Grundschutz-Beschaffung in der Praxis: ein Cloud-Dienst vom Bedarf bis zum Vertragsende

Eigene Auszählung im Anwenderkatalog Grundschutz++, Build 2026-10-29, rekursiv über alle Verschachtelungsebenen:

Zwei Beobachtungen helfen bei der Arbeit. Erstens haben 70 der 109 BES-Anforderungen im Feld documentation den Wert „Beschaffungskriterien“. Die meisten Beschaffungsanforderungen landen also in einem einzigen Dokument, den Kriterien, die vor der Vergabe feststehen. Zweitens lautet das Verb in 84 der 109 Anforderungen „vereinbaren“ (52) oder „dokumentieren“ (32). Eine Anforderung mit „vereinbaren“ ist erfüllt, wenn die Vereinbarung im Vertrag steht. Ob der Anbieter sie einhält, prüft später DLS.

Die Zielobjektkategorien dieser Praktiken bauen aufeinander auf. Nach den Definitionen in Anhang 1 von BSI-Standard 300-1 sind IT-Produkte und Dienstleistungen jeweils Einkäufe, Outsourcing ist eine Dienstleistung und Cloud-Dienste sind Outsourcing. Kapitel 3.4.2 verlangt, einem Asset auch die übergeordneten Zielobjektkategorien zuzuordnen. Ein Cloud-Dienst erhält damit die Anforderungen für Cloud-Dienste, Outsourcing, Dienstleistungen und Einkäufe.

Fiktives Beispiel. Anforderungen aus dem Anwenderkatalog Grundschutz++ (Build 2026-10-29), als Infinitiv gekürzt, Parameter in eckigen Klammern. Prüffragen, Belege, Rollen und Ergebnisse sind erfunden. Die Tabelle ist eine Auswahl entlang des Ablaufs, keine vollständige Liste der 83 MUSS- und SOLLTE-Anforderungen mit Sicherheitsniveau normal-SdT im Paket des Falls.

Was die Tabelle aus Platzgründen nicht zeigt: Für jede Zeile gehören nach Kapitel 4.3 von 300-1 die zugeordnete Maßnahme, das Datum der Umsetzung oder Überprüfung und die prüfende Person in den Umsetzungsplan. Wie Sie das ordnen, zeigt der Nachweisplan.

Befund 1, BES.4.8.2 (SOLLTE, Cloud-Dienste): Konformitätsnachweis durch Dritte. Die Vertragsklausel ist vereinbart. Die Erläuterung im Katalog verlangt aber mehr als den Nachweis selbst: „Hierbei ist zu prüfen, ob der Geltungsbereich und der Schutzbedarf die genutzten Clouddienste erfasst (Auswertung des Nachweises). Dies gilt auch für Subdienstleister.“ Bei der Auswertung zeigt sich, dass der Nachweis von Anbieter P das Rechenzentrum von U1 einschließt, den Support durch U2 aber nicht. Das LFV setzt den Status auf „nicht erfüllt“ und ordnet die Nichterfüllung als temporär ein: Anbieter P hat zugesagt, U2 bis zur nächsten Prüfung in den Geltungsbereich aufzunehmen, die Frist steht im Umsetzungsplan.

Ob eine temporär nicht erfüllte SOLLTE-Anforderung eine Risikobetrachtung auslöst, beantwortet 300-1 an zwei Stellen unterschiedlich. Kapitel 4.1.2 sagt: „Eine temporäre Nichterfüllung löst keine Risikobetrachtung aus.“ Kapitel 2.11 verlangt für SOLLTE-Anforderungen, die in der Umsetzungsplanung enthalten, aber noch nicht erfüllt sind, eine Restrisikobetrachtung; das identifizierte Risiko muss die Institutionsleitung freigeben. Kapitel 4.1.1 verlangt, das noch nicht mitigierte Risiko zu identifizieren und der Leitung mitzuteilen. Wie diese Stellen zusammenpassen, ist eine offene Auslegungsfrage. Das LFV geht den vorsichtigen Weg: Es beschreibt das Restrisiko (Supportzugriffe durch U2 ohne geprüften Nachweis), teilt es der Leitung mit und lässt es befristet bis zum Fristende freigeben.

Befund 2, BES.6.3 (SOLLTE, Dienstleistungen): Übertragbarkeit von Daten, Konfigurationen und Funktionalität für den Fall einer Kündigung. Vereinbart ist nur der Export der Antragsdaten und Dokumente. Die im Portal angelegten Workflows und Bescheidvorlagen lassen sich nicht übertragen, und Anbieter P lehnt eine Ergänzung ab. Die Erfüllung ist damit auf absehbare Zeit nicht vorgesehen: eine dauerhafte Nichterfüllung. Nach Kapitel 2.11 und 4.1.2 folgt daraus eine Risikobetrachtung. Risikoeigentümer ist nach Kapitel 4.2.1 der Eigentümer von GP-07, weil nichts anderes festgelegt ist. Für die Risikobehandlung zieht das LFV eine KANN-Anforderung heran, was Kapitel 3.4.2 ausdrücklich ermöglicht: BES.8.2 (KANN, Outsourcing) verlangt ein Verfahren zur Übertragung von Geschäftsprozessen für den Fall einer geplanten oder ungeplanten Vertragsbeendigung. Das LFV dokumentiert die Workflows und Vorlagen außerhalb des Portals und pflegt sie bei jeder Änderung nach. Das verbleibende Restrisiko geht der Leitung zur Freigabe zu (Kapitel 4.2.3). Wie das im Register aussieht, zeigt das Risikoregister; die Freigabe beschreibt Risikoakzeptanz und Restrisiko.

Ein MUSS-Befund hätte anders ausgesehen: Für nicht erfüllte MUSS-Anforderungen sind nach Kapitel 4.1.2 Maßnahmen festzulegen, eine Risikobetrachtung ersetzt sie nicht, und eine Ausnahmegenehmigung oder Risikoakzeptanz ist nicht möglich. Im Fall betrifft das zum Beispiel DLS.1.1 (MUSS, Dienstleistungen), das Verfahren zur Steuerung und geordneten Beendigung von Dienstleistungsverträgen. Ohne dieses Verfahren gäbe es für DP-07 keinen Rahmen.

Die Phasen hängen an Unterlagen, die von einer Stelle zur nächsten wandern. Fehlt eine davon, fehlt der nächsten Phase die Prüfgrundlage:

• Kriterienkatalog → Abnahmeprotokoll. Die Akzeptanzkriterien für BES.7.1 sind die Beschaffungskriterien aus BES.4.2 oder deren Konkretisierung. Wer die Kriterien vor der Vergabe nicht festlegt, kann bei der Abnahme nichts dagegen testen.
• Vertrag → Auslagerungsregister. Was nach BES.5 vereinbart wurde, steht im Register (BES.7.4.9) und bildet dort die Liste dessen, was DLS.3.1 später prüft. Die Katalogerläuterung zu BES.7.4.9 sagt dazu: „Hierzu genügt ein zentrales Auslagerungsregister“.
• Prüfergebnis → Sperrliste. Stellt die Prüfung nach DLS.3.1 fest, dass künftig mit Verstößen zu rechnen ist, greift DLS.3.5. Die Erläuterung definiert einen Dienstleister als unzuverlässig, „wenn zukünftig mit Verstößen gegen die Schutzziele Vertraulichkeit, Verfügbarkeit oder Integrität durch ihn zu rechnen ist“. Die Sperrliste fragt die Vergabestelle bei jeder neuen Beschaffung ab (BES.3.3). Ob ein gelisteter Anbieter in einem Vergabeverfahren ausgeschlossen werden darf, richtet sich nach dem Vergaberecht; das prüfen Vergabestelle und Rechtsabteilung.
• Meldeweg → Vorfallsbearbeitung. Die Meldeadresse aus BES.5.10.2 gehört in das Meldeverfahren der Detektion, sonst landet die Meldung des Anbieters in einem Funktionspostfach ohne Zuständigkeit. Wie eine solche Meldung weiterläuft, zeigt Detektion und Vorfallsbearbeitung.
• Vertragsende → Berechtigungsverwaltung. DLS.4.1.2 verlangt, die für den Vertrag benötigten Berechtigungen unverzüglich zu deaktivieren. Das geht nur, wenn die Konten des Anbieterpersonals im Inventar der Berechtigungen stehen; den Ablauf für Eintritt, Wechsel und Austritt zeigt Berechtigungen und Personal.
• Befunde → Managementbewertung. Befund 1 und Befund 2 gehen mit Status, Frist und Risikoentscheidung in den Managementbericht; siehe Managementbewertung und Kennzahlen.

Wie wir die drei Fälle grundsätzlich dokumentieren, steht auf der Seite Anwenderkatalog Grundschutz++. Halten Sie Ihre Entscheidung mit Begründung und Katalogstand fest und prüfen Sie sie bei jedem neuen Build, denn die Kataloge werden fortlaufend aktualisiert.

1. Zuordnung: Welchen Zielobjektkategorien ist das neue Asset zugeordnet, einschließlich der übergeordneten? Ist eine verworfene Zuordnung, etwa zu IT-Produkten, begründet?
2. Parameter: Sind die Parameter der beteiligten Anforderungen festgelegt, zum Beispiel „regelmäßig“ in DLS.3.1 und DLS.3.1.1 oder [Kriterien zur Akzeptanz] in BES.7.1 (Kapitel 3.5)?
3. Kriterien vor Vergabe: Stehen die Beschaffungskriterien fest, bevor Angebote eingehen, und folgen sie der Vertragsrichtlinie (BES.4.2, BES.4.4)?
4. Geteilte Verantwortung: Ist die Verteilung der Schutzmaßnahmen im Vertrag vereinbart und nicht nur intern beschrieben (BES.1.7)?
5. Unterauftragnehmer: Sind sie benannt, gelten die Kriterien auch für sie, und deckt der Nachweis sie ab (BES.5.6, BES.5.6.1, BES.4.8.2)?
6. Ende mitdenken: Sind Löschung, Entzug der Zugänge und Übertragbarkeit für den Kündigungsfall vereinbart (BES.6.1 bis BES.6.3)?
7. Abnahme: Ist jedes Akzeptanzkriterium mit Ergebnis protokolliert, bevor der Dienst produktiv genutzt wird (BES.7.1)?
8. Betrieb: Steht der Vertrag im Auslagerungsregister mit Prüfturnus, und wird der Nachweis im festgelegten Turnus (Parameter „regelmäßig“ in DLS.3.1.1) ausgewertet und nicht nur abgelegt (BES.7.4.9, DLS.3.1.1)?

Blackfort Technology unterstützt Sie dabei mit Paket C der Umsetzung nach Grundschutz++: Statusermittlung je Anforderung, darunter BES und DLS, und ein Nachweisplan, der Kriterienkatalog, Abnahmeprotokoll und Auslagerungsregister miteinander verbindet. Vertragsklauseln bewerten wir technisch; die rechtliche Prüfung bleibt bei Ihrer Rechtsabteilung.

Die Beschaffung setzt Ergebnisse aus früheren Schritten voraus und liefert welche für spätere:

• Der Schutzbedarf von GP-07 kommt aus der Schutzbedarfsfeststellung; bei hohem Schutzbedarf wäre nach Kapitel 2.11 eine explizite Risikobetrachtung fällig, und die KANN-Anforderungen wie BES.4.8.1 (Zertifikat oder Testat nach [einem passenden Sicherheitsstandard]) würden dafür zur Auswahl stehen.
• Wie ein Asset den Zielobjektkategorien zugeordnet wird, beschreibt Modellierung und Zielobjektkategorien.
• Wie Status und Abweichungen vergeben werden, steht unter Anforderungen bewerten, Abweichungen dokumentieren.
• Wer Cloud-Anbieter nach dem Kriterienkatalog C5 bewerten will oder einen externen ISB sucht, findet das auf der Firmenseite https://www.blackfort-tec.de.