BSI-Standard 300-1: Was die Methodik zu Grundschutz++ verlangt und wie Sie damit arbeiten

Die Tabelle ordnet jedem Kapitel zu, was Sie dort entscheiden oder festlegen und welche Unterlage dabei entsteht. Sie folgt dem Text von 300-1; die Spalte „Unterlage“ fasst zusammen, was der Standard zu dokumentieren verlangt, in welcher Form, lässt er meist offen.

Lesepfad für den ersten Durchgang:

1. Kapitel 2.10 und 2.6 zuerst: Sie zeigen, was die Leitung entscheiden muss und wie der Schutzbedarf je Geschäftsprozess bestimmt wird.
2. Anhang 2 und Kapitel 2.5: Geschäftsprozesse in der einfachsten zulässigen Form erfassen und den Startprozess wählen.
3. Kapitel 3.1 bis 3.5 mit Anhang 1: Verbund abgrenzen, Assets den Zielobjektkategorien zuordnen, Anforderungspaket bilden.
4. Kapitel 4.1 und 4.3: Umsetzungsstatus prüfen, Maßnahmen und Nachweise zuordnen.
5. Kapitel 2.11, 4.2 und Anhang 3, sobald ein Auslöser für eine explizite Risikobetrachtung vorliegt; danach Kapitel 5 und 6 für den laufenden Betrieb.

Den Schutzbedarf stellt die Institution je Geschäftsprozess fest, bezogen auf Vertraulichkeit, Integrität und Verfügbarkeit der dort verarbeiteten Informationen (Kapitel 2.6). Geschäftsprozesse kannte schon BSI-Standard 200-2: Dort wurde der Schutzbedarf zuerst für Geschäftsprozesse und Anwendungen bestimmt und dann auf IT-Systeme, Räume und Kommunikationsverbindungen vererbt, in drei Kategorien. Neu in 300-1 ist, dass der Schutzbedarf je Geschäftsprozess mit nur noch zwei Kategorien festgestellt wird: „normal“ („die Auswirkungen sind begrenzt und überschaubar“) und „hoch“ („die Auswirkungen können beträchtlich sein“), so Kapitel 2.6. Eigene, zusätzliche Kategorien sind erlaubt, müssen aber auf diese beiden abgebildet werden. Für ein zertifizierbares ISMS ist in der niedrigsten Kategorie immer der Stand der Technik einzuhalten.

Bei der ersten Einführung empfiehlt der Standard, mit dem wichtigsten Geschäftsprozess der höchsten Schutzbedarfskategorie zu beginnen. Die übrigen Geschäftsprozesse des Anwendungsbereichs sind danach schrittweise zu untersuchen. Ein ISMS muss also nicht mit einer vollständigen Modellierung der ganzen Institution starten.

Auch die Dokumentation richtet sich nach dem Schutzbedarf (Kapitel 3.2). Bei normalem Schutzbedarf verlangt der Standard nur die Abhängigkeiten zwischen Anwendungen und IT-Systemen sowie zwischen IT-Systemen und Räumen. Die Zugehörigkeit der Assets zum Geschäftsprozess mit ihren wesentlichen Abhängigkeiten ist nur bei hohem Schutzbedarf gefordert. Vorhandene CMDBs, Asset-Register, Betriebshandbücher, Netzpläne oder Service Maps dürfen genutzt werden.

Wie Sie die Kategorien begründet vergeben und alte Einstufungen aus drei Kategorien prüfen, zeigt die Seite Schutzbedarfsfeststellung; die Abgrenzung des Verbunds und die Erhebung der Assets behandeln Informationsverbund und Strukturanalyse.

Die Assets werden Zielobjektkategorien zugeordnet. Anhang 1 des Standards definiert 39 Kategorien, von Standorten über Nutzende, Netze und IT-Systeme bis zu Anwendungen mit Unterkategorien wie Verzeichnisdiensten oder Webanwendungen; Cloud-Dienste ordnet der Standard unter Outsourcing ein. Die übergeordneten Kategorien gelten jeweils mit (Kapitel 3.4.2). Aus den zugeordneten Kategorien ergeben sich die Anforderungen.

Das individuelle Anforderungspaket besteht aus drei Teilen (Kapitel 3.4): den Methodik-Anforderungen, die für jeden Informationsverbund gelten, den technischen und organisatorischen Anforderungen ohne Zielobjektkategorie, die immer aufzunehmen sind, und den Anforderungen der zugeordneten Kategorien. Im Build vom 29. Oktober 2026 sind das 95 Methodik-Anforderungen, 265 technische und organisatorische Anforderungen ohne und 636 mit Zielobjektkategorie, dazu vier Anforderungen zum Risikomanagement (eigene Auszählung). Hinzu kommen Blaupausen, also vorgefertigte Kataloge für bestimmte Anwendungsszenarien mit vorgegebenen Parametern, und eigene Ergänzungen etwa aus dem Compliance-Management. Für bestimmte Institutionen kann es laut Standard verpflichtende Blaupausen geben.

Viele Anforderungen enthalten Parameter, zum Beispiel „regelmäßig“. Die Institution legt sie bei oder nach der Erstellung des Pakets fest. Der Standard weist ausdrücklich darauf hin, dass solche Parameter auch für automatisierte Prüfungen genutzt werden können.

Ein durchgerechnetes Zuordnungsbeispiel mit Vererbung steht auf der Seite Modellierung mit Zielobjektkategorien, welche Katalogdatei Sie dafür nehmen, erklärt Anwenderkatalog Grundschutz++.

Für jede Anforderung im Paket wird der Umsetzungsstatus vollständig geprüft (Kapitel 4.1.1). Er lautet „erfüllt“, „nicht erfüllt“ oder „nicht anwendbar“; eine Nichtanwendbarkeit ist zu begründen. Ein „teilweise“ sieht der Standard nicht vor. Der IT-Grundschutz-Check nach BSI-Standard 200-2 kannte dagegen noch die Werte „teilweise“ und „entbehrlich“.

Was bei einer nicht erfüllten Anforderung passiert, hängt vom Modalverb ab (Kapitel 4.1.2):

• MUSS: Es sind Maßnahmen zur Erfüllung festzulegen. Eine Risikobetrachtung ersetzt die Erfüllung nicht; der Standard hält fest: „Eine Ausnahmegenehmigung oder Risikoakzeptanz ist nicht möglich.“
• SOLLTE: Die Nichterfüllung wird als temporär oder dauerhaft eingeordnet. Temporär heißt, die Erfüllung ist geplant; dann ist die Nichterfüllung stichhaltig zu begründen. Kapitel 4.1.2 sagt, eine temporäre Nichterfüllung löse keine Risikobetrachtung aus. Kapitel 2.11 verlangt für SOLLTE-Anforderungen, die in der Umsetzungsplanung enthalten, aber noch nicht erfüllt sind, eine Restrisikobetrachtung und die Freigabe des Risikos durch die Institutionsleitung; Kapitel 4.1.1 verlangt, das Risiko zu identifizieren und der Leitung mitzuteilen. Wie beide Stellen zusammenpassen, ist eine offene Auslegungsfrage. Wer auf der sicheren Seite bleiben will, identifiziert das Restrisiko, teilt es der Leitung mit und lässt es von ihr freigeben. Dauerhaft heißt, die Anforderung wird auf absehbare Zeit nicht erfüllt; dann ist eine Risikobetrachtung durchzuführen, und das Restrisiko geht zur Freigabe an die Institutionsleitung. Häufen sich dauerhafte Nichterfüllungen, kann laut Standard der Stand der Technik insgesamt verfehlt werden; in einer Zertifizierung droht dann eine erhebliche Abweichung (Kapitel 4.1.2).
• KANN: Anforderungen mit dem Sicherheitsniveau „erhöht“ sind optional. Sie dienen als Fundus für zusätzliche Maßnahmen in der Risikobetrachtung.

Wie Sie Musterfälle für jedes Modalverb dokumentieren, zeigt die Seite Anforderungen bewerten und Abweichungen dokumentieren.

Dem Anwenderkatalog liegt eine allgemeine Risikobetrachtung des BSI zugrunde. Bei normalem Schutzbedarf müssen Institutionen deshalb keine eigene durchführen (Kapitel 2.11). Pflicht ist sie in drei Fällen: 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.

Die Methode ist frei wählbar, genannt werden etwa ISO/IEC 27005 und ISO 31000. Sie muss aber die 35 verbindlichen Mindestkriterien aus Anhang 3 erfüllen. Dazu gehören ein festgelegter Risikoappetit, Risikoakzeptanzkriterien, ein Risikoeigentümer für jedes Risiko, Mindestangaben im Risikoregister, die Autorisierung der Restrisiken durch die Institutionsleitung, eine Befristung temporär akzeptierter Risiken und eine Überprüfung mindestens einmal im Jahr. Als Ausgangspunkt dienen die 47 elementaren Gefährdungen G 0.1 bis G 0.47; an den technischen und organisatorischen Anforderungen im Katalog steht die Kennung der Gefährdung, der sie entgegenwirkt (Anhang 4).

Einen bearbeiteten Risikofall vom Anlass bis zur Behandlung finden Sie unter Risikoanalyse, die 35 Kriterien mit Prüffrage und benötigtem Beleg unter Mindestkriterien für die Risikobetrachtung.

Für die Ermittlung des Umsetzungsstatus nennt der Standard Verfahren von Interviews und Dokumentenprüfungen bis zu automatisierten Konfigurationsprüfungen und technischen Scans (Kapitel 4.1). Die zur Beurteilung herangezogenen Nachweise sind der jeweiligen Maßnahme eindeutig zuzuordnen. Bei automatisierter Prüfung sind das eingesetzte Werkzeug, der Prüfzeitpunkt und das Ergebnis zu dokumentieren; erzeugt das Werkzeug einen Prüfbericht, ist er der Maßnahme und der Anforderung zuzuordnen (Kapitel 4.3).

Die Grundlage dafür ist der maschinenlesbare Katalog im Format OSCAL als JSON. Die Stand-der-Technik-Bibliothek, in der er liegt, löst laut BSI das IT-Grundschutz-Kompendium ab. Im Build vom 29. Oktober 2026 (Commit c3f37859) umfasst der Anwenderkatalog 1.000 Anforderungen in 20 Praktiken, davon 773 auf dem Sicherheitsniveau „normal-SdT“ und 227 auf „erhöht“ (eigene Auszählung über alle Verschachtelungsebenen am 1. November 2026). In der Bibliothek liegen außerdem Zuordnungstabellen von ISO/IEC 27001:2022 Annex A und vom IT-Grundschutz-Kompendium 2023 auf Grundschutz++.

Wie Sie festlegen, wer welchen Nachweis wann liefert, zeigt der Nachweisplan.

Das BSI führt einen Meilensteinplan, den es laufend anpasst. Für die Arbeit mit 300-1 zählen nach dem Stand Oktober 2026 vor allem drei Termine:

• 01.01.2027: Anträge auf Zertifizierung nach ISO 27001 auf Basis von Grundschutz++ möglich
• 1. Quartal bis 31.12.2027: Early-Adopter-Phase
• 30.11.2031: Ende der Zertifizierbarkeit des klassischen IT-Grundschutz

Zwischen dem 1. Januar 2027 und dem 30. November 2031 können Institutionen also wählen, ob sie nach dem klassischen IT-Grundschutz oder nach Grundschutz++ zertifizieren. Das Ende der Zertifizierbarkeit ist eine Festlegung im Meilensteinplan des BSI, keine gesetzliche Frist. Alle Termine mit Status und Folge stehen im Terminregister zu Grundschutz++.

Nach § 30 Abs. 2 BSIG sollen die Maßnahmen wichtiger und besonders wichtiger Einrichtungen den Stand der Technik einhalten und die einschlägigen europäischen und internationalen Normen berücksichtigen. Ein bestimmtes Rahmenwerk schreibt die Vorschrift nicht vor. Grundschutz++ ist damit einer von mehreren Wegen. Ob er für die eigene Einrichtung der passende ist, hängt vom Einzelfall ab, etwa davon, ob Auftraggeber aus dem öffentlichen Sektor einen Grundschutz-Nachweis erwarten. Die NIS2-Umsetzung selbst behandelt Blackfort Technology auf https://www.blackfort-tec.de/consulting-pages/nis2-umsetzung.

Wer heute ein Zertifikat nach ISO 27001 auf Basis von IT-Grundschutz hat, muss nicht sofort umstellen. Aus unserer Sicht spricht viel dafür, die Umstellung mit dem nächsten Re-Zertifizierungszyklus zu planen. Wer dagegen erst 2027 oder später ein ISMS zertifizieren lassen will, sollte aus unserer Sicht gleich nach 300-1 beginnen, sonst steht absehbar vor 2031 eine Migration an.

300-1 selbst erwähnt weder die Standards 200-1 bis 200-3 noch die bisherigen Vorgehensweisen Basis-, Kern- und Standard-Absicherung. Ob diese Varianten unter Grundschutz++ fortbestehen, lässt der Standard offen. Zum BSI-Standard 200-4 (Business Continuity Management) trifft 300-1 keine Aussage; ein BCMS nennt er nur als mögliche Quelle für die Identifizierung der Geschäftsprozesse (Kapitel 2.5).

Welche Änderungen Ihre Arbeit konkret betreffen, zeigt der Vergleich IT-Grundschutz 2023 und Grundschutz++; welcher Umstiegsweg zu Ihrer Ausgangslage passt, die Seite Umstieg entscheiden; die Arbeitspakete einer Überführung beschreibt Migration nach Grundschutz++.

1. Rahmen entscheiden und der Leitung vorlegen. Klären Sie, ob Sie beim klassischen IT-Grundschutz bleiben, nach ISO 27001 ohne Grundschutz-Bezug arbeiten oder auf Grundschutz++ gehen, und bis wann. Bei einem bestehenden Zertifikat sollte sich der Zeitplan am Re-Zertifizierungstermin ausrichten. Die Entscheidung gehört zur Institutionsleitung, weil sie Anwendungsbereich und Ressourcen freigibt.
2. Geschäftsprozesse erfassen. Wo keine Prozesslandkarte vorliegt, genügt nach Anhang 2 eine einfache Tabelle mit Kennung, Name, verantwortlicher Stelle, Kurzbeschreibung und wesentlichen Anwendungen. Bestimmen Sie den Schutzbedarf je Prozess und wählen Sie den Prozess, mit dem Sie beginnen.
3. Risikomethode gegen die Mindestkriterien prüfen. Ob Sie nach 200-3, ISO/IEC 27005 oder einer eigenen Methode arbeiten: Gleichen Sie Verfahren, Rollen, Kriterien und Risikoregister mit den 35 Kriterien aus Anhang 3 ab. Prüfen Sie dabei besonders, ob Risikoappetit und Akzeptanzkriterien festgelegt und von der Leitung autorisiert sind und ob temporär akzeptierte Risiken eine Befristung haben (Kriterien 7, 8, 9 und 28).
4. Bestehende Dokumentation über die Zuordnungstabellen abgleichen. Wer ein ISMS nach dem Kompendium 2023 oder nach ISO 27001 betreibt, kann über die Zuordnungstabellen des BSI eine erste Abdeckung ermitteln: welche Grundschutz++-Anforderungen schon bedient sind und wo neue hinzukommen. Die Tabelle zum Kompendium 2023 hat den Status Entwurf („draft“), ihre Zuordnungen sind deshalb fachlich zu prüfen; die Tabelle zu ISO 27001 deckt nur die Maßnahmen aus Annex A ab.
5. Nachweise automatisieren, wo es technisch geht. Patchstand, Mehr-Faktor-Authentisierung, Protokollierung oder Härtung lassen sich oft aus vorhandenen Werkzeugen belegen. Halten Sie fest, welches Werkzeug wann welches Ergebnis geliefert hat, und ordnen Sie es der Maßnahme und der Anforderung zu.
6. Den Statuswert „nicht anwendbar“ sauber begründen. Weil Anforderungen ohne Zielobjektkategorie immer ins Paket kommen, braucht jede Nichtanwendbarkeit eine nachvollziehbare Begründung. Das ist für eine spätere Zertifizierung prüfbar.

Termine zur Personenzertifizierung als GS++-Berater und GS++-Auditteamleiter führt das Terminregister zu Grundschutz++.

300-1 erleichtert den Einstieg und zieht an einigen Stellen klare Grenzen. Eine Institution kann mit einem Geschäftsprozess beginnen, braucht eine explizite Risikobetrachtung nur in drei benannten Fällen und darf vorhandene Asset-Daten nutzen. Gleichzeitig kennen MUSS-Anforderungen keine Ausnahme, eine Nichtanwendbarkeit wird begründet im Status festgehalten und die Anforderung bleibt im Paket, und die Risikomethode ist an feste Mindestkriterien gebunden. Der maschinenlesbare Katalog und die ausdrücklich zugelassenen automatisierten Prüfungen machen es möglich, Nachweise laufend aus dem Betrieb zu ziehen.

Diese Seite ordnet den Standard fachlich ein und ist keine Rechtsberatung; Blackfort Technology ist keine Rechtsanwaltskanzlei. Ob und wie die Vorgaben im Einzelfall gelten, klären Sie bitte mit einer dazu befugten Stelle, etwa Ihrer Rechtsabteilung.

Wenn Sie den Abgleich Ihres ISMS mit 300-1 nicht allein angehen möchten: Was das Team von Blackfort Technology dazu anbietet, steht auf der Seite Beratung zu IT-Grundschutz und Grundschutz++.