Grundschutz++ und IT-Grundschutz 2023: welche Unterschiede Ihre Arbeit betreffen

Verglichen werden zwei Stände. Auf der einen Seite der klassische IT-Grundschutz: BSI-Standard 200-2 „IT-Grundschutz-Methodik“ und 200-3 „Risikoanalyse auf der Basis von IT-Grundschutz“, jeweils Version 1.0 vom Oktober 2017, zusammen mit dem IT-Grundschutz-Kompendium in der Edition 2023. Auf der anderen Seite Grundschutz++: BSI-Standard 300-1 „Methodik Grundschutz++“, Version 1.0 vom 20.10.2026, und der Anwenderkatalog Grundschutz++ in der Stand-der-Technik-Bibliothek, hier im Build vom 29.10.2026.

Vieles bleibt vertraut. Beide Methoden arbeiten mit einem Informationsverbund, mit Schutzbedarf für Vertraulichkeit, Integrität und Verfügbarkeit, mit einer Leitlinie, einer Sicherheitsorganisation und den 47 elementaren Gefährdungen. Beide gehen davon aus, dass das BSI für den normalen Schutzbedarf die Gefährdungs- und Risikobewertung vorab übernommen hat. Neu sind vor allem das Datenmodell (Geschäftsprozess, Asset, Zielobjektkategorie, Anforderungspaket), die Bewertungslogik und die ausdrückliche Zulassung automatisierter Prüfungen als Nachweis.

Wie man ein bestehendes ISMS Schritt für Schritt überführt, beschreibt die Seite zur Migration. Diese Seite bleibt beim Was: welche Arbeitsergebnisse sich ändern und wie stark.

Geschäftsprozesse gab es schon in 200-2. Dort wird zuerst der Schutzbedarf der Geschäftsprozesse und Anwendungen bestimmt und dann auf IT-Systeme, Räume und Kommunikationsverbindungen vererbt, im Wesentlichen nach dem Maximumprinzip (200-2, Kap. 8.2.2). Neu in 300-1 ist, dass der Schutzbedarf je Geschäftsprozess in zwei Stufen festgestellt wird. Eine eigene Schutzbedarfsfeststellung für IT-Systeme oder Räume beschreibt 300-1 nicht. An den Assets zählt das Sicherheitsniveau, das sich aus dem Schutzbedarf des betrachteten Geschäftsprozesses ergibt: „normal-SdT“ oder „erhöht“ (Kap. 3.4.2).

Als Hilfe für die Einstufung „hoch“ nennt 300-1 fünf Schadensszenarien, darunter Gesetzesverstöße mit existenzbedrohender Konsequenz, Beeinträchtigung der persönlichen Unversehrtheit und finanzielle Auswirkungen existenzbedrohenden Ausmaßes. 200-2 kannte sechs Schadensszenarien mit Tabellen für alle drei Kategorien, einschließlich der Beeinträchtigung der Aufgabenerfüllung mit Ausfallzeiten. Wer seine Schutzbedarfstabellen aus 200-2 weiterverwendet, muss sie auf die beiden Kategorien von 300-1 abbilden; für ein zertifizierbares ISMS ist in der niedrigsten Kategorie stets der Stand der Technik einzuhalten (Kap. 2.6).

Bei der Modellierung ersetzt die Zielobjektkategorie das Zusammenspiel von Baustein und Zielobjekt. Anhang 1 von 300-1 definiert 39 Kategorien von Standorten über Nutzende, Netze und IT-Systeme bis zu Anwendungen; Cloud-Dienste stehen unter Outsourcing. Die übergeordneten Kategorien gelten jeweils mit. Eine Besonderheit, die oft übersehen wird: Anforderungen ohne Zielobjektkategorie sind nach Kap. 3.4.1 verpflichtend in das Anforderungspaket aufzunehmen. Der Katalog im Build vom 29.10.2026 beschreibt in der Erläuterung zu STM.2.1.5 noch, nicht relevante Anforderungen dieser Art mit Begründung aus dem Paket zu streichen. Für die eigene Dokumentation empfehlen wir, dem Standard zu folgen, die Anforderung im Paket zu lassen und, wo sie nicht greift, den Status „nicht anwendbar“ mit einem der beiden Gründe aus Kap. 4.1.1 zu belegen: Die Anforderung kann funktional nicht erfüllt werden, oder die zugrunde liegende Komponente existiert im Informationsverbund nicht. Passt keiner der beiden Gründe, ist die Anforderung zu bewerten wie jede andere.

Die Anforderungen selbst liegen als Daten vor. Sie haben im Katalog Eigenschaften wie Sicherheitsniveau, Aufwandsstufe und Schutzziele; 901 der 1.000 Anforderungen haben eine Zuordnung zu elementaren Gefährdungen (eigene Auszählung, Build 29.10.2026). Das erlaubt Filter, Auswertungen und Abgleiche, die mit dem Kompendium nur über Werkzeuge oder Handarbeit möglich waren.

Die Statuslogik ist strenger geworden. 300-1 verlangt, für jede Anforderung den Umsetzungsstatus vollständig zu prüfen, und kennt nur „erfüllt“, „nicht erfüllt“ und „nicht anwendbar“ (Kap. 4.1.1). „Nicht anwendbar“ ist zulässig, wenn die Anforderung funktional nicht erfüllt werden kann oder die zugrunde liegende Komponente im Informationsverbund nicht existiert, und immer zu begründen. Der Wert „teilweise“ aus dem IT-Grundschutz-Check entfällt, ebenso „entbehrlich“ mit Verweis auf Alternativmaßnahmen. Im Build vom 29.10.2026 beschreibt die Erläuterung zu UMS.1.1 im Katalog grundsätzlich nur „umgesetzt“ und „nicht umgesetzt“; der Katalog hinkt hier dem Standard nach.

Was bei einer nicht erfüllten Anforderung folgt, hängt vom Modalverb ab (Kap. 4.1.2). Bei MUSS sind Maßnahmen zur Erfüllung festzulegen; eine Risikobetrachtung kann die Erfüllung nicht ersetzen, Ausnahmegenehmigung und Risikoakzeptanz sind ausgeschlossen. Bei SOLLTE wird zwischen temporärer und dauerhafter Nichterfüllung unterschieden. Temporär heißt, die Erfüllung ist vorgesehen; die Nichterfüllung ist stichhaltig zu begründen. Wie mit dem Risiko in dieser Zeit umzugehen ist, regelt 300-1 an zwei Stellen unterschiedlich: Nach Kap. 4.1.2 löst eine temporäre Nichterfüllung keine Risikobetrachtung aus; nach Kap. 2.11 ist für SOLLTE-Anforderungen, die in der Umsetzungsplanung enthalten, aber noch nicht erfüllt sind, eine Restrisikobetrachtung durchzuführen und das Risiko von der Institutionsleitung freizugeben (ähnlich Kap. 4.1.1). Das ist eine offene Auslegungsfrage, die sich mit Ihrer Zertifizierungsstelle klären lässt. Dauerhaft heißt, die Anforderung wird auf absehbare Zeit oder endgültig nicht erfüllt; dann ist eine Risikobetrachtung durchzuführen und das Restrisiko der Leitung zur Freigabe vorzulegen. KANN-Anforderungen sind optional.

Die Auslöser für eine eigene Risikobetrachtung haben sich verschoben. Nach 200-2 und 200-3 war sie unter anderem erforderlich bei hohem oder sehr hohem Schutzbedarf eines Zielobjekts, bei Zielobjekten, die mit Bausteinen nicht hinreichend modelliert werden können, und bei Einsatzszenarien, die der IT-Grundschutz nicht vorsieht. Nach 300-1 ist sie erforderlich, wenn ein Geschäftsprozess bei mindestens einem Schutzziel hohen Schutzbedarf hat, wenn ein relevantes Asset durch die Zielobjektkategorien nicht hinreichend abgedeckt ist und wenn eine anwendbare SOLLTE-Anforderung dauerhaft nicht erfüllt wird (Kap. 2.11). Der dritte Auslöser ist als ausdrücklicher Fall neu; 200-2 verlangte für nicht oder teilweise erfüllte Anforderungen, das damit verbundene Risiko in geeigneter Form zu ermitteln und zu dokumentieren (Kap. 8.4.3).

Das Verfahren selbst ist freier geworden, aber an Mindestkriterien gebunden. 200-3 beschreibt eine Matrix aus vier Häufigkeitsstufen (selten bis sehr häufig) und vier Schadensstufen (vernachlässigbar bis existenzbedrohend) und lässt alternativ andere etablierte Verfahren zu. 300-1 überlässt die Methode der Institution, verlangt aber die 35 Kriterien aus Anhang 3. Ein 200-3-Verfahren kann diese Kriterien erfüllen, muss aber geprüft werden, etwa auf Risikoappetit, Risikoeigentümer, Befristung temporärer Akzeptanz und Mindestangaben im Risikoregister.

Für die Rollen bringt 300-1 zwei Neuerungen, die im Alltag spürbar sind. Erstens den Risikoeigentümer: Jedes Risiko wird einem Risikoeigentümer zugewiesen, im Regelfall dem Eigentümer des Geschäftsprozesses (Kap. 4.2.1). In der Praxis werden das oft die Fachbereiche sein, die nach 200-2 schon als Informationseigentümer benannt sind (unsere Einschätzung). Sie autorisieren als Risikoeigentümer die Umsetzungsplanung; die Restrisiken gibt weiterhin die Institutionsleitung frei. Zweitens die Freigaben: Die Institutionsleitung gibt Anwendungsbereich, Schutzbedarf, Reihenfolge, Ressourcen und Leitlinie frei, die Risikoeigentümer autorisieren die Umsetzungsplanung.

Bei den Dokumenten gliedert 300-1 den Einstieg nach ISO/IEC 27001: Den ersten Prozessschritt ordnet er den Kapiteln 4 und 5 der Norm zu, mit Kontext der Institution, Compliance-Management und interessierten Parteien als eigenen Schritten. Vieles davon kannte 200-2 schon unter „Ermittlung von Rahmenbedingungen“ (Kap. 3.2.1), und Kap. 5.2.3 regelte Kennzeichnung, Version und Freigabe von Dokumenten. 300-1 verlangt zusätzlich ausdrücklich ein Verfahren zur Lenkung aller ISMS-relevanten Dokumente (Kap. 2.9). Den Begriff „Sicherheitskonzept“ verwendet 300-1 nicht; die Ergebnisse heißen Anforderungspaket, Umsetzungsplan und Risikoregister. Wie man daraus eine prüffähige Unterlage zusammenstellt, beschreibt die Seite zum Sicherheitskonzept.

Bei den Nachweisen ist die größte Änderung die Zuordnung pro Anforderung. Nach Kap. 4.3 sind für jede umzusetzende Maßnahme mindestens „die zugehörige Anforderung, das Datum der Umsetzung oder Überprüfung sowie die dokumentierende beziehungsweise prüfende Person“ festzuhalten. Automatisierte Prüfungen sind ausdrücklich vorgesehen. Das ändert die Planung: Statt einmal im Jahr Interviews zu führen, lassen sich Nachweise technischer Anforderungen laufend aus vorhandenen Werkzeugen ziehen, mit Werkzeug, Zeitpunkt und Ergebnis.