Grundschutz++ ist da: Was der BSI-Standard 300-1 für jede Organisation mit ISMS ändert

KERNTHESE Der BSI-Standard 300-1 führt die deutsche Basis der Informationssicherheit von einem Katalog aus Bausteinen zu einer prozessorientierten Methodik mit einer maschinenlesbaren Anforderungsbibliothek. Für Organisationen mit normalem Schutzbedarf hat das BSI den Großteil der Risikoarbeit bereits erledigt. Was bleibt, ist eine disziplinierte Leitungsaufgabe: die Geschäftsprozesse kennen, entscheiden, welche davon hohen Schutz brauchen, jede Lücke bei den verpflichtenden Anforderungen schließen und jede Ausnahme so dokumentieren, dass ein Auditor und zunehmend auch ein Werkzeug sie prüfen kann.

Am 26. Oktober 2026 hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) die Methodik des Grundschutz++ als BSI-Standard 300-1 bekannt gegeben; laut Meilensteinplan des BSI wurde sie am 27. Oktober auf der it-sa in Nürnberg vorgestellt.¹² Das Dokument selbst, Version 1.0 vom 20. Oktober 2026, umfasst 42 Seiten.³ Das ist kurz für einen Standard, der eine der meistgenutzten Sicherheitsmethoden im deutschsprachigen Raum ablösen soll, und nach meiner Lesart hat die Kürze einen Grund: Vieles, was früher in langen Texten stand, liegt jetzt in einer eigenständig gepflegten, maschinenlesbaren Anforderungsbibliothek.

Das BSI beschreibt den Standard als Weiterentwicklung des IT-Grundschutz, unter anderem für Institutionen mit heterogenen IT-Landschaften oder komplexer Virtualisierung.¹ Ein nach Grundschutz++ implementiertes ISMS soll ab 2027 zertifizierbar und zur ISO/IEC 27001 kompatibel sein.¹ Version 1.0 richtet sich in erster Linie an „Early Adopters“, also erfahrene Institutionen, die Grundschutz++ früh umsetzen wollen und deren Erfahrungen in die weitere Entwicklung des Grundschutz++ einfließen.³

Woher der Wandel kommt

Der IT-Grundschutz nach den BSI-Standards 200-1 bis 200-3 verlangte, den Informationsverbund auf Grundlage einer Strukturanalyse, die auch Geschäftsprozesse und Anwendungen erfasste, mit Bausteinen aus dem IT-Grundschutz-Kompendium zu modellieren und den Schutzbedarf in drei Kategorien festzustellen. Eine zusätzliche Risikoanalyse war für Zielobjekte mit hohem oder sehr hohem Schutzbedarf vorgesehen, für Zielobjekte, die sich mit den Bausteinen nicht hinreichend abbilden ließen, und für Einsatzszenarien, die der IT-Grundschutz nicht vorsah.⁴ Nach meiner Erfahrung funktionierte das und hat eine große Gemeinschaft geschulter Praktiker hervorgebracht. Es hat aber auch lange Dokumente erzeugt, die schwer aktuell zu halten und noch schwerer automatisch zu prüfen waren.

Grundschutz++ behält die Idee einer Basis, die das BSI für typische Situationen vorab berechnet, und ändert fast alles um sie herum. Das BSI hebt in seiner Pressemitteilung drei Merkmale hervor: Die Methodik ist an Geschäftsprozessen ausgerichtet, das Risikoverfahren ist frei wählbar, sofern festgelegte Mindestkriterien eingehalten werden, und alle Anforderungen liegen jetzt maschinenlesbar vor.¹ Der zweite Punkt ist weniger neu, als er klingt: Schon der BSI-Standard 200-3 ließ ein anderes etabliertes Risikoverfahren zu; neu sind die 35 verbindlichen Mindestkriterien, die jedes Verfahren erfüllen muss.³⁴ Die Stand-der-Technik-Bibliothek ersetzt das IT-Grundschutz-Kompendium² und wird in Form von OSCAL-Dokumenten in einem öffentlichen Repository unter einer Creative-Commons-Lizenz veröffentlicht.⁵

Fünf Schritte, ein Zyklus

Die Methodik folgt einem PDCA-Zyklus mit fünf Prozessschritten.³ Für die ersten beiden Schritte nennt sie die Kapitel der ISO/IEC 27001, die sie abdecken, und die Methodik-Anforderungen insgesamt bilden die Kapitel 4 bis 10 ab.

• Schritt 1, Erhebung und Planung, führt die Aktivitäten der Kapitel 4 und 5 der ISO/IEC 27001 durch: Kontext, Compliance-Management, Anwendungsbereich, interessierte Parteien, Geschäftsprozesse, Schutzbedarf, Leitlinie, Rollen, Dokumentation, Freigabe durch die Leitung und Initiierung der Risikobetrachtung.
• Schritt 2, Anforderungsanalyse, führt die Aktivitäten der Kapitel 6 und 10 durch: Abgrenzung des Informationsverbunds, Erfassung der Assets, Auswahl von Blaupausen und Erstellung eines individuellen Anforderungspakets.
• Schritt 3, Realisierung, prüft den Umsetzungsstatus jeder Anforderung, führt die Risikobetrachtung durch, wo sie nötig ist, und überführt das Ergebnis in einen Umsetzungsplan mit Zuständigkeiten und Fristen.
• Schritt 4, Überwachung, umfasst Leistungsbewertung, interne Audits, Managementbewertungen, Monitoring-Verfahren und die Validierung der Anforderungen.
• Schritt 5, kontinuierliche Verbesserung, behandelt Nicht-Konformitäten, Verbesserungspotenziale, einen Korrektur- und Verbesserungsplan und die Evaluation, ob Maßnahmen tatsächlich gewirkt haben.

Zwei Einzelheiten aus Schritt 1 verdienen die Aufmerksamkeit der Leitung. Die Verantwortung für das ISMS liegt bei der Institutionsleitung und kann nicht delegiert werden.³ Und der ISB oder eine andere Rolle der Sicherheitsorganisation muss in sicherheitsrelevante Projekte wie die Einführung eines neuen Systems eingebunden und über die wesentlichen Inhalte informiert werden; festgelegt wird, wann diese Beteiligung erfolgt.³

Erst die Prozesse, dann die Assets

Die sichtbarste Änderung ist der Bezugspunkt. Auch der IT-Grundschutz begann die Strukturanalyse mit den Geschäftsprozessen, stellte den Schutzbedarf dann aber je Zielobjekt fest und ordnete Bausteine Objekt für Objekt zu;⁴ im Grundschutz++ bleibt der Geschäftsprozess durchgehend der Bezugspunkt. Organisationen identifizieren und dokumentieren die Geschäftsprozesse im Anwendungsbereich, bevor sie auf Systeme schauen. Für Behörden und Anstalten des öffentlichen Rechts verweist der Standard auf ihre gesetzlichen Aufträge als Quelle.³ Fehlt eine Prozesslandkarte, bietet Anhang 2 ein bewusst schlankes Verfahren: Ein Geschäftsprozess ist ein wiederkehrender, wesentlicher Ablauf aus zusammenhängenden Tätigkeiten mit nachvollziehbarem Ergebnis, und für jeden genügen Kennung, Name, fachlich verantwortliche Person, Rolle oder Organisationseinheit, Kurzbeschreibung und die wesentlichen Anwendungen.³

Der Schutzbedarf wird dann je Geschäftsprozess festgestellt, nicht je System, und es gibt nur zwei Kategorien: normal, wenn die Auswirkungen begrenzt und überschaubar sind, und hoch, wenn sie beträchtlich sein können.³ Organisationen dürfen weitere eigene Kategorien bilden, müssen sie aber auf diese beiden abbilden, und für ein zertifizierbares ISMS muss in der niedrigsten Kategorie stets der Stand der Technik eingehalten werden.³ Der Standard empfiehlt, bei erstmaliger Einführung mit dem wichtigsten Geschäftsprozess aus der höchsten Schutzbedarfskategorie zu beginnen und danach die übrigen abzuarbeiten.³

Die Arbeit an den Assets folgt aus dieser Entscheidung. Bei hohem Schutzbedarf sind Zugehörigkeit und Abhängigkeit der Assets zum Geschäftsprozess zu dokumentieren, weil die spätere Risikobetrachtung auf Ebene des Geschäftsprozesses und entlang des Ressourcenpfads stattfindet. Bei normalem Schutzbedarf ist diese Dokumentation nicht erforderlich, und der Standard verlangt weniger: mindestens die Abhängigkeiten zwischen Anwendungen und IT-Systemen sowie zwischen IT-Systemen und Räumen.³ Vorhandene CMDBs, Asset-Register, Netzpläne und Service Maps dürfen genutzt werden.³

Von den Assets zum Anforderungspaket

Die Assets werden anschließend Zielobjektkategorien zugeordnet, standardisierten Klassen wie Gebäude, Serverräume, Administrierende, externe Netzanschlüsse, Cloud-Dienste, Webanwendungen oder E-Mail. Anhang 1 definiert sie, und sie stehen in einer Vererbungshierarchie: Ein Serverraum ist auch ein Raum, und ein Asset in einer untergeordneten Kategorie übernimmt die Anforderungen der übergeordneten Kategorien mit.³

Grundschutz++ unterscheidet drei Arten von Anforderungen.³ Die Methodik-Anforderungen bilden die Kapitel 4 bis 10 der ISO/IEC 27001 ab und gelten für jeden Informationsverbund, ein individuelles Vorgehen ist nicht vorgesehen. Technische und organisatorische Anforderungen ohne Zielobjektkategorie sind ebenfalls verpflichtend aufzunehmen. Anforderungen mit Kategoriebezug gelten überall dort, wo Assets dieser Kategorie zugeordnet sind. Ergänzt wird das Paket bei Bedarf um eigene Anforderungen für Assets, die der Katalog nicht hinreichend abbildet, sowie um Verpflichtungen aus dem Compliance-Management, der Analyse der interessierten Parteien oder der Risikobetrachtung.³ Blaupausen, vorgefertigte Anforderungskataloge für bestimmte Anwendungsszenarien, können eine Vorauswahl treffen und die Parameter festlegen, und für bestimmte Institutionen kann es verpflichtende Blaupausen geben.³

Parameter sind aus meiner Sicht die leise Neuerung. Eine Anforderung kann verlangen, dass etwas „regelmäßig“ geschieht; sofern keine Blaupause oder andere verbindliche Vorgabe den Wert bereits festlegt, bestimmt die Organisation bei oder nach der Erstellung ihres Pakets, was regelmäßig heißt, und der Standard hält fest, dass Parameter für eine automatisierte Prüfung genutzt werden können.³

MUSS, SOLLTE, KANN: wo die Linie jetzt verläuft

Bevor eine Lücke behandelt wird, ist zuerst zu prüfen, ob die Anforderung überhaupt anwendbar ist; ist sie es nicht, wird das begründet, und das ist etwas anderes als eine Risikoakzeptanz.³ Jede anwendbare Anforderung trägt ein Modalverb, und Grundschutz++ verbindet mit jedem klare Folgen.³

KANN-Anforderungen gehören zum Sicherheitsniveau „erhöht“ und sind optional. Sie sind ein Angebot für Organisationen, deren Risikobetrachtung mehr verlangt.

SOLLTE-Anforderungen, die nicht erfüllt sind, müssen eingeordnet werden. Eine temporäre Nichterfüllung, also eine stichhaltig begründete Lücke, deren Schließung zu einem absehbaren späteren Zeitpunkt vorgesehen ist, löst für sich genommen keine vollständige explizite Risikobetrachtung aus. Eine Restrisikobetrachtung bleibt aber erforderlich, und das identifizierte Risiko ist durch die Institutionsleitung freizugeben, die es bis zur Erfüllung trägt. Eine dauerhafte Nichterfüllung löst eine Risikobetrachtung aus, und die Restrisiken werden der Leitung zur Freigabe vorgelegt. Der Standard fügt eine Warnung hinzu: Häufen sich dauerhafte Nichterfüllungen, kann der Stand der Technik insgesamt verfehlt werden, und in einer Zertifizierung könnte eine erhebliche Abweichung festgestellt werden.³

MUSS-Anforderungen sind verpflichtend. Für jede nicht erfüllte sind Maßnahmen festzulegen, eine Risikobetrachtung kann ihre Erfüllung nicht ersetzen, und weder eine Ausnahmegenehmigung noch eine Risikoakzeptanz ist möglich.³

Nach meiner Einschätzung ist das der Satz, den viele Organisationen zuerst spüren werden. ISO/IEC 27001 erlaubt eine risikobasierte Auswahl von Maßnahmen und die Akzeptanz von Restrisiken im Rahmen ihrer Anforderungen; die verbindlichen ISMS-Anforderungen der Kapitel 4 bis 10 lassen sich dadurch allerdings nicht abbedingen. Der IT-Grundschutz schloss die Risikoübernahme bei Basis-Anforderungen schon bisher im Normalfall aus;⁴ Grundschutz++ macht daraus für jede MUSS-Anforderung eine ausnahmslose Regel und schließt auch den Weg über eine Ausnahmegenehmigung.

Risikobetrachtung: nur bei Auslösern, aber mit festeren Regeln

Wie schon im IT-Grundschutz hat das BSI eine allgemeine Risikobetrachtung in den Anforderungskatalog eingebaut. Es leitet die Anforderungen auf Grundlage von 47 elementaren Gefährdungen ab, von G 0.1 Feuer bis G 0.47 schädliche Seiteneffekte IT-gestützter Angriffe, und soweit im Katalog hinterlegt, trägt eine technische oder organisatorische Anforderung die G-0-Kennungen der Gefährdungen, denen sie entgegenwirkt; Methodik-Anforderungen tragen keine.³⁵ Deshalb müssen Organisationen bei normalem Schutzbedarf grundsätzlich keine eigene explizite Risikobetrachtung durchführen, sofern keiner der unten genannten Auslöser vorliegt; Restrisiken geplanter, noch nicht erfüllter SOLLTE-Anforderungen sind dennoch zu betrachten und freizugeben.³

Eine explizite Risikobetrachtung ist in drei Fällen erforderlich: wenn ein Geschäftsprozess bei mindestens einem Schutzziel hohen Schutzbedarf hat, wenn ein relevantes Asset durch die bestehenden Zielobjektkategorien und ihre Anforderungen nicht hinreichend abgedeckt ist, oder wenn eine anwendbare SOLLTE-Anforderung dauerhaft nicht erfüllt wird.³ Das Verfahren dürfen Organisationen selbst wählen, etwa angelehnt an ISO/IEC 27005 oder ISO 31000, sofern es die 35 verbindlichen Mindestkriterien aus Anhang 3 erfüllt.³

Für mich lesen sich diese Kriterien wie die Checkliste eines Auditors. Die Institution legt Risikoappetit und Risikoakzeptanzkriterien fest, und die Leitung autorisiert Verfahren, Rollen, Kriterien und Risikoappetit. Jedes Risiko erhält einen Risikoeigentümer, standardmäßig den Eigentümer des Geschäftsprozesses, und einen Eintrag im Risikoregister mit mindestens Kennung, Untersuchungsobjekt, Beschreibung, betroffenen Schutzzielen, Risikoniveau und Eigentümer, bei zu behandelnden Risiken zusätzlich Priorität, Behandlungsoption und zugeordnete Maßnahmen. Temporär akzeptierte Risiken brauchen eine Befristung. Restrisiken autorisiert die Leitung. Die gesamte Betrachtung wird mindestens jährlich sowie bei geplanten oder eingetretenen wesentlichen Änderungen überprüft.³

Nachweise, die ein Werkzeug lesen kann

Nach meiner Lesart ist die Realisierung mit Blick auf Automatisierung geschrieben. Jede Maßnahme ist mit den Anforderungen zu verknüpfen, die sie adressiert, und für jede Anforderung muss erkennbar sein, welche Maßnahmen ihr dienen. Zu jeder Maßnahme werden mindestens die zugehörige Anforderung, das Datum der Umsetzung oder Überprüfung und die dokumentierende oder prüfende Person festgehalten. Erfolgt die Prüfung automatisiert, sind Werkzeug, Zeitpunkt und Prüfergebnis zu dokumentieren, und ein vom Werkzeug erzeugter Prüfbericht wird Maßnahme und Anforderung zugeordnet.³

Die Prüfung des Umsetzungsstatus kann von Interviews und Dokumentenprüfungen bis zu automatisierten Konfigurationsprüfungen und technischen Scans reichen.³ Zusammen mit dem maschinenlesbaren Katalog weist das nach meiner Einschätzung in eine Richtung: Die Nachweiskette von der Anforderung über die Maßnahme zum Beleg wird am besten in Werkzeugen gepflegt und nicht vor dem Audit rekonstruiert.

Was noch offen ist

Version 1.0 benennt ihre Lücken offen. Einheitliche Vorgaben zur Leistungsbewertung stehen noch aus. Die Leistungsbewertung selbst ist aber schon jetzt erforderlich: Die Institutionen gestalten sie vorerst selbst und legen der Institutionsleitung eine nachvollziehbare Bewertung vor.³ Der Zeitplan des BSI sieht ein Konzept zur Leistungsmessung im Februar 2027 und Leistungskennzahlen für jede Anforderung aus den Methodik-Praktiken bis Ende März 2027 vor.² Schulungskonzepte für GS++-Praktiker und -Berater sind für den 30. November 2026 angekündigt, ein Anwendungsbeispiel mit einer fiktiven Behörde für Dezember 2026.²

Der Zeitplan, auf den es ankommt

Datum	Meilenstein
26./27.10.2026	BSI-Standard 300-1 bekannt gegeben (Pressemitteilung, 26.10.) und auf der it-sa vorgestellt (27.10.); Dokumentversion 1.0 vom 20.10.2026
30.11.2026	Schulungskonzepte für Praktiker und Berater
01.01.2027	Anträge auf ISO-27001-Zertifizierung auf Basis von Grundschutz++ möglich
Q1 2027 – 31.12.2027	Early-Adopter-Phase
30.11.2031	Ende der Zertifizierung nach IT-Grundschutz

Quellen: Pressemitteilung des BSI vom 26.10.2026 und Übersichtsseite des BSI zum Grundschutz++, Stand Oktober 2026.¹²

Die letzte Zeile gehört in jede Planung. Laut Meilensteinplan des BSI bleibt die Zertifizierung nach IT-Grundschutz bis zum 30. November 2031 möglich, fünf Jahre nach der Veröffentlichung des Grundschutz++. Ob vor diesem Datum erteilte Zertifikate bis zum Ende ihrer Laufzeit gültig bleiben, sagt die Seite nicht; das sollte mit dem BSI geklärt werden, bevor eine Migrationsplanung darauf aufbaut. Nach meiner Einschätzung ist dieser Horizont genug Zeit für eine überlegte Migration, und kurz genug, dass ein heute beginnendes ISMS-Projekt von Anfang an auf Grundschutz++ ausgerichtet werden sollte.

Was der Standard außerdem verlangt

Die bisher beschriebenen Änderungen sind die, die die meisten Organisationen zuerst bemerken werden. Version 1.0 enthält mehr, und einige Punkte gehören in jeden Projektplan.³

• Rollen ohne Interessenkonflikte. Die Rollen der Sicherheitsorganisation brauchen die nötige Kompetenz und klare Schnittstellen; Interessenkonflikte, etwa zwischen IT-Leitung und ISB oder zwischen DSB und ISB, sind zu vermeiden (Kapitel 2.8).
• Grenzen des Anwendungsbereichs. Ein Anwendungsbereich kann mehrere Informationsverbünde enthalten. Deren organisatorische, technische und infrastrukturelle Grenzen sind zu dokumentieren, einschließlich ausgelagerter Teile und Schnittstellen zu Dritten (Kapitel 2.3 und 3.1).
• Zwei verschiedene Ebenen. Die Schutzbedarfskategorien normal und hoch sind nicht dasselbe wie die Sicherheitsniveaus der Anforderungen, normal (Stand der Technik) und erhöht. Welche zusätzlichen Anforderungen ein hoher Schutzbedarf verlangt, entscheidet die Risikobetrachtung (Kapitel 2.6 und 3.4.2).
• Blaupausen werden gepflegt, nicht einmal ausgewählt. Auswahl und Anpassungen der Blaupausen werden dokumentiert, Abdeckungslücken geschlossen und die Auswahl bei relevanten Änderungen überprüft (Kapitel 3.3).
• Planung mit Ressourcen. Die Umsetzungsplanung wird mit Ressourcen und Zuständigkeiten freigegeben, Fortschritt und Abweichungen werden laufend verfolgt (Kapitel 4.4 und 4.5).
• Audits und Managementbewertung. Interne Audits folgen einem Auditprogramm mit kompetenten, unparteiischen Auditoren, und die Managementbewertung stützt sich auf Ergebnisse aus Audits, Leistungsbewertung, Sicherheitsvorfällen und Risikobehandlung (Kapitel 5.2 und 5.3).
• Überwachung und Verbesserung. Sicherheitsvorfälle, Schwachstellen und neue Bedrohungen werden laufend bearbeitet, Anforderungen bei Änderungen von Informationsverbund, Katalog oder Blaupausen validiert und Verbesserungen auf ihre Wirksamkeit geprüft (Kapitel 5.4 bis 6).

Lessons Learned

Die folgenden Lehren sind meine Lesart als Lead Auditor, keine Aussagen des BSI.

Die erste Lehre lautet, dass Grundschutz++ zuerst eine Leitungsmethode ist und erst dann eine technische. Die ersten Weichenstellungen, also Anwendungsbereich, Schutzbedarf der Geschäftsprozesse, Reihenfolge der Bearbeitung, Ressourcen und Leitlinie, muss die Leitung treffen oder freigeben, und die Verantwortung für das ISMS kann nicht delegiert werden.³ Eine Organisation, die ihre zehn wichtigsten Prozesse und deren Verantwortliche nicht benennen kann, ist noch nicht startklar, wie gut ihre Firewall-Regeln auch sein mögen.

Die zweite Lehre betrifft Lücken. Sortieren Sie sie zuerst nach Modalverb. MUSS-Lücken brauchen Maßnahmen, keine Risikoakzeptanz deckt sie ab. SOLLTE-Lücken brauchen eine Einordnung als temporär oder dauerhaft: Temporäre brauchen eine stichhaltige Begründung und die Freigabe des Restrisikos durch die Leitung, dauerhafte eine Risikobetrachtung und die Freigabe der Restrisiken durch die Leitung.³ Wer heute Risiken per Vermerk akzeptiert, sollte prüfen, ob hinter jedem Vermerk eine MUSS-Anforderung steht.

Die dritte Lehre betrifft Nachweise. Grundschutz++ geht davon aus, dass Anforderungen, Maßnahmen und Belege eindeutig verknüpft sind, wobei eine Maßnahme mehreren Anforderungen dienen darf, und dass sie aktuell gehalten werden, automatisierte Prüfungen eingeschlossen, dokumentiert bis zum Werkzeug und zum Zeitpunkt.³ Für einen kleinen Informationsverbund reicht dafür eine Tabelle. Für alles Größere ist das maschinenlesbare Format des Katalogs eine Einladung, das ISMS in einem Werkzeug zu führen, das ihn direkt lesen kann.

Die vierte Lehre betrifft den Zeitpunkt. Laut Meilensteinplan des BSI können ab dem 1. Januar 2027 Zertifizierungsanträge für ISO 27001 auf Basis von Grundschutz++ gestellt werden, und die Zertifizierung nach IT-Grundschutz endet am 30. November 2031.² Organisationen mit laufendem IT-Grundschutz-Zertifikat sollten den Umstieg planen, nicht überstürzen. Wer neu startet, sollte gleich mit Grundschutz++ beginnen.

Glossar

Begriff	Bedeutung
Grundschutz++ (GS++)	Nachfolger des IT-Grundschutz zum Aufbau eines ISMS; die Methodik ist der BSI-Standard 300-1
Stand-der-Technik-Bibliothek	Maschinenlesbare Sammlung von Anforderungen und Maßnahmen des BSI als OSCAL-Dokumente; sie ersetzt das IT-Grundschutz-Kompendium
Anwenderkatalog GS++	Katalog aller Anforderungen des Grundschutz++, einschließlich der Methodik-Anforderungen
Geschäftsprozess	Wiederkehrender, wesentlicher Ablauf aus zusammenhängenden Tätigkeiten mit nachvollziehbarem Ergebnis
Schutzbedarf	Erforderliches Maß an Vertraulichkeit, Integrität und Verfügbarkeit eines Geschäftsprozesses; GS++ kennt „normal“ und „hoch“
Informationsverbund	Gesamtheit der infrastrukturellen, organisatorischen, personellen und technischen Assets, die den Anwendungsbereich oder einen Teil davon abbilden
Zielobjektkategorie (ZOK)	Standardisierte Klasse von Assets, etwa Serverraum oder Cloud-Dienst, an die Anforderungen geknüpft sind
Blaupause	Vorgefertigter Anforderungskatalog für ein bestimmtes Szenario mit vorgegebenen Parametern
Parameter	Variables Element einer Anforderung, etwa „regelmäßig“, das die Organisation festlegt und ein Werkzeug prüfen kann
MUSS / SOLLTE / KANN	Verpflichtende / im Regelfall zu erfüllende, Abweichung nur mit Begründung / optionale Anforderungen, jeweils mit eigener Folge bei Nichterfüllung
Elementare Gefährdungen	Die 47 Gefährdungen G 0.1 bis G 0.47, aus denen das BSI die Anforderungen ableitet
OSCAL	Open Security Controls Assessment Language, ein maschinenlesbares Format für Sicherheitsanforderungen

Rechtlicher Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Er beschreibt den BSI-Standard 300-1 in Version 1.0; spätere Versionen können Einzelheiten ändern. Stand: Oktober 2026.

1. BSI, Pressemitteilung „Methodik zum Grundschutz++ als BSI-Standard 300-1 veröffentlicht“, 26.10.2026, https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/BSI-Standard_300-1_261026.html (abgerufen am 27.10.2026). ↩ ↩² ↩³ ↩⁴ ↩⁵

2. BSI, „Grundschutz++“, Übersichtsseite mit Zeitplan (Pilotphase, Veröffentlichung, Zertifizierung ab 1.1.2027, Early-Adopter-Phase, Ende der IT-Grundschutz-Zertifizierung am 30.11.2031), https://www.bsi.bund.de/dok/grundschutz-plus-plus (abgerufen am 27.10.2026). ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. BSI, „BSI-Standard 300-1 – Methodik Grundschutz++“, Version 1.0, 20.10.2026, 42 Seiten: Einleitung (Zielgruppe, PDCA-Zyklus), Kapitel 2 (Erhebung und Planung, u. a. 2.6 Schutzbedarfsfeststellung, 2.8 Rolle des ISB, 2.10 nicht delegierbare Verantwortung, 2.11 Initiierung der Risikobetrachtung), Kapitel 3 (Anforderungsanalyse, Zielobjektkategorien, Blaupausen, Parameter), Kapitel 4 (Realisierung, u. a. 4.1.2 MUSS/SOLLTE/KANN und 4.3 Umsetzungsplanung, u. a. Nachweis der Umsetzung), Kapitel 5 (Überwachung, u. a. 5.1 Leistungsbewertung), Kapitel 6 (Verbesserung), Anhang 1 (Zielobjektkategorien), Anhang 2 (vereinfachte Geschäftsprozessanalyse), Anhang 3 (35 Mindestkriterien für die Risikobetrachtung), Anhang 4 (47 elementare Gefährdungen). PDF: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_300-1.pdf?__blob=publicationFile&v=3 (abgerufen am 27.10.2026). ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹ ↩³² ↩³³ ↩³⁴

4. BSI, „BSI-Standard 200-2 – IT-Grundschutz-Methodik“, Version 1.0, 2017, Kapitel 8 (Strukturanalyse einschließlich Geschäftsprozessen und Anwendungen, Schutzbedarfsfeststellung, Modellierung; 8.4.2 und 9.2 zu Basis-Anforderungen; 8.5 Risikoanalyse), https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.pdf?__blob=publicationFile&v=2 (abgerufen am 28.10.2026); BSI-Standard 200-3 – Risikoanalyse auf der Basis von IT-Grundschutz, Version 1.0, 2017, Abschnitt 1.4, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.pdf?__blob=publicationFile&v=2 (abgerufen am 28.10.2026). ↩ ↩² ↩³ ↩⁴

5. BSI, „Stand-der-Technik-Bibliothek“, GitHub-Repository mit maschinenlesbaren OSCAL-Dokumenten, Lizenz CC BY-SA 4.0, https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek (abgerufen am 27.10.2026). ↩ ↩²