BSI 300-1 vs. 200-1: Was Grundschutz++ verändert

Der BSI-Standard 300-1 „Methodik Grundschutz++“, Version 1.0 vom 20. Oktober 2026 und am 27. Oktober auf der it-sa vorgestellt, beschreibt auf 42 Seiten Aufbau und Betrieb eines ISMS in fünf Prozessschritten. Er bündelt, was bisher auf 200-1, 200-2 und 200-3 verteilt war. Die Sicherheitsanforderungen liegen nicht im PDF, sondern als maschinenlesbarer OSCAL-Katalog auf GitHub. Anforderungen, Zuordnungen und Katalog-Updates werden damit zu Daten.

Den Hintergrund zu Grundschutz++ und zum geplanten Umstieg liefert der KaitoSec-Überblick zu Grundschutz++. Hier geht es um das, was mit dem 300-1 jetzt konkret vorliegt.

Was regelt der BSI-Standard 300-1?

Der BSI-Standard 300-1 regelt die Methodik von Grundschutz++ (GS++): Aufbau und Betrieb eines ISMS in fünf Prozessschritten entlang des PDCA-Zyklus, von der Erhebung und Planung bis zur kontinuierlichen Verbesserung. Er richtet sich in erster Linie an Early Adopters, also erfahrene Institutionen, deren Erfahrungen in die Weiterentwicklung einfließen. Entwickelt wurde die Methodik mit der Grundschutz-Community, erprobt in ausgewählten Pilotierungsinstitutionen.

Die fünf Prozessschritte im Einzelnen:

1. Erhebung und Planung: Kontext, Anwendungsbereich, Stakeholder, Geschäftsprozesse, Schutzbedarf, Leitlinie und Rollen. Der Schritt deckt die Aktivitäten aus Kapitel 4 und 5 der ISO/IEC 27001 ab.
2. Anforderungsanalyse: Informationsverbund abgrenzen, Assets erfassen, Zielobjektkategorien zuordnen, Blaupausen (vorgefertigte Anforderungskataloge, etwa für bestimmte Asset-Gruppen) auswählen und das Anforderungspaket bilden. Hier liegen die Kapitel 6 und 10 der ISO/IEC 27001.
3. Realisierung: Umsetzungsstatus je Anforderung bewerten („erfüllt“, „nicht erfüllt“, „nicht anwendbar“), Risiken betrachten, Umsetzungsplan mit Zuständigkeiten und Fristen.
4. Überwachung: Leistungsbewertung, internes Auditprogramm, Managementbewertung, Monitoring und Validierung der Anforderungen.
5. Kontinuierliche Verbesserung: Nichtkonformitäten bearbeiten, Korrektur- und Verbesserungsplan, Wirksamkeit bewerten.

Der Einstieg ist bewusst schlank. Die Schutzbedarfsfeststellung beginnt bei den Geschäftsprozessen, und das BSI empfiehlt, mit dem wichtigsten Prozess der höchsten Schutzbedarfskategorie zu starten. Wer keine Prozesslandkarte hat, findet in Anhang 2 eine vereinfachte Geschäftsprozessanalyse mit fünf Angaben pro Prozess: ID, Name, fachlich verantwortliche Person, Rolle oder Organisationseinheit, Kurzbeschreibung, wesentliche Anwendungen. Die Beschreibung soll laut Standard „so einfach wie möglich und so genau wie nötig“ sein. Wie die Schutzbedarfsfeststellung bisher nach 200-2 läuft, beschreibt die KaitoSec-Wissensbasis zur Schutzbedarfsfeststellung.

Worin unterscheidet sich 300-1 von 200-1?

Der 200-1 ist ein Rahmenstandard, der 300-1 eine Prozessmethodik. Der 200-1 „Managementsysteme für Informationssicherheit“ stammt aus dem Oktober 2017 und beschreibt auf 48 Seiten, was ein ISMS ausmacht. Für das konkrete Vorgehen verweist er auf den 200-2, für die Risikoanalyse auf den 200-3. Inhaltlich ist der 300-1 deshalb das Gegenstück zu 200-1 bis 200-3, nicht nur zum 200-1.

Thema	BSI-Standard 200-1 (2017)	BSI-Standard 300-1 / GS++ (2026)
Charakter	Rahmenstandard: was ein ISMS ausmacht	Prozessmethodik in fünf Schritten im PDCA-Zyklus
Vorgehensweise	Verweist auf 200-2 (Basis-, Standard-, Kern-Absicherung)	Im Standard enthalten, eine einheitliche Methodik
Risiko	Implizite Risikobewertung bei normalem Schutzbedarf, explizite Analyse nach 200-3	Gleiches Prinzip, Methode frei wählbar, 35 verbindliche Mindestkriterien (Anhang 3)
ISO/IEC 27001	Kompatibel, eigene Gliederung	Prozessschritte 1 und 2 nennen die Normkapitel direkt (4/5 bzw. 6/10)
Anforderungen	IT-Grundschutz-Kompendium	Anwenderkatalog GS++ als OSCAL/JSON auf GitHub, CC BY-SA 4.0
Modellierung	Bausteine werden Zielobjekten zugeordnet	Praktiken und Zielobjektkategorien in einer vererbenden Hierarchie
Schutzbedarfskategorien	Drei: normal, hoch, sehr hoch	Zwei: normal, hoch
Adressaten	Alle Institutionen	In erster Linie Early Adopters

Leitlinie, Rollen und die nicht delegierbare Verantwortung der Institutionsleitung aus dem 200-1 finden sich im 300-1 in Prozessschritt 1, Managementbewertung und Verbesserung in den Schritten 4 und 5. Die Unterscheidung in Basis-, Standard- und Kern-Absicherung aus dem 200-2 kommt im 300-1 nicht mehr vor. Wer heute noch nach dieser Logik arbeitet, findet im Überblick zu den drei Vorgehensweisen die Einordnung. Einen Ablösungstermin nennt der 300-1 selbst nicht; laut der Grundschutz++-Seite des BSI endet die Zertifizierbarkeit nach klassischem IT-Grundschutz am 30. November 2031. Der BSI-Standard 200-4 zum Business Continuity Management bleibt davon unberührt.

Was ändert Grundschutz++ bei Modellierung und Risikobetrachtung?

Grundschutz++ ersetzt die Bausteine durch zwei Ordnungen: Praktiken bündeln die Anforderungen thematisch, Zielobjektkategorien bestimmen, welche Anforderungen für ein Asset gelten. Die Kategorien stehen in einer Eltern-Kind-Hierarchie, und ein Asset erbt die Anforderungen aller übergeordneten Kategorien. Anforderungen ohne Kategoriebezug gelten ohnehin.

Das BSI nennt in Anhang 1 „E-Mail“ als Kind von „Interpersonelle Kommunikationsanwendungen“, die wiederum unter „Anwendungen“ liegen. Die Zuordnungslogik, die bisher über die IT-Grundschutz-Modellierung lief, steckt damit im Datenmodell.

Beim Risiko bleibt das Grundprinzip, das schon der 200-1 beschreibt: Bei normalem Schutzbedarf müssen Anwender keine eigene Risikobetrachtung durchführen, weil dem Katalog bereits eine Risikobetrachtung des BSI zugrunde liegt. Neu ist, dass sie sichtbar wird. Die technischen und organisatorischen Anforderungen tragen die Kennung der elementaren Gefährdungen (G 0.1 bis G 0.47), gegen die sie wirken. Eine explizite Risikobetrachtung wird in drei Fällen fällig:

• bei hohem Schutzbedarf,
• bei Assets, die keine Zielobjektkategorie hinreichend abdeckt,
• bei dauerhaft nicht erfüllten SOLLTE-Anforderungen.

Die Methode wählt die Institution selbst, der Standard nennt ISO/IEC 27005 und ISO 31000 als Beispiele. Neu sind die 35 verbindlichen Mindestkriterien in Anhang 3, die jede Methode erfüllen muss. Wer bisher nach dem BSI-Standard 200-3 vorgeht, gleicht seine Methode gegen diese Kriterien ab. Risikoeigentümer ist, sofern nichts anderes festgelegt ist, der Eigentümer des betroffenen Geschäftsprozesses.

Klar geregelt ist der Umgang mit den Modalverben. Eine MUSS-Anforderung lässt sich weder durch Risikoakzeptanz noch durch eine Ausnahmegenehmigung ersetzen. Bei SOLLTE-Anforderungen unterscheidet der Standard zwischen temporärer und dauerhafter Nichterfüllung. Nur die dauerhafte löst eine vollständige Risikobetrachtung aus; auch bei temporärer Nichterfüllung ist das Restrisiko zu betrachten und von der Institutionsleitung freizugeben. KANN-Anforderungen bilden das Sicherheitsniveau „erhöht“ und können für die Risikobetrachtung herangezogen werden.

Warum ist OSCAL für Grundschutz++ mehr als ein Dateiformat?

OSCAL macht die Anforderungen von Grundschutz++ zu Daten: Anforderungspaket, Katalog-Updates, Prüfungen und eigene Profile lassen sich als Abfrage, Versionsvergleich oder Skript bearbeiten statt in Word und Excel. Der Anwenderkatalog liegt dafür in der Stand-der-Technik-Bibliothek des BSI auf GitHub, als OSCAL-JSON unter CC BY-SA 4.0.

OSCAL steht für Open Security Controls Assessment Language und stammt vom NIST. Das Repository hat drei Ebenen:

• Control Layer: Kataloge, Profile, aufgelöste Kataloge und Mappings. Hier liegt Grundschutz++-resolved_catalog.json, der direkt nutzbare Gesamtkatalog. Daneben stehen weitere BSI-Vorgaben im selben Format, etwa WLAN, Lieferkettensicherheit, Risikomanagement und ein Entwurf des Mindeststandards TLS, sowie Mappings vom IT-Grundschutz-Kompendium 2023 und von ISO/IEC 27001:2022 Anhang A auf GS++.
• Implementation Layer: wiederverwendbare Komponentendefinitionen, also Beschreibungen, wie Anforderungen konkret umgesetzt werden.
• Assessment Layer: vorgesehen für maschinenlesbare Prüfartefakte wie Prüfpläne und Prüfergebnisse, derzeit noch leer.

Damit werden vier Arbeitsschritte, die bisher Handarbeit waren, zu Datenoperationen:

1. Anforderungspaket erzeugen. Sind die eigenen Assets den Zielobjektkategorien zugeordnet, ist die Kette Asset → Zielobjektkategorie → Anforderungen eine Abfrage über den Katalog.
2. Katalog-Updates nachvollziehen. Katalogstände sind im Repository versioniert. Mit einem Versionsvergleich, per Git oder mit OSCAL-Diff-Werkzeugen, lässt sich ermitteln, welche Anforderungen sich geändert haben. Liegt die eigene Zuordnung maschinenlesbar vor, zeigt sich auch, welche Assets betroffen sind.
3. Prüfungen automatisieren. Parameter in den Anforderungen (z. B. „regelmäßig“) können laut Kapitel 3.5 auch für automatisierte Prüfungen genutzt werden. Erfolgt eine Prüfung automatisiert, sind nach Kapitel 4.3 Tool, Zeitpunkt und Ergebnis zu dokumentieren.
4. Eigene Profile pflegen. Ein OSCAL-Profil wählt Anforderungen aus, belegt Parameter vor und bleibt auf den Quellkatalog rückführbar. Branchenverbände, Konzerne oder Dienstleister können so eigene Profile synchron zum BSI-Katalog halten.

Das schafft technische Möglichkeiten, keine automatische Compliance. Für einen lesbaren Einstieg ohne eigenes Tooling gibt es den Stand-der-Technik-Viewer der Community.

Welche Grundlagen braucht die Umstellung auf Grundschutz++?

Die Umstellung auf Grundschutz++ braucht vor allem saubere, auswertbare Daten: ein gepflegtes Asset-Inventar, dokumentierte Geschäftsprozesse mit benannter Verantwortung, versionierte Katalogstände, eine Prüfinfrastruktur und eine Maßnahmenverfolgung mit Zuständigkeiten und Fristen. Fehlt eine dieser Grundlagen, bleibt der maschinenlesbare Katalog weitgehend ungenutzt.

• Asset-Inventar. Die Zuordnung zu Zielobjektkategorien funktioniert nur, wenn Assets vollständig und aktuell erfasst sind. Der Standard nennt CMDBs, Asset-Register und Service Maps als Quellen. Sinnvoll ist, dass die Daten auswertbar vorliegen, als Export oder per API.
• Geschäftsprozesse. Das Minimum aus Anhang 2, mit einer fachlich verantwortlichen Stelle, die in der Regel auch das Risiko trägt.
• Versionierung. Der Katalog kommt als Repository. Katalogstände vergleichen und Änderungen auf die eigenen Objekte abbilden gehört damit zum Handwerkszeug, ob per Skript oder Werkzeug.
• Prüfinfrastruktur. Konfigurationsmanagement, Compliance-Scanner oder Pipelines, die Soll-Werte aus den Parametern gegen den Ist-Zustand prüfen und Nachweise mit Zeitstempel ablegen.
• Maßnahmenverfolgung. Kapitel 4.4 nennt ein Projektmanagement- oder Ticketsystem als geeigneten Ort für Zuständigkeiten und Fristen.

Nichts davon ist exotisch. In vielen Häusern liegen Asset-Daten, Prozessdokumentation und Maßnahmen aber in getrennten Silos mit unterschiedlichem Pflegestand. Die Methodik lässt sich dann weiter in Tabellen abarbeiten, der Hauptvorteil des neuen Formats bleibt aber ungenutzt. Die Alternative ist eine ISMS-Plattform, die Inventar, Risiken, Maßnahmen und Nachweise auf einer gemeinsamen Datenbasis führt. KaitoSec ist so aufgebaut und arbeitet mit OSCAL-basierten Katalogen für BSI IT-Grundschutz.

Ein realistischer erster Schritt ist ein begrenzter Pilot: den Grundschutz++-resolved_catalog.json laden, die Assets eines einzelnen Geschäftsprozesses den Zielobjektkategorien aus Anhang 1 zuordnen und das entstehende Anforderungspaket mit dem heutigen Baustein-Mapping vergleichen. So werden Datenlücken sichtbar, bevor die Methodik produktiv geht. Wer noch mit dem klassischen Kompendium arbeitet, kann den Grundschutz-Starter von KaitoSec als Ausgangspunkt nutzen. Was beim Wechsel der Software zu beachten ist, beschreibt der Artikel zur Ablösung von IT-Grundschutz-Software.

Was ist bei Grundschutz++ noch offen?

Für die Leistungsbewertung des ISMS gibt es noch keine einheitlichen Vorgaben; das BSI schreibt, deren Entwicklung stehe aus, die Institutionen seien bis dahin frei. Ein Zertifizierungsschema für GS++ regelt der 300-1 nicht. Den Zeitplan veröffentlicht das BSI separat auf seiner Grundschutz++-Seite: Zertifizierungsanträge für ISO 27001 auf Basis von GS++ sind ab dem 1. Januar 2027 möglich, die Early-Adopter-Phase beginnt im 1. Quartal 2027, und die Zertifizierbarkeit des klassischen IT-Grundschutz endet am 30. November 2031. Organisationen sollten diese Termine in ihre Roadmap aufnehmen und die Veröffentlichungen des BSI verfolgen.

Wenn Sie einschätzen möchten, wie Ihr bestehendes ISMS, Ihr Asset-Inventar und Ihre Maßnahmenverfolgung zu GS++ passen, besprechen Sie das in einer Demo mit KaitoSec.

Häufig gestellte Fragen zu BSI 300-1 und Grundschutz++

Ersetzt der BSI-Standard 300-1 den 200-1 sofort?

Nein. Der 300-1 selbst nennt keinen Ablösungstermin. Laut BSI bleibt der klassische IT-Grundschutz bis zum 30. November 2031 zertifizierbar, Zertifizierungen auf Basis von GS++ sind ab dem 1. Januar 2027 möglich. Wer nach 200-1 bis 200-3 arbeitet, hat damit Zeit, GS++ parallel in einem Pilot zu erproben.

Muss ich für Grundschutz++ OSCAL selbst programmieren?

Nein. OSCAL ist das Veröffentlichungsformat des Katalogs. Entscheidend sind nachvollziehbare Assets und Zuordnungen zu Zielobjektkategorien. Ob Sie die Daten mit einem Werkzeug, über Schnittstellen oder mit eigenen Skripten verarbeiten, ist eine Umsetzungsentscheidung. Für das reine Lesen genügt der Stand-der-Technik-Viewer.

Wann braucht GS++ eine zusätzliche Risikobetrachtung?

Bei hohem Schutzbedarf, bei Assets, die keine Zielobjektkategorie hinreichend abdeckt, und bei dauerhaft nicht erfüllten SOLLTE-Anforderungen. Die gewählte Methode muss die 35 Mindestkriterien aus Anhang 3 erfüllen. Bei temporär nicht erfüllten SOLLTE-Anforderungen ist zumindest das Restrisiko zu betrachten und von der Institutionsleitung freizugeben.

Sind MUSS-Anforderungen in GS++ abweichbar?

Nein. Der Standard schließt aus, die Erfüllung einer MUSS-Anforderung durch Risikoakzeptanz oder eine Ausnahmegenehmigung zu ersetzen. Spielraum gibt es nur bei SOLLTE-Anforderungen, deren Nichterfüllung als temporär oder dauerhaft einzuordnen ist, und bei den optionalen KANN-Anforderungen des Niveaus „erhöht“.

Warum gibt es nur noch zwei Schutzbedarfskategorien?

GS++ gibt „normal“ und „hoch“ vor, die Kategorie „sehr hoch“ aus dem bisherigen Grundschutz entfällt. Institutionen dürfen eigene Kategorien definieren, müssen sie aber auf diese beiden abbilden. Für ein zertifizierbares ISMS muss in der niedrigsten Kategorie stets der Stand der Technik eingehalten werden.

Gibt es ein Mapping vom IT-Grundschutz-Kompendium auf GS++?

Ja. Die Stand-der-Technik-Bibliothek enthält im Control Layer ein Mapping vom IT-Grundschutz-Kompendium 2023 auf GS++, außerdem eines von ISO/IEC 27001:2022 Anhang A. Beide sind ein guter Ausgangspunkt, um das heutige Baustein-Mapping mit dem neuen Anforderungspaket zu vergleichen. Wie sich Grundschutz und ISO 27001 heute schon in einem Control-Set verbinden lassen, zeigt der Artikel zum Grundschutz-ISO-27001-Mapping.

Quellen

• BSI-Standard 300-1 „Methodik Grundschutz++“, Version 1.0, 20.10.2026 (PDF)
• BSI-Standard 200-1 „Managementsysteme für Informationssicherheit“, Version 1.0, Oktober 2017 (PDF)
• BSI: Grundschutz++ (Zeitplan und Zertifizierung)
• BSI: Stand-der-Technik-Bibliothek auf GitHub
• Stand-der-Technik-Viewer (Community)
• NIST: OSCAL