Was der IT-Grundschutz-Check ist und was er voraussetzt
BSI-Standard 200-2 beschreibt den IT-Grundschutz-Check als „Organisationsinstrument, das einen schnellen Überblick über das vorhandene Sicherheitsniveau bietet“ (Kap. 7.7). Das Kompendium erklärt den Begriff im Glossar als Überprüfung, ob die empfohlenen Anforderungen bereits erfüllt sind, mit dem Zusatz „(früher: Basis-Sicherheitscheck)“.
Bei der Standard-Absicherung setzt 200-2 für den Check voraus, dass Strukturanalyse, Schutzbedarfsfeststellung und Modellierung vorliegen; die Modellierung, also die Zuordnung der Bausteine zu Zielobjekten, dient im Check als Prüfplan (200-2, Kap. 8.4). Die Arbeitsschritte dürfen nach 200-2 zwar parallel laufen (Kap. 8, „Reihenfolge der Bearbeitung“), geprüft werden kann aber nur, was schon modelliert ist. Bei der Basis-Absicherung genügen Erstaufnahme und Auswahl der Bausteine, die dann als Prüfplan dienen (Kap. 6.3).
Der Check gehört zu jeder der drei klassischen Vorgehensweisen. Bei der Basis-Absicherung werden nur die Basis-Anforderungen geprüft; für Standard- oder Kern-Absicherung kommt ein eigener Check mit den Standard-Anforderungen hinzu. 200-2 empfiehlt, die Ergebnisse der Basis-Absicherung so aufzubereiten, dass sie in die spätere Vorgehensweise übernommen werden können (Kap. 6.3).
Schritt 1: Vorbereitung
Die organisatorischen Vorarbeiten stehen in 200-2, Kap. 8.4.1. Wir haben sie als Prüfliste mit dem jeweils erwarteten Ergebnis aufbereitet:
| Vorarbeit | Ergebnis, das vor dem ersten Interview vorliegen sollte |
|---|---|
| Vorhandene Regelungen und Dokumentationen zu Sicherheitsabläufen sichten, auch ungeschriebene Praxis (200-2, Kap. 8.4.1) | Unterlagenliste je Baustein mit zuständiger Person für jedes Dokument |
| Klären, ob externe Stellen beteiligt werden müssen, etwa externe Rechenzentren, vorgesetzte Behörden, Outsourcing-Dienstleister oder Baubehörden | Liste der externen Stellen mit Ansprechperson und Weg der Beteiligung (Interview, schriftliche Auskunft, Vor-Ort-Termin) |
| Für jeden in der Modellierung verwendeten Baustein einen Hauptansprechpartner festlegen; die Rollen in den Anforderungen helfen dabei | Zuordnung Baustein und Zielobjekt zu Hauptansprechpartner |
| Terminplan für die Interviews mit vorab abgestimmten Ausweichterminen | Interviewplan (siehe unten) |
| Interviewteams bilden; 200-2 nennt zwei Personen je Interview, eine fragt, eine protokolliert | Teamaufteilung je Termin |
Wir empfehlen dazu eine Vorabanforderung: Wer weiß, welche Unterlagen und welche Stichprobe im Interview gebraucht werden, bringt sie mit. 200-2 empfiehlt außerdem, je nach Fachgebiet vorab Checklisten zu erstellen (Aktionspunkte zu Kap. 8.4.2).
Arbeitsergebnis 1: Interviewplan
Fiktives Beispiel. Eine Behörde hat ihren Informationsverbund „Bürgerservice“ nach Standard-Absicherung modelliert. Bausteine, Titel und Zuständigkeitsbeispiele stammen aus dem IT-Grundschutz-Kompendium Edition 2023 und aus 200-2, Kap. 8.4.1; Zielobjekte, Termine und Stichproben sind erfunden.
| Block | Baustein und Zielobjekt | Hauptansprechpartner (Rolle) | Vorab anfordern | Geplante Stichprobe | Termin / Ausweichtermin |
|---|---|---|---|---|---|
| 1 | ISMS.1 Sicherheitsmanagement, Informationsverbund | ISB; für Fragen zur Gesamtverantwortung die Behördenleitung | Leitlinie, Sicherheitskonzept, letzte Managementberichte | Freigabevermerk der Leitlinie, Protokoll der letzten Leitungsbefassung | Di 10.03., 09:00 / Do 12.03., 09:00 |
| 2 | ORP.2 Personal, Informationsverbund | Personalabteilung | Einarbeitungs- und Austrittscheckliste | Zwei Austritte des letzten Halbjahres von der Checkliste bis zur Kontosperre nachverfolgen | Di 10.03., 13:00 / Fr 13.03., 09:00 |
| 3 | CON.3 Datensicherungskonzept, Informationsverbund | IT-Betrieb, zuständig für die Datensicherung | Datensicherungskonzept, Datensicherungspläne | Sicherungsprotokolle der letzten vier Wochen, Nachweis des letzten Wiederherstellungstests | Mi 11.03., 09:00 / Mo 16.03., 09:00 |
| 4 | OPS.1.1.3 Patch- und Änderungsmanagement, Informationsverbund | IT-Betrieb | Patchrichtlinie, Auszug aus dem Ticketsystem | Patchstand von drei Servern und fünf Clients am Tag des Interviews | Mi 11.03., 11:00 / Mo 16.03., 11:00 |
| 5 | SYS.1.1 Allgemeiner Server, Gruppe S-01 bis S-12 | Administration der Server-Gruppe | Härtungsvorgabe, Betriebsdokumentation | Dienste-Liste auf drei Servern gegen die Härtungsvorgabe | Mi 11.03., 13:00 / Di 17.03., 09:00 |
| 6 | NET.1.1 Netzarchitektur und -design, Netz N-01 | Netzadministration | Netzplan, Zonenkonzept | Netzplan gegen die Konfiguration eines Kernswitches | Do 12.03., 13:00 / Di 17.03., 13:00 |
| 7 | INF.2 Rechenzentrum sowie Serverraum, Raum R-0.14 | Haustechnik, dazu der externe Gebäudeverwalter | Wartungsnachweise für USV und Klimatisierung | Begehung des Serverraums mit der Haustechnik | Fr 13.03., 10:00 / Mi 18.03., 10:00 |
Jeder Block deckt einen Baustein mit seinen Zielobjekten ab, damit der Hauptansprechpartner am Ende des Termins das Ergebnis für seinen Baustein erfährt; so sieht es 200-2 vor (Kap. 8.4.2). Bei Bausteinen, die viele gleichartige Zielobjekte betreffen, wie hier zwölf Server, prüfen Sie eine Gruppe und dokumentieren, welche Mitglieder Sie stichprobenartig angesehen haben.
Schritt 2: Erhebung im Interview
Gehen Sie die Anforderungen des Bausteins der Reihe nach durch und lassen Sie die befragte Person zuerst schildern, was schon umgesetzt ist. Halten Sie Bausteintext und Umsetzungshinweise bereit. Was überprüft werden soll, sehen Sie sich als Stichprobe an: das Dokument, den Raum, die Einstellung am System (200-2, Kap. 8.4.2).
Für jede Anforderung vergeben Sie einen von vier Werten (Kap. 8.4.2):
| Status | Bedeutung nach 200-2 | Was im Protokoll stehen muss |
|---|---|---|
| ja | „Zu der Anforderung wurden geeignete Maßnahmen vollständig, wirksam und angemessen umgesetzt.“ | die Maßnahme, die die Anforderung erfüllt, und der Beleg |
| teilweise | nur ein Teil der Anforderung ist umgesetzt | welcher Teil fehlt und welche Maßnahme noch umzusetzen ist |
| nein | die Anforderung ist noch nicht erfüllt, geeignete Maßnahmen fehlen größtenteils | fehlende Maßnahmen, Verantwortliche, soweit schon erkennbar |
| entbehrlich | die Anforderung ist im Informationsverbund nicht relevant, etwa weil Dienste nicht aktiviert sind, oder wird durch Alternativmaßnahmen behandelt | Begründung und die zugehörigen elementaren Gefährdungen aus der Kreuzreferenztabelle; bei Alternativmaßnahmen zusätzlich die Begründung, warum das Risiko aller betreffenden Gefährdungen angemessen gemindert ist |
Zwei Grenzen gelten für „entbehrlich“. Bei Basis-Anforderungen kann das entstehende Risiko nicht übernommen werden, und eine Anforderung darf nicht entbehrlich gesetzt werden, indem das Risiko einer Gefährdung über die Kreuzreferenztabelle pauschal akzeptiert oder ausgeschlossen wird (200-2, Kap. 8.4.2; für die Kern-Absicherung auch Kap. 7.7). Das Kompendium stellt zusätzlich klar, dass eine Anforderung nicht schon deshalb hinfällig wird, weil alle in der Kreuzreferenztabelle zugeordneten Gefährdungen im Einzelfall nicht relevant sind; entschieden wird anhand der vollständigen Sicherheitskonzeption.
Die Befragungstiefe orientiert sich zunächst an Basis- und Standard-Anforderungen. Aspekte hochschutzbedürftiger Anwendungen, die über dieses Niveau hinausgehen, betrachten Sie erst nach Abschluss des Checks (Kap. 8.4.2).
Arbeitsergebnis 2: Prüfprotokoll
Für die Dokumentation nennt 200-2 Kopfangaben je Zielobjekt und Felder je Anforderung (Kap. 8.4.3). Das folgende Protokoll setzt beides um. Fiktives Beispiel mit echten Anforderungen aus dem Baustein SYS.1.1 der Edition 2023; Feststellungen, Namen und Termine sind erfunden.
| Kopfangaben | |
|---|---|
| Zielobjekt | S-01 bis S-12, Gruppe „Fachverfahrensserver“, Baustein SYS.1.1 Allgemeiner Server |
| Standort | Serverraum R-0.14, Hauptgebäude |
| Erfassung | 11.03. (Interview) und 13.03. (Begehung), erfasst von A. Beispiel (ISB-Team), Protokoll B. Muster |
| Befragte | C. Admin (Administration Server), D. Vertretung |
| Anforderung | Status | Umsetzung durch | Beleg und Stichprobe | Umsetzung bis | Verantwortlich | Bemerkung, Defizit, Risiko |
|---|---|---|---|---|---|---|
| SYS.1.1.A6 Deaktivierung nicht benötigter Dienste (B) | teilweise | Härtungsvorgabe HV-SRV, Fassung 3, mit Liste zulässiger Dienste | Dienste-Liste auf S-03, S-07 und S-11 am 11.03. gegen HV-SRV verglichen; auf S-07 ein Druckdienst aktiv, für den es keinen Bedarf gibt | 30.04. | C. Admin | Dienst auf S-07 deaktivieren, übrige neun Server nach demselben Verfahren prüfen; bis dahin erweitert der Dienst die Angriffsfläche von S-07 |
| SYS.1.1.A15 Unterbrechungsfreie und stabile Stromversorgung (S) | ja | Anschluss aller zwölf Server an die zentrale USV des Serverraums | bei der Begehung am 13.03. Anschluss von S-01 und S-12 gesehen; Wartungsprotokoll der USV vom Januar | Die USV selbst wird im Baustein INF.2 geprüft (INF.2.A3) | ||
| SYS.1.1.A21 Betriebsdokumentation für Server (S) | ja | Betriebshandbuch je Server im Wiki, Änderungen werden automatisch aus dem Ticketsystem übernommen | Einträge für S-03 gesichtet, letzte Konfigurationsänderung vom 02.03. mit Ticketnummer nachvollziehbar | |||
| SYS.1.1.A23 Systemüberwachung und Monitoring von Servern (S) | ja | zentrales Monitoring mit Grenzwerten und Alarmierung an die Rufbereitschaft | Dashboard am 11.03. eingesehen, Grenzwerte für alle zwölf Server hinterlegt, Alarm vom 04.03. mit Quittierung | |||
| SYS.1.1.A25 Geregelte Außerbetriebnahme eines Servers (S) | nein | keine Regelung vorhanden | im Interview bestätigt: Außerbetriebnahmen ohne Checkliste; zum letzten ausgemusterten Server liegt kein Löschnachweis vor | 30.06. | noch offen, in der Realisierungsplanung festlegen | Checkliste für die Außerbetriebnahme erstellen; Risiko: schutzbedürftige Daten auf ausgemusterten Datenträgern |
Das Feld „Umsetzung bis“ hält 200-2 für sinnvoll, auch wenn es im Check „im Allgemeinen nicht ausgefüllt wird“; es dient als Platzhalter für die Realisierungsplanung, ebenso das Feld für Verantwortliche, das nur ausgefüllt wird, wenn die Zuständigkeit schon eindeutig ist (Kap. 8.4.3). Für nicht oder nur teilweise erfüllte Anforderungen verlangt 200-2 außerdem, das damit verbundene Risiko zu ermitteln und den Aufwand für die Beseitigung zu schätzen. Den Aufwand führen Sie am besten in einer eigenen Spalte oder direkt in der Realisierungsplanung.
Arbeitsergebnis 3: schwache und belastbare Feststellungen
Ein Check ist so viel wert wie seine Feststellungen. 200-2 verlangt eine Dokumentation, die für alle Beteiligten nachvollziehbar ist und als Grundlage der Umsetzungsplanung dient; im Hinblick auf eine Zertifizierung soll festgehalten werden, durch welche Maßnahmen die Anforderungen konkret erfüllt werden (Kap. 8.4.3). Daraus haben wir eine Gegenüberstellung als Arbeitshilfe abgeleitet:
| Anforderung | Schwache Feststellung | Belastbare Feststellung | Was den Unterschied macht |
|---|---|---|---|
| SYS.1.1.A6 | „Nicht benötigte Dienste sind laut Admin deaktiviert.“ Status ja. | Dienste-Liste auf S-03, S-07, S-11 am 11.03. gegen HV-SRV, Fassung 3, verglichen; Abweichung auf S-07. Status teilweise. | Stichprobe mit Systemen, Datum und Soll-Vorgabe; Abweichung benannt |
| CON.3.A5 Regelmäßige Datensicherung (B) | „Backups laufen täglich.“ | Sicherungsprotokolle 10.02. bis 10.03. gesichtet, zwei fehlgeschlagene Läufe am 18.02. und 25.02., beide am Folgetag nachgeholt; Turnus und Umfang der Läufe stimmen mit dem Datensicherungsplan DSP-01 (täglich, Vollsicherung sonntags) überein; Information der Mitarbeitenden über die Regelungen im Intranet seit 01.12.; Aufgaben der Mitarbeitenden bei der Datensicherung in der Dienstanweisung DA-07, Abschnitt 3, beschrieben. Status ja. | Zeitraum, Fundstelle, auch das Negative steht im Protokoll; jeder Teil der Anforderung geprüft |
| Beliebige Anforderung, Status entbehrlich | „nicht relevant“ | „Der Dienst X ist auf keinem Server der Gruppe installiert und wird nicht benötigt, geprüft am Softwareinventar vom 10.03.; zugehörige Gefährdungen laut Kreuzreferenztabelle: G 0.x, G 0.y; die Entscheidung ist im Sicherheitskonzept, Abschnitt …, festgehalten.“ | Grund ist überprüfbar; Gefährdungen benannt; Entscheidung im Sicherheitskonzept; Prüfquelle mit Datum |
| ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) | „ISB ist benannt.“ | Bestellungsschreiben der Behördenleitung vom 05.01. liegt vor und überträgt dem ISB, die Informationssicherheit zu fördern sowie den Sicherheitsprozess mitzusteuern und zu koordinieren; Stellenanteil und eigenes Budget im Haushaltsplan, Kapitel 4; direktes Vortragsrecht in der Geschäftsordnung, Abschnitt 4; Beteiligung bei neuen Fachverfahren im Projekthandbuch geregelt, beim letzten Projekt im Protokoll vom 20.02. belegt. | jeder Teil der Anforderung einzeln belegt, vom ersten bis zum letzten Satz |
Prüffragen für jede Zeile, bevor das Protokoll abgeschlossen wird:
- Woher stammt die Aussage: Interview, Dokument, Stichprobe am System oder vor Ort?
- Welche Systeme, Dokumente oder Vorgänge wurden angesehen, wie viele und an welchem Tag?
- Deckt der Beleg die ganze Anforderung ab oder nur einen Satz daraus?
- Ist bei „teilweise“ und „nein“ benannt, was fehlt, und bei „entbehrlich“, warum?
- Würde eine dritte Person, etwa ein Auditteam, mit dem Protokoll und den Belegen zum selben Status kommen?
Was sich mit Grundschutz++ ändert
BSI-Standard 300-1 verwendet den Begriff IT-Grundschutz-Check nicht. Der entsprechende Arbeitsschritt heißt dort Ermittlung des Umsetzungsstatus und gehört zum Prozessschritt Realisierung (Kap. 4.1). Als Verfahren nennt 300-1 eine Spanne von Interviews und Dokumentenprüfungen bis zu automatisierten Konfigurationsprüfungen und technischen Scans. Drei Unterschiede betreffen Ihr Protokoll unmittelbar:
| Punkt | IT-Grundschutz-Check (200-2) | Umsetzungsstatus (300-1) |
|---|---|---|
| Statuswerte | ja, teilweise, nein, entbehrlich | „erfüllt“ („ja“), „nicht erfüllt“ („nein“), „nicht anwendbar“ (Kap. 4.1.1); einen Wert „teilweise“ gibt es nicht |
| Verzicht auf eine Anforderung | „entbehrlich“, auch bei Behandlung durch Alternativmaßnahmen, mit Begründung | „nicht anwendbar“ nur, wenn die Anforderung funktional nicht erfüllt werden kann oder die zugrunde liegende Komponente im Informationsverbund nicht existiert; Begründung ist Pflicht (Kap. 4.1.1) |
| Belege | Bemerkungen und Begründungen je Anforderung | Nachweise werden der Maßnahme eindeutig zugeordnet, die Maßnahme der Anforderung; bei automatisierter Prüfung mit Werkzeug, Zeitpunkt und Ergebnis (Kap. 4.3) |
Für die Übernahme vorhandener Ergebnisse folgt daraus: Ein „teilweise“ wird nach 300-1 zu „nicht erfüllt“, bis die fehlenden Teile umgesetzt sind. Ein „entbehrlich“ prüfen Sie gegen die beiden Gründe für „nicht anwendbar“; fehlende Relevanz allein reicht nicht. Wurde die Anforderung durch eine Alternativmaßnahme behandelt, entscheiden Sie an der neuen Anforderung, ob die Maßnahme sie erfüllt. Ein Status lässt sich ohnehin nicht einfach umschreiben, weil die alten Anforderungen nicht eins zu eins auf die neuen abgebildet sind; wie die Zuordnungstabelle des BSI dabei hilft und wo sie nicht weiterhilft, zeigt die Seite Mapping IT-Grundschutz 2023.
Der Anwenderkatalog vom 29.10.2026 fasst den Schritt als Anforderung UMS.1.1: „Umsetzung MUSS den Umsetzungsstatus der Anforderungen im Anforderungspaket vollständig [regelmäßig] überprüfen.“ Die Erläuterung dazu kennt noch zwei Werte: „Der Umsetzungsstatus einer Anforderung kann grundsätzlich nur „umgesetzt“ („ja“) oder „nicht umgesetzt“ („nein“) sein.“ Der Standard nennt drei Werte. Halten Sie sich an den Standard und notieren Sie den Katalog-Build, mit dem Sie arbeiten.
Wie Sie Status, Abweichungen und Nichtanwendbarkeit nach 300-1 im Einzelnen dokumentieren, steht auf der Seite Anforderungen bewerten, Abweichungen dokumentieren. Wer welche Nachweise wann liefert, legt der Nachweisplan fest.
Nach dem Check
Mit dem abgeschlossenen Check liegt der Soll-Ist-Vergleich vor, auf dem die Realisierungsplanung aufsetzt (200-2, Kap. 6.4 und 9). Prüfen Sie vorher zwei Dinge: ob jedes Zielobjekt aus der Modellierung im Protokoll vorkommt, und ob jede Anforderung mit „teilweise“ oder „nein“ eine Bemerkung zur fehlenden Maßnahme hat. Wer eine Zertifizierung nach ISO 27001 auf Basis von IT-Grundschutz anstrebt, braucht im Protokoll die konkreten Maßnahmen je Anforderung (Kap. 8.4.3); das Verfahren selbst beschreibt die Seite Zertifizierung. Wer ein ISMS nach dem Kompendium 2023 nach Grundschutz++ überführt, findet die Reihenfolge der Arbeitspakete auf der Seite Migration. Den Standard selbst erschließt die Seite BSI-Standard 200-2, die Wahl der Vorgehensweise die Seite Basis-, Kern- oder Standard-Absicherung und den sicheren Umgang mit der Ausgabe 2023 die Seite IT-Grundschutz-Kompendium.
Wenn Sie den Umsetzungsstatus nach 300-1 erheben oder einen vorhandenen IT-Grundschutz-Check in die neue Statuslogik überführen wollen, unterstützt Sie Blackfort Technology, siehe Beratung.
Rechtehinweis: Kurze Zitate aus BSI-Standard 200-2 „IT-Grundschutz-Methodik“, Version 1.0, © Bundesamt für Sicherheit in der Informationstechnik 2017, Quelle: BSI-Seite zu BSI-Standard 200-2; Baustein- und Anforderungstitel sowie ein Kurzzitat aus dem Glossar des IT-Grundschutz-Kompendiums, Edition 2023, © 2023 Reguvis Fachmedien GmbH und © 2023 Bundesamt für Sicherheit in der Informationstechnik, Quelle: BSI-Seite zum IT-Grundschutz-Kompendium; aus BSI-Standard 300-1 „Methodik Grundschutz++“, Version 1.0 vom 20.10.2026, © Bundesamt für Sicherheit in der Informationstechnik 2026, Quelle: BSI-Seite zu Grundschutz++. Diese Zitate stehen nicht unter CC BY-SA 4.0; der Lizenzhinweis am Seitenende gilt nur für den Auszug aus den Katalogdaten.