Grundschutz++ erklärt: Der neue BSI-Standard 300-1 und was sich für dein ISMS ändert | DevOps

Grundschutz++ erklärt: Der neue BSI-Standard 300-1 und was sich für dein ISMS ändert | DevOps | Tobias Weiss

Teil des Content-Index — siehe auch Compliance ohne Karussell: BSI C5:2026, NIST und CCM.

Quelle: BSI-Standard 300-1 „Methodik Grundschutz++" (PDF).

Am 26. Oktober 2026 hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) den BSI-Standard 300-1, die Methodik des Grundschutz++, veröffentlicht — der größte Umbau des IT-Grundschutzes in seiner 30-jährigen Geschichte. Bausteine und Absicherungsstufen weichen einem prozessorientierten ISMS mit maschinenlesbarem Anforderungskatalog. Zertifizierbar wird das ab 1. Januar 2027; der klassische IT-Grundschutz bleibt bis 30. November 2031 zertifizierbar.

Diagramm: Grundschutz++ ersetzt den bausteinbasierten IT-Grundschutz durch fünf PDCA-Prozessschritte — Erhebung & Planung, Anforderungsanalyse, Realisierung, Überwachung, kontinuierliche Verbesserung — gesteuert vom maschinenlesbaren Anforderungskatalog

Hintergrund: Warum es Grundschutz++ gibt

IT-Grundschutz ist die Basis-Methodik des BSI für Informationssicherheit — seit 30 Jahren die De-facto-Referenz für die deutsche öffentliche Verwaltung und zunehmend für Unternehmen, die für sie arbeiten. Der klassische Ansatz (Standards 200-1 bis 200-3 plus IT-Grundschutz-Kompendium) baut auf Bausteinen auf: Systeme in Bausteine einordnen, die zugehörigen Maßnahmen umsetzen, fertig. Das funktionierte — wurde aber unhandlich. Tausende Maßnahmen, Absicherungsstufen und ein statisches, dokumentenbasiertes Kompendium, das schwer aktuell zu halten und unmöglich zu automatisieren war.

Grundschutz++ ist die Antwort auf vier Entwicklungen:

Heterogene und virtualisierte IT — Cloud, Container und komplexe Virtualisierung passen nicht mehr in die „ein Baustein pro System"-Welt der 1990er.
Automatisierung — Regulierungen (NIS2, KRITIS-Dachgesetz) verlangen Nachweise, die prüfbar und automatisierbar sind, nicht Prosa in einem PDF.
ISO/IEC-27001-Ausrichtung — Institutionen brauchen zunehmend beides; eine Methodik, die sauber auf den internationalen Standard abbildet, spart doppelte Dokumentation.
Risikoorientierung — Einheitsmaßnahmen verschwenden Aufwand an Assets mit geringem Wert und schützen kritische Geschäftsprozesse unzureichend.

Was ist neu — auf einen Blick

Dimension	Klassischer IT-Grundschutz	Grundschutz++ (Standard 300-1)
Fokus	IT-Systeme / Bausteine	Geschäftsprozesse (Assets folgen)
Struktur	Kompendium, ~100+ Bausteine	5 PDCA-Prozessschritte
Katalog	Statische Dokumente	Maschinenlesbare Anforderungen (OSCAL)
Schutzbedarf	normal / hoch / sehr hoch	normal / hoch
Risikobetrachtung	Pflicht für alle	Implizit (BSI) für normal; explizit nur bei hoch
Methode	Feste BSI-Methode	Frei wählbar, 34 Mindestkriterien (Anhang 3)
Zertifizierung	Ab Tag eins	Ab 1. Jan 2027; Übergang bis 30. Nov 2031

Die fünf Prozessschritte (PDCA)

Grundschutz++ ist als Plan-Do-Check-Act-Zyklus mit genau fünf Prozessschritten organisiert. Jeder Schritt ist im Standard als formalisierte Anforderungen beschrieben — in derselben Satzschablone wie der gesamte Katalog:

Erhebung und Planung (P) — Kontext der Institution, Compliance-Management, Anwendungsbereich, Stakeholder-Analyse, Geschäftsprozesse, Schutzbedarfsfeststellung, Leitlinie, Rollen, Dokumentation, Initiierung der Risikobetrachtung.
Anforderungsanalyse (D) — Festlegung des Informationsverbunds, Asset-Erfassung, Auswahl von Blaupausen, Aufbau des individuellen Anforderungspakets, Konkretisierung von Parametern („Gestaltungsentscheidungen").
Realisierung (D) — Ermittlung des Umsetzungsstatus je Anforderung, Risikobetrachtung für nicht Abgedecktes, Umsetzungsplanung und Priorisierung, Zuständigkeiten und Fristen, Fortschrittsverfolgung.
Überwachung (C) — Leistungsbewertung des ISMS, internes Auditprogramm, Managementbewertungen, Monitoring-Methoden und -Tools, Validierung der Anforderungen.
Kontinuierliche Verbesserung (A) — Umgang mit Nicht-Konformitäten mit Ursachenanalyse, Verbesserungspotenziale, Korrektur- und Verbesserungsplan, Evaluation.

Anforderungskatalog: maschinenlesbare Anforderungen

Die radikalste Änderung ist der Anwenderkatalog, der das IT-Grundschutz-Kompendium ablöst. Er kommt im OSCAL-Format (dem offenen NIST-Datenmodell für Sicherheitskataloge), und jede Anforderung ist atomar mit strukturierten Metadaten:

Feld	Bedeutung	Beispiel / Werte
`id`, `title`	Eindeutige Kennung, z. B. `UMS.1.1`	~1.000 Anforderungen
`modal_verb`	Verbindlichkeit	MUSS (149) / SOLLTE (627) / KANN (224)
`sec_level`	Sicherheitsniveau	`normal-SdT` (Stand der Technik) / `erhöht`
`categories`	Zielobjektkategorien, an denen die Anforderung hängt	z. B. Anwendung, IT-System, Raum
`params`	Offene Parameter wie „regelmäßig" — Wert legst du fest	`<param>`-Platzhalter
`threats`	Verknüpfte elementare Gefährdungen (G 0.1 – G 0.47)	nachvollziehbare Kette zum Risiko
`effort_level`	0–5; 0 = zwingend, 1 = Quick Win … 5 = komplex	treibt die Priorisierung
`sec_data`	Wirkung auf Vertraulichkeit / Integrität / Verfügbarkeit	0–2 je Schutzziel

Drei Anforderungsarten:

MUSS — verbindlich. Nicht abdingbar, keine Risikoakzeptanz möglich. Eine Risikobetrachtung ersetzt die Erfüllung nie.
SOLLTE — erwartet. Eine temporäre Nichterfüllung braucht eine dokumentierte Begründung; eine dauerhafte Nichterfüllung löst eine Risikobetrachtung mit Freigabe der Restrisiken durch die Leitung aus.
KANN — optional, Niveau „erhöht"; ein Pool zusätzlicher Maßnahmen für die eigene Risikobetrachtung.

Die konkreten Zahlen (149 / 627 / 224) stammen aus unabhängigen Analysen des veröffentlichten OSCAL-Katalogs — der Standard liefert die Zählung maschinenlesbar im Datenmodell mit, nicht als Schlagzeile. Insgesamt sind es rund 1.000 Anforderungen; davon 773 auf dem Niveau „normal" (Stand der Technik), der Rest auf „erhöht".

Risikobetrachtung: implizit für normal, explizit für hoch

Grundschutz++ dreht das Risikomodell um:

Bei normalem Schutzbedarf hat das BSI das Risikodenken für dich übernommen — eine implizite Risikobetrachtung steckt im Katalog. Eine eigene Risikobetrachtung führst du für Normalprozesse nicht durch. Das ist die größte Arbeitsersparnis für die meisten Institutionen.
Bei Prozessen mit hohem Schutzbedarf führst du eine explizite Risikobetrachtung auf Ebene des Geschäftsprozesses und kritischer Assets entlang des Ressourcenpfads durch.
Die Methode ist frei wählbar (z. B. ISO/IEC 27005, ISO 31000), solange die 34 verbindlichen Mindestkriterien aus Anhang 3 erfüllt werden — vom Risikoappetit und den Akzeptanzkriterien (Kriterien 7 und 8) über die Pflichtfelder des Risikoregisters (15), den Risikoeigentümer (16) bis zur Freigabe der Restrisiken durch die Leitung (Kriterien 27 und 30).

Blaupausen und das Anforderungspaket

Statt „Bausteine auswählen" baust du jetzt ein Anforderungspaket aus drei Quellen:

Verpflichtende Methodik-Anforderungen (gelten für jeden Informationsverbund).
Technische und organisatorische Anforderungen, ausgewählt durch Zuordnung deiner Assets auf Zielobjektkategorien — eine Hierarchie, in der Elternknoten Anforderungen an Kindknoten vererben. Jedes Asset passt in mindestens eine Kategorie.
Ergänzende eigene Anforderungen, z. B. aus dem Compliance-Management oder der eigenen Risikobetrachtung.

Blaupausen sind vorgefertigte Ausschnitte des Katalogs für wiederkehrende Szenarien mit voreingestellten Parametern. Für bestimmte Institutionen kann es verpflichtende Blaupausen geben; sonst wählst du mehrere Blaupausen aus, dokumentierst die Auswahl und kombinierst sie. Eine einzelne Anforderung individualisierst du über Parameter („regelmäßig" → „vierteljährlich", „monatlich" …) bei der Paketerstellung.

Elementare Gefährdungen (G 0.1 – G 0.47)

Eine schlanke, technikneutrale Liste von 47 elementaren Gefährdungen ersetzt die ausufernden alten Gefährdungskataloge. Jede Anforderung im Katalog ist mit den Gefährdungen verknüpft, die sie mindert — du kannst also jederzeit nachvollziehen, warum eine Anforderung existiert, und die Zuordnung für eigene Risikobetrachtungen wiederverwenden. Die Gefährdungen folgen den klassischen Gruppen: höhere Gewalt, organisatorische Mängel, menschliche Fehlhandlungen, technisches Versagen und vorsätzliche Handlungen.

Was das in der Praxis bedeutet

Für bereits nach klassischem IT-Grundschutz zertifizierte Institutionen: Du hast eine Übergangszeit bis 30. November 2031. Keine Panik-Migration — aber starte eine Delta-Analyse; die meisten Nachweise tragen über, und die ISO/IEC-27001-Ausrichtung bedeutet, dass deine bestehende ISMS-Dokumentation fast 1:1 abbildet.

Für Neueinsteiger: Das ist der günstigste saubere Einstieg, den das BSI je angeboten hat — die implizite Risikobetrachtung für die 90 % deiner Prozesse mit „normalem" Schutzbedarf beseitigt den historisch größten Blocker auf dem Weg zur Zertifizierung.

Für Tool- und GRC-Anbieter: Der OSCAL-Katalog ist der eigentliche Preis. Anforderungen sind jetzt Daten: automatisch filtern, priorisieren und mappen — kein Scraping mehr von 2.000-Seiten-PDFs. Standards geben das Modell vor; der Markt baut jetzt die Werkzeuge.

Zeitplan:

Datum	Ereignis
20. Okt 2026	Standard 300-1 v1.0 veröffentlicht (PDF)
26. Okt 2026	BSI-Ankündigung
1. Jan 2027	Zertifizierung nach Grundschutz++ möglich
Q1 2027	Ergänzungsschulungen für zertifizierte Berater/Auditteamleiter
31. Dez 2027	Ende der Early-Adopter-Phase
30. Nov 2031	Ende der Zertifizierung nach klassischem IT-Grundschutz

Fazit: Grundschutz++ ist kein Facelift — es ist ein anderes Betriebsmodell für deutsche Informationssicherheit: prozessorientiert statt bausteinbasiert, maschinenlesbar statt dokumentenbasiert, risikogerecht statt einheitlich. Wenn deine Institution irgendwo im deutschen Public Sector, unter NIS2 oder KRITIS lebt, ist das der Standard, gegen den du im nächsten Jahrzehnt zertifizieren wirst.

14. November 2026. Lies den Standard selbst: BSI-Standard 300-1 „Methodik Grundschutz++" (PDF). Zur Cloud-Seite deutscher Compliance: C5:2026, NIST und CCM.