Grundschutz:Einführung und Aufbau

Dieser Artikel bietet einen schrittweisen Überblick über BSI Grundschutz++ und dem neuen BSI Standard 300-1 "Methodik Grundschutz++". Er navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.

Einführung in Grundschutz++

Grundschutz++ ist die Weiterentwicklung des IT-Grundschutzes. Methodische Grundlage dieser Darstellung ist der neue BSI-Standard 300-1 „Methodik Grundschutz++“, Version 1.0 vom 20.10.2026.

Grundschutz++ verbindet einen iterativen ISMS-Prozess mit einem individuell zusammengestellten Anforderungspaket. Geschäftsprozesse bilden die Grundlage für Schutzbedarfsfeststellung, Asset-Erfassung und Risikobetrachtung. Anforderungen werden thematisch in Praktiken zusammengefasst und, soweit assetbezogen, über Zielobjektkategorien zugeordnet.

Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.

Wesentliche Merkmale

• Geschäftsprozessorientierung: Ausgangspunkt sind die Geschäftsprozesse und ihr Schutzbedarf.
• Individuelles Anforderungspaket: Verpflichtende, assetbezogene und ergänzende Anforderungen werden nach den Auswahlregeln des Standards individuell zusammengeführt.
• Hierarchische Zielobjektkategorien: Assets werden passenden Zielobjektkategorien einschließlich ihrer übergeordneten Zielobjektkategorien zugeordnet.
• Blaupausen: Szenariobezogene Anforderungskataloge mit vorgegebenen Parametern unterstützen die Auswahl.
• Risikoorientierte Ergänzung: Für normalen Schutzbedarf liegt dem Anwenderkatalog eine allgemeine Risikobetrachtung des BSI zugrunde. In bestimmten Fällen ist eine eigene explizite Risikobetrachtung erforderlich.
• Kontinuierliche Verbesserung: Fünf iterative Prozessschritte umfassen Planung, Umsetzung, Überwachung und Verbesserung in einem PDCA-Zyklus.

Ziele und Einordnung

Ziele der Reform:

• Schlankere Prozesse: Durch Automatisierung soll der administrative Aufwand sinken.
• Dynamische Anpassung: JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
• Praxisorientierte Vereinfachung: Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
• Priorisierung und Messbarkeit: Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.

Vorhandene Dokumentationen und Datenquellen können weitergenutzt werden. Ein umfassendes Prozessmanagement wird für die vereinfachte Geschäftsprozessanalyse nicht verlangt. Maschinenlesbare Kataloge und geeignete Tools können die Bearbeitung unterstützen; sie ersetzen keine fachlichen Entscheidungen und keine Leitungsverantwortung.

Der Standard 300-1 legt keine verbindlichen Einführungs-, Übergangs- oder Zertifizierungstermine fest. Solche Termine sind anhand gesonderter aktueller BSI-Veröffentlichungen zu prüfen. Der Anforderungskatalog wird in der Stand-der-Technik-Bibliothek auf GitHub bereitgestellt.

Bedeutung von OSCAL im Grundschutz++

Das zugrundeliegende Format für Grundschutz++ ist OSCAL.

OSCAL ist ein Framework bzw. eine Datenmodellierungssprache, die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat JSON entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

• Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
• Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig (z.B. mit Deinstleistenden, Auditiernden, BSI) ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

• Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
• Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
• Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.

Für die lesbare Darstellung des OSCAL Grundschutz++-Katalogs steht eine lokaler Web-Viewer auf GitHub zur Verfügung.

Satzschablonen

Praktiken

Anforderungen werden im Grundschutz++ mit Satzschablonen erstellt, die wie folgt aussehen:

{Praktik} [für {Zielobjektkategorie}] {MODALVERB} <Ereignis> {Handlungswort} (TAGs) (Hinweise)

Praktik: Beschreibt jeweils ein Themenfeld der Informationssicherheit (z.B. Berechtigungsmanagement, Konfiguration, Personal, Monitoring) und bündelt alle dazugehörigen Anforderungen an Organisation, Prozesse und Technik in einem Paket. Sie ersetzt damit die frühere Verteilung ähnlicher Anforderungen über viele einzelne Bausteine und sorgt dafür, dass ein Thema an einer Stelle konsistent beschrieben wird. Liste der gültigen Praktiken.

Zielobjektkategorien

Zielobjektkategorie: Eine Kategorie von Objekten (Assets), auf die sich Sicherheitsanforderungen beziehen (z.B. Daten, Mitarbeitende, Endgeräte, Hostsysteme, WLANs). Im weitesten Sinne vergleiche mit "Bausteinen" im klassischen IT-Grundschutz. Liste der Gültigen Zielobjektkategorien.

Modalverb: Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN). Liste der gültigen Modalverben.

Ereignis: Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

Handlungswort: Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. Liste der gültigen Handlungsworte.

Das ganze kann noch mit TAGs für eine bessere Gruppierung und mit einem Hinweis zu weiterführenden Informationen ergänzt werden. Liste der gültigen TAGs.

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken (aktuell von ca. 7.000 auf 998).

Beispiel

Die Anforderung:

ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]

Die Institutionsleitung MUSS einen oder eine ISB benennen. . . .

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. . . .

Wird jetzt zu den Anforderungen:

GOV.4.2: Die Governance MUSS einer Person die Rolle ISB zuweisen.

GOV.2.3: Die Governance MUSS für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen zuweisen.

GOV.4.4: Die Governance MUSS dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung ermöglichen.

Da dies übergreifende Anforderungen sind, ist hier keine spezifische Zielobjektkategorie benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.

Im ursprünglichen Konzept von Grundschutz++ hatten Satzschablonen den Zweck, Anforderungen in eine einheitliche, maschinenlesbare und fachlich klar strukturierte Form zu bringen. Inzwischen übernimmt OSCAL als Datenmodell die Funktion der Maschinenlesbarkeit. Beispiel:

Satzschablone: „Praktik X für Zielobjektkategorie Y MUSS Ereignisse Z protokollieren.“

OSCAL: Control mit id, title, parameter (Z), implemented-requirement für Komponente (Y), Rolle (aus Praktik X).

Auch wenn die Anforderung (Control title) in OSCAL grundsätzlich frei und verständlich formulierbar ist, hält das BSI für Grundschutz++ Anforderungen in OSCAL am Satzschablonenformat fest.

Priorisierung

Die Institution priorisiert die Maßnahmen ihres Umsetzungsplans insbesondere anhand des Aufwands, der Synergien zwischen Maßnahmen, der Risikohöhe, der strategischen Bedeutung und möglicher Quick-Wins mit hoher Wirksamkeit. Grundsätzlich empfiehlt der Standard, Anforderungen der übergeordneten Zielobjektkategorien („Elternknoten“) in der Umsetzung zu priorisieren. Zuständigkeiten, Ressourcen und realistische Fristen sind festzulegen.

Modalverben bestimmen die Verbindlichkeit und sind nicht mit einer Aufwandseinstufung gleichzusetzen.

Alle Anforderungen im Katalog werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:

• Stufe 0: Zwingend (sofort) umzusetzende Anforderungen (MUSS-Anforderungen).

Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:

• Stufe 1: Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
• Stufe 2: Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
• Stufe 3: Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
• Stufe 4: Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.

Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.

• Stufe 5: Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf oder Anforderung mit erheblichem Aufwand.

Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung, sie stellt aber ausdrücklich keine verbindliche Umsetzungsprioritat dar.

Leistungsbewertung und Kennzahlen

Eine Leistungsbewertung ist erforderlich, um die Wirksamkeit des ISMS und seiner Ziele zu überprüfen. Nach Kapitel 5.1 stehen einheitliche GS++-Vorgaben hierfür noch aus; Institutionen sind in der Ausgestaltung frei. Die Leistungsbewertung sollte der Institutionsleitung nachvollziehbar vorgelegt werden.

Geeignete Kennzahlen können die Bewertung unterstützen. Der Standard schreibt jedoch weder ein C/I/A-Punktesystem für einzelne Anforderungen noch die konrete Bewertung oder die Art der Summierung zu einem Erfüllungsgrad oder verbindliche Schwellwerte für die Zertifizierbarkeit vor. Entsprechende Entwicklungsansätze sind von den geltenden methodischen Vorgaben zu trennen.

Umsetzungsstatus und Wirksamkeit sind ebenfalls zu unterscheiden: Eine dokumentierte Umsetzung ersetzt nicht die Überprüfung, ob die Maßnahme die Anforderung tatsächlich erfüllt.

Leistungskennzahlen

Im Katalog sollen zukünftig Leistungskennzahlen der Messung und Bewertung der Umsetzung von Sicherheitsanforderungen dienen. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet. Das BSI will Leistungskennzahlen bis 31.03.2027 in Grundschutz++ vollständig integrieren.

Schwellwerte und Erfüllungsgrad

• Schwellwerte definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
• Der Erfüllungsgrad zeigt, welche Anforderungen bereits umgesetzt wurden.

Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.

Der ursprüngliche Ansatz sah vor, dass Schwellwerte den Reifegrad und die Zertifizierbarkeit von Informationsverbünden dokumentieren sollten.

Gestaltungsentscheidungen (Parameter)

Gestaltungsentscheidungen umfassen die Festlegung organisationsspezifischer Parameter (Rollen und Werte innerhalb der Anforderungen). Sie konkretisieren das Anforderungspaket und ermöglichen automatisierte Prüfungen. Beispiel:

Anforderung:

• PERF.5.2 – Bericht an die Institutionsleitung
• Statement (mit Parameter): „Monitoring‑Evaluation MUSS die Institutionsleitung über den Stand des Managementsystems {{regelmäßig}} anhand des Managementberichtes informieren.“
• Parameter in OSCAL (perf.5.2-prm1): Label „regelmäßig“.

Gestaltungsentscheidung:

• Es wird festgelegt: „Die Institutionsleitung wird vierteljährlich anhand eines Managementberichts informiert.“
• Optional ergänzt: „Zusätzlich anlassbezogen nach schweren Sicherheitsvorfällen (z.B. Datenpannen mit Meldepflicht).“

Damit wird konkretisiert, was „regelmäßig“ im Kontext des eigenen ISMS bedeutet (Rhythmus, gegebenenfalls Triggerereignisse). Bereits festgeschriebene Parameter, etwa aus einer Blaupause, sind zu beachten; sie stehen nicht zur beliebigen organisationsspezifischen Festlegung.

Die Anforderungen werden damit organisationsspezifisch angepasst und können (bei technischen Parametern) ggf. später automatisiert geprüft werden.

Was bleibt erhalten?

Standards und Vorgehen

Der Standard 300-1 beschreibt fünf iterative Prozessschritte:

1. Erhebung und Planung
2. Anforderungsanalyse
3. Realisierung
4. Überwachung
5. Kontinuierliche Verbesserung

Er enthält keine pauschale Weitergeltungs- oder Ablösungsregel für die gesamte Reihe 200-1 bis 200-4. Übergangs- und Zertifizierungsregelungen sind anhand gesonderter aktueller BSI-Veröffentlichungen zu klären.

Die Modalverben sind wie folgt zu berücksichtigen:

• MUSS: Anwendbare MUSS-Anforderungen sind verpflichtend zu erfüllen. Bei Nichterfüllung sind Maßnahmen zur Erfüllung festzulegen. Eine Risikobetrachtung ersetzt die Erfüllung nicht; Ausnahmegenehmigung und ersetzende Risikoakzeptanz sind ausgeschlossen.
• SOLLTE: Nichterfüllungen sind als temporär oder dauerhaft einzuordnen. Dauerhafte Nichterfüllung erfordert eine Risikobetrachtung und die Freigabe verbleibender Restrisiken durch die Institutionsleitung. Temporäre Nichterfüllung setzt eine vorgesehene, absehbare Umsetzung und eine stichhaltige dokumentierte Begründung voraus; zusätzlich sind Restrisikobetrachtung und Leitungsfreigabe zu beachten.
• KANN: Die Umsetzung ist optional. Anforderungen des Sicherheitsniveaus „erhöht“ enthalten dieses Modalverb und können in der Risikobetrachtung als Ausgangspunkt für zusätzliche Maßnahmen dienen.

Häufige dauerhafte Nichterfüllungen von SOLLTE-Anforderungen können dazu führen, dass der erforderliche Stand der Technik insgesamt nicht erreicht wird.

Tool-Einsatz

Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.

Struktur und zentrale Begriffe im Grundschutz++

Ein pauschaler Eins-zu-eins-Vergleich mit den bisherigen Bausteinen kann die Unterschiede zwischen Praktiken und Zielobjektkategorien verdecken. Für die Anwendung des Standards sind folgende Begriffe maßgeblich:

Begriff	Bedeutung und Funktion
Anwendungsbereich (Scope)	Formaler und organisatorischer Umfang des ISMS. Er wird durch die Institutionsleitung festgelegt und kann einen oder mehrere Informationsverbünde umfassen.
Informationsverbund	Inhaltlich-technische Abbildung des Anwendungsbereichs beziehungsweise eines Teilbereichs; umfasst infrastrukturelle, organisatorische, personelle und technische Assets.
Asset	Materieller oder immaterieller Wert, der für die betrachteten Geschäftsprozesse benötigt wird. Ähnliche Assets können bei vergleichbaren Eigenschaften und Einsatzzwecken gruppiert werden.
Zielobjektkategorie	Standardisierte Klasse zur Zuordnung von Assets und Anforderungen. Auch die jeweils übergeordneten Kategorien sind dem Asset zuzuordnen. Definitionen enthält Anhang 1.
Praktik	Thematische Zusammenfassung von Anforderungen. Unterschieden werden Methodik-, technische und organisatorische Praktiken. Eine Praktik ist kein Asset-Typ.
Anforderungspaket	Gesamtheit der für den Informationsverbund relevanten verpflichtenden, über Assets und Zielobjektkategorien zugeordneten sowie ergänzenden Anforderungen.
Schutzbedarf	Bewertung möglicher Schäden einer Beeinträchtigung eines Geschäftsprozesses hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit. Vorgegeben sind „normal“ und „hoch“; eigene Kategorien müssen hierauf abgebildet werden.
Sicherheitsniveau	Der Standard unterscheidet bei Anforderungen „normal-SdT“ und „erhöht“. „Hoch“ bezeichnet die Schutzbedarfskategorie und ist nicht die Bezeichnung eines Sicherheitsniveaus.

Das Anforderungspaket ist nicht beliebig anpassbar. Methodik-Anforderungen sind verpflichtend auf jeden Informationsverbund anzuwenden; ein individuelles methodisches Vorgehen ist nicht vorgesehen. Alle weiteren Anforderungen ohne zugewiesene Zielobjektkategorie sind verpflichtend aufzunehmen. Assetbezogene Anforderungen ergeben sich aus den zugeordneten Kategorien einschließlich der übergeordneten Kategorien. Ergänzungen und Parameterkonkretisierungen erfolgen nach den Regeln der Kapitel 3.4 und 3.5 des Standards.

Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Standards gegenüber:

	Grundschutz Kompendium	Grundschutz++
	Fester verbindlicher Katalog von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.	Der variable und erweiterbare OSCAL-Datenbestand bildet den Stand der Technik an und wird mit Parametern an die Bedürfnisse der Organisation angepasst. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
	Järliche Aktualisierung zum Stichtag 1. Februar. (bis 2023)	Die Aktualisierung erfolgt fortlaufend nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch unklar.
	Das Kompendium ist (Stand 2023) in 10 Schichten mit insgesamt 111 Bausteine gegliedert, die statisch die jeweiligen Anforderungen enthalten.	Praktiken und Zielobjektkategorien (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Anforderungen. Sie können modular einzelnen Assets zugeordnet werden (Zielobjektkategorien) oder übergreifend das ISMS definieren (Praktiken). Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjektkategorien zugeordnet. Zielobjektkategorien entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor im Fluß!
	Drei Stufen (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.	Es gibt sechs Stufen (0–5), die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z.B. über Leistungskennzahlen). Das Sicherheitsniveau gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen. Unterschieden werden: Normales Sicherheitsniveau: entspricht dem Stand der Technik Erhöhtes Sicherheitsniveau: für besonders schutzbedürftige Informationen oder Systeme
	Zielobjekte als gruppierte Sammlung von gleichartigen Assets die zur späteren Modellierung (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.	Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann Assets. Der Begriff Zielobjekt wird hierfür nicht mehr genutzt. Diese Assets werden in der Modellierung künftig Zielobjektkategorien zugewiesen, wobei Zielobjektkategorien eher dem entsprechen, was bislang die Bausteine waren, eine Sammlung von spezifischen Anforderungen für bestimmte Asset-Typen.
	Modalverben MUSS, SOLLTE, KANN bestimmen die Verbindlichkeit von Anforderungen.	Die Bedeutung der Modalverben (MUSS, SOLLTE, KANN) bleibt weitgehend unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
	-	Neu sind Leistungskennzahlen, die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
	Gültigkeit bis 30.11.2031	Gültig ab 1.1.2026. Zertifizierbar ab 1.1.2027.

Teilweise werden Begrifflichkeiten neu (oder anders) definiert:

	Grundschutz Kompendium	Grundschutz++
	Zielobjekt als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung	Asset und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann Assets. Der Begriff Zielobjekt wird hierfür nicht mehr genutzt.
	Baustein als Sammlung von Anforderungen für bestimmte Zielobjekttypen.	Zielobjektkategorien und Praktiken sind zukünftig das was bislang die Bausteine waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjektkategorien zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe ist noch im Fluß.

Blaupausen

Eine Blaupause ist ein vorgefertigter, auf bestimmte Anwendungsszenarien zugeschnittener Anforderungskatalog. Sie enthält eine Vorauswahl von Anforderungen und vorgegebene Parameter.

Funktion der Blaupausen

Blaupausen können einzelnen Assets oder Gruppen von Assets zugeordnet werden. Sie unterstützen die Zusammenstellung des individuellen Anforderungspakets, ersetzen jedoch nicht die institutionsbezogene Schutzbedarfsfeststellung, die Erfassung der relevanten Assets oder eine erforderliche Risikobetrachtung.

Auswahl und Anwendung

• Eignung für das konkrete Anwendungsszenario prüfen.
• Auswahl einschließlich Version, Zuordnung und vorgenommene Anpassungen nachvollziehbar dokumentieren.
• Bei unvollständiger Abdeckung weitere Blaupausen oder zusätzliche Anforderungen ergänzen.
• Bei Änderungen des Informationsverbunds oder der verfügbaren Blaupausen die Auswahl überprüfen und erforderlichenfalls anpassen.
• Beachten, dass es für bestimmte Institutionen verpflichtende Blaupausen geben kann.

Eine Institution kann Anforderungen aus mehreren Blaupausen beziehen. Bereits festgeschriebene Parameter, etwa aus einer Blaupause, sind bei der Konkretisierung des Anforderungspakets zu berücksichtigen. Ein konkretes technisches OSCAL-Profil- oder SSP-Verfahren beschreibt der Standard nicht.

Grundlagen und Standards

• BSI-Standard 300-1: Methodik Grundschutz++ – methodische Grundlage dieser Darstellung.
• Stand-der-Technik-Bibliothek – bei der Nutzung ist der konkrete Katalogstand zu berücksichtigen.
• OSCAL (Open Security Controls Assessment Language) – technische Hintergrundinformationen.

Die bisherigen Standards 200-1 bis 200-4 sind gesonderte Dokumente. Ob sie im konkreten Vorhaben zusätzlich heranzuziehen sind und welche Übergangsregelungen gelten, ist anhand der einschlägigen aktuellen BSI-Veröffentlichungen zu prüfen; eine pauschale Regel hierzu enthält 300-1 nicht.

Schritt-für-Schritt-Methodik

Grafik: Prozessschritte

Der Standard beschreibt fünf iterative Prozessschritte. Die folgende Übersicht fasst die wesentlichen Aktivitäten zusammen; sie ersetzt weder den Standard noch die Methodik-Anforderungen des Katalogs.

Schritt 1: Erhebung und Planung (PLAN)

1. Internen und externen Kontext der Institution erheben und relevante Einflussfaktoren dokumentieren.
2. Compliance-Management beziehungsweise zuständige Stellen einbinden; rechtliche, regulatorische, interne und vertragliche Vorgaben erheben.
3. Anwendungsbereich durch die Institutionsleitung festlegen und Schnittstellen sowie Abgrenzungen berücksichtigen.
4. Interessierte Parteien und ihre relevanten Anforderungen und Erwartungen analysieren.
5. Geschäftsprozesse im Anwendungsbereich identifizieren und dokumentieren.
6. Für jeden Geschäftsprozess den Schutzbedarf hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit ermitteln und dokumentieren: „normal“ oder „hoch“. Eigene zusätzliche Kategorien sind auf diese Kategorien abzubilden.
7. Informationssicherheitsleitlinie mit Sicherheitszielen, Strategie und Leitungsverpflichtung entwickeln, durch die Institutionsleitung freigeben und allen Mitarbeitenden kommunizieren.
8. Sicherheitsorganisation mit Rollen, Zuständigkeiten, Kompetenzen und Schnittstellen festlegen; Interessenkonflikte vermeiden und Beteiligung der Sicherheitsorganisation an sicherheitsrelevanten Projekten regeln.
9. Verfahren zur internen und externen Kommunikation sowie zur Dokumentenlenkung verankern.
10. Wesentliche Entscheidungen, Schutzbedarfsfeststellung, Bearbeitungsreihenfolge und Ressourcen durch die Institutionsleitung freigeben lassen.
11. Rahmen der Risikobetrachtung festlegen: Verfahren, Rollen einschließlich Risikoeigentümerschaft, Bewertungskriterien, Risikoappetit und Risikoakzeptanzkriterien. Die Institutionsleitung autorisiert diesen Rahmen.

Bei erstmaliger Implementierung empfiehlt der Standard, mit dem wichtigsten Geschäftsprozess aus der höchsten Schutzbedarfskategorie zu beginnen. Sukzessive sind alle Geschäftsprozesse des Anwendungsbereichs zu untersuchen. Die Verantwortung für die Umsetzung des ISMS verbleibt bei der Institutionsleitung und ist nicht delegierbar. Siehe Kapitel 2 des Standards.

Ergebnis: Freigegebener organisatorischer und methodischer Rahmen, dokumentierte Geschäftsprozesse und Schutzbedarfe sowie festgelegte Bearbeitungsreihenfolge.

Weiterführende Informationen:

• Informationssicherheitsleitlinie
• IS-Strategie
• Geschäftsprozesse

Schritt 2: Anforderungsanalyse (PLAN)

1. Informationsverbund abgrenzen und Schnittstellen zu externen Prozessen, Systemen und anderen Informationsverbünden dokumentieren; auch Outsourcing und Cloud-Dienste berücksichtigen.
2. Relevante Assets erfassen. Vorhandene Register, CMDBs, Netzpläne und Betriebsdokumentationen können genutzt werden. Bei ähnlichen Eigenschaften und Einsatzzwecken ist Gruppierung möglich.
3. Erforderliche Abhängigkeiten dokumentieren:
   • Bei hohem Schutzbedarf: Zugehörigkeit und wesentliche Abhängigkeiten der Assets zum Geschäftsprozess nachvollziehbar abbilden; dies unterstützt die spätere Risikobetrachtung entlang des Ressourcenpfades.
   • Bei normalem Schutzbedarf: Die Dokumentation der Geschäftsprozesszugehörigkeit der Assets ist nicht erforderlich. Mindestens die Abhängigkeiten zwischen Anwendungen und IT-Systemen sowie zwischen IT-Systemen und Räumen dokumentieren.
4. Geeignete beziehungsweise verpflichtende Blaupausen auswählen und deren Version, Zuordnung und Anpassungen festhalten.
5. Assets den passenden Zielobjektkategorien einschließlich aller übergeordneten Kategorien zuordnen.
6. Anforderungspaket zusammenstellen:
   • Methodik-Anforderungen verpflichtend auf jeden Informationsverbund anwenden.
   • Alle weiteren Anforderungen ohne zugewiesene Zielobjektkategorie verpflichtend aufnehmen.
   • Assetbezogene Anforderungen anhand der zugeordneten Zielobjektkategorien berücksichtigen.
   • Erforderliche Ergänzungen aus Compliance, Stakeholder-Anforderungen und Risikobetrachtung aufnehmen.
7. Parameter konkretisieren, soweit keine festgeschriebenen Parameter, beispielsweise aus einer Blaupause, vorliegen. Die Konkretisierung kann bei oder nach der Erstellung des Anforderungspakets erfolgen.

Anforderungen des Sicherheitsniveaus „erhöht“ enthalten das Modalverb KANN und sind optional. Sie können als Ausgangspunkt zur Ermittlung zusätzlicher Maßnahmen in der Risikobetrachtung dienen. Hoher Schutzbedarf bedeutet nicht, dass pauschal jede erhöhte KANN-Anforderung verpflichtend umzusetzen ist. Siehe Kapitel 3 des Standards.

Ergebnis: Individuelles Anforderungspaket für den Informationsverbund einschließlich nachvollziehbarer Zuordnungen und Parameterfestlegungen.

Weiterführende Informationen:

• Strukturanalyse
• Stand-der-Technik-Bibliothek auf GitHub

Schritt 3: Realisierung (DO)

1. Aktuellen Umsetzungsstatus jeder Anforderung vollständig überprüfen und dokumentieren: „erfüllt“, „nicht erfüllt“ oder „nicht anwendbar“.
2. „Nicht anwendbar“ begründen. Der Standard nennt hierfür funktionale Nichterfüllbarkeit oder das Fehlen der zugrunde liegenden Komponente im Informationsverbund. Der Status ist nicht mit einer Risikoakzeptanz gleichzusetzen.
3. Fehlende Umsetzungen nach Modalverb behandeln:
   • MUSS: Maßnahmen zur Erfüllung festlegen. Keine Ausnahmegenehmigung und keine die Erfüllung ersetzende Risikoakzeptanz.
   • SOLLTE, temporär nicht erfüllt: Absehbare Umsetzung einplanen und die Nichterfüllung stichhaltig begründen. Restrisiko betrachten und durch die Institutionsleitung freigeben lassen.
   • SOLLTE, dauerhaft nicht erfüllt: Explizite Risikobetrachtung durchführen und verbleibende Restrisiken durch die Institutionsleitung freigeben lassen.
   • KANN: Umsetzung optional.
4. Erforderliche explizite Risikobetrachtungen durchführen. Auslöser sind:
   • Hoher Schutzbedarf eines Geschäftsprozesses bei mindestens einem Schutzziel.
   • Nicht hinreichende Abdeckung eines relevanten Assets durch Zielobjektkategorien und zugeordnete Anforderungen.
   • Dauerhafte Nichterfüllung einer anwendbaren SOLLTE-Anforderung.
5. Risiken identifizieren, im Risikoregister dokumentieren und Risikoeigentümern zuweisen. Grundsätzlich ist dies die geschäftsprozessverantwortliche Person, sofern nichts anderes festgelegt wurde. Eintrittshäufigkeit und Schadensauswirkung bewerten, Risikoniveau bestimmen und mit den Risikoakzeptanzkriterien abgleichen.
6. Risikobehandlung festlegen: Reduktion, Vermeidung, Transfer oder Akzeptanz. Maßnahmen und Risiken nachvollziehbar zuordnen; verbleibende Restrisiken durch die Institutionsleitung autorisieren lassen. Die Umsetzungsplanung der Risikobehandlungsmaßnahmen wird durch die Risikoeigentümer autorisiert.
7. Umsetzungsplan mit konkreten Maßnahmen, Prioritäten, Zuständigkeiten, Fristen und Ressourcen erstellen; das Vorgehen durch die Institutionsleitung freigeben lassen.
8. Anforderungen, Maßnahmen und Nachweise eindeutig verknüpfen. Für jede Maßnahme mindestens zugehörige Anforderung, Umsetzungs- beziehungsweise Überprüfungsdatum und dokumentierende beziehungsweise prüfende Person festhalten. Bei automatisierten Prüfungen Tool, Prüfzeitpunkt und Ergebnis dokumentieren und vorhandene Prüfberichte zuordnen.
9. Fortschritt kontinuierlich nachhalten, Hindernisse behandeln und den Umsetzungsplan aktualisieren. Interessenkonflikte zwischen Umsetzung und Fortschrittsverfolgung durch angemessene Rollenverteilung vermeiden.

Abgrenzung bei temporärer Nichterfüllung: Kapitel 4.1.2 des Standards erklärt, dass eine temporäre Nichterfüllung einer SOLLTE-Anforderung keine Risikobetrachtung auslöst. Kapitel 2.11 des Standards verlangt hierfür dennoch eine Restrisikobetrachtung mit Leitungsfreigabe. Die Aussagen sind nebeneinander zu berücksichtigen; der Standard beschreibt kein gesondertes Detailverfahren für diese Abgrenzung.

Das Verfahren der Risikobetrachtung ist frei wählbar, muss aber die 35 verbindlichen Mindestkriterien aus Anhang 3 des Standards erfüllen. Die Risikobetrachtung ist mindestens jährlich sowie bei wesentlichen Änderungen zu überprüfen.

Ergebnis: Dokumentierter Umsetzungsstatus, Risikoregister, autorisierte Risikobehandlung und fortgeschriebener Umsetzungsplan mit Nachweisen.

Weiterführende Informationen:

• Leitfaden Grundschutzcheck
• RiLi-Freigabe
• Richtlinie zum Management von Ausnahmen und Abweichungen

Schritt 4: Überwachung (CHECK)

1. Wirksamkeit des ISMS und seiner Ziele durch eine geeignete Leistungsbewertung überprüfen. Eine einheitliche GS++-Berechnungsmethode schreibt der Standard noch nicht vor.
2. Internes Auditprogramm planen und durchführen; Ziele, Risiken, Umfang, Ressourcen und erforderliche Kompetenzen berücksichtigen. Objektivität und Unparteilichkeit sicherstellen.
3. Ergebnisse und relevante Informationen in einem Managementbericht aufbereiten.
4. Institutionsleitung auf Grundlage des Managementberichts die Eignung, Angemessenheit und Wirksamkeit des ISMS bewerten lassen. Unter anderem Auditergebnisse, Leistungsbewertung, Sicherheitsvorfälle, Risikobehandlungsstatus, Änderungen und frühere Managemententscheidungen berücksichtigen.
5. Verfahren zur Erkennung von Sicherheitsvorfällen, zum Umgang mit Schwachstellen sowie zur Erfassung und Behandlung neuer Bedrohungen verankern und mit der Risikobetrachtung verbinden.
6. Anforderungspaket regelmäßig auf Aktualität und Angemessenheit überprüfen. Änderungen des Informationsverbunds, der Stand-der-Technik-Bibliothek, verwendeter Blaupausen und der Methodik berücksichtigen.

Monitoring kann je nach Größe und Komplexität von manuellen Verfahren bis zu automatisierten Systemen reichen. Der Standard schreibt nicht pauschal den Einsatz eines SIEM oder eines bestimmten Scanners vor. Siehe Kapitel 5 des Standards.

Ergebnis: Leistungsbewertung, Auditberichte, Managementbericht und Managementbewertung sowie dokumentierter Anpassungsbedarf.

Weiterführende Informationen:

• Reifegradmodell
• Key Performance Indicators (KPIs)
• Erstellen eines Managementberichts

Schritt 5: Kontinuierliche Verbesserung (ACT)

1. Nichtkonformitäten erfassen und Ursachen analysieren; Wiederauftreten und vergleichbare Abweichungen in anderen Bereichen berücksichtigen.
2. Verbesserungspotenziale aus Audits, Vorfällen, Bedrohungsentwicklung, Prozesserfahrungen und Vorschlägen der Mitarbeitenden identifizieren und bewerten.
3. Korrektur- und Verbesserungsplan erstellen und in den Umsetzungsplan aufnehmen; Maßnahmen risikoorientiert priorisieren und Zuständigkeiten festlegen.
4. Maßnahmen umsetzen, Fortschritt nachverfolgen und anhand geeigneter Kriterien prüfen, ob Ursachen beseitigt und angestrebte Verbesserungen erreicht wurden.
5. Ergebnisse dokumentieren, relevante Erkenntnisse in die Risikobetrachtung zurückführen und erforderliche Anpassungen des ISMS vornehmen.
6. Ein strukturiertes Verfahren zur Behandlung von Compliance-Verstößen etablieren und anwenden.

Die Verbesserung kann Änderungen an Maßnahmen, Verfahren, Risikobetrachtung oder Anforderungspaket erfordern. Nicht jede Verbesserung führt zwingend zu einer Änderung des Anforderungspakets. Siehe Kapitel 6 des Standards.

Ergebnis: Dokumentierte Korrekturen und Verbesserungen, überprüfte Wirksamkeit und bei Bedarf angepasste ISMS-Unterlagen als Grundlage der nächsten Iteration.

Praktische Hinweise

• Iteration: Bei erstmaliger Implementierung möglichst mit dem wichtigsten Geschäftsprozess der höchsten Schutzbedarfskategorie beginnen; anschließend alle Prozesse des Anwendungsbereichs bearbeiten.
• Vorhandene Daten nutzen: Prozessübersichten, CMDB, Asset-Register, Netzpläne und Betriebsdokumentationen können Doppelarbeit vermeiden.
• Dokumentationsform: Der Standard lässt für verschiedene Dokumentationen ausdrücklich Tabellen, Wiki, CMDB oder andere geeignete Formen zu. Eine allgemeine Pflicht, sämtliche ISMS-Dokumentation in OSCAL zu führen, ergibt sich daraus nicht.
• Tools: Geeignete Tools können Auswahl, Dokumentation, Prüfung und Fortschrittsverfolgung unterstützen. Sie ersetzen keine fachlichen Entscheidungen und Freigaben.
• Überprüfung: Die Risikobetrachtung ist mindestens jährlich sowie bei wesentlichen Änderungen zu überprüfen. Für den gesamten PDCA-Zyklus legt der Standard keine einheitliche jährliche Zyklusdauer fest; Überwachung und Verbesserung erfolgen regelmäßig und anlassbezogen.

Migration bestehender Sicherheitskonzepte

Bisher gibt es noch keine offizielle MIgrationsstrategie von Grundschutz auf Grundschutz++. Es gibt erste KI-basierte Ansätze aus der Community, jedoch noch keine allgemein anerkannte Lösung.

Weiterführende Informationen:

Grundschutz++ Migration

Offenen Punkte und Kritiken

Zu viele Beteiligte, unklare Zuständigkeiten

Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

Unklare Umsetzung einiger Ziele

Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

Geringer Mehrwert im Vergleich zu ISO 27001

Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards und die deutliche Schrumpfung zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

Zu ambitionierter Zeitplan

Der Grundschutz++ soll ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2031 vorgesehen ist. Bisher ist nur eine unvollständige erste Version eines Leitfadens zur Methodik veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher größtenteils nur als Entwurf vor. Eine Pilotierung und Einführung 2026/27 und eine Übergangsphase bis 2031 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

Zunehmende (Sicherheits-)Lücke zwischen IT-Grundschutz und Grundschutz++

Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2031 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

Bislang kein Sicherheitsgewinn gegenüber Kompendium Edition 2023

Ein erkennbarer Sicherheitsgewinn durch Grundschutz++ gegenüber dem IT‑Grundschutz-Kompendium (Edition 2023, Redaktionsschluss 2022) ist bislang nicht gegeben. Das BSI befasst sich weiterhin mit dem Standard selbst, jedoch ohne erkennbare inhaltliche Weiterentwicklung im Grundschutz seit 2023. Der aktuelle Anwenderkatalog basiert weiterhin auf einem abgespeckten Kompendium der Edition 2023. Wesentliche von Anwendern geforderte Aktualisierungen, insbesondere zu aktuellen Themen wie Cloudnutzung und KI-Einsatz und anderen aktuellen Bedrohungs- und Technologietrends, sind bislang nicht berücksichtigt.

Fehlende Migration vom IT-Grundschutz-Kompendium zu Grundschutz++

Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

Überholte Satzschablonen

Die oben beschriebenen Satzschablonen waren vor OSCAL ein erster Versuch, Anforderungen durch eine feste Syntax maschinenlesbar vorzubereiten. Der Eisatz von OSCAL macht sie jedoch überflüssig, da Praktiken und Zielobjektkategorien flexibel in Metadaten (props, groups, links) abgebildet und gefiltert werden können. So lassen sich Anforderungstexte natürlich-sprachlich formulieren. Das verbessert die Lesbarkeit für Mitarbeitende und Tools gleichermaßen. GS++ verwendet dennoch weiterhin diese sperrige Satzschablonen-Syntax für Anforderungen, was umfangreiche Erläuterungstexte zu den Anforderungen erfordert.

Fazit

Ein abschließendes Bild zur Umsetzung von Grundschutz++ lässt sich aktuell noch nicht zeichnen – einige Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit einigen Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein nachvollzieharer echter Mehrwert des neuen Standards ist daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.

Ausblick und ToDos aus Anwendersicht

Stichtag für die Einführung von Grundschutz++ war der 1.1.2026. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und praktische Umsetzungsempfehlungen oder Leitfäden zur Methodik.

Der Standard 300-1 zur Methodik Grundschutz++ bildet hier eine Basis, hilft hier nur begrenzt.

Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Zertifizierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:

• Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
• Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
  • Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln in jeweils einem Satz/Absatz zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
• Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
• Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab 2027.
• Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
• Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

Weiterführende Ressourcen

• BSI-Standard 300-1 - Methodik zum Grundschutz++
• Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.
• Grundschutz++ Viewer zur Anzeige des OSCAL Grundschutz++ Katalogs
• Praxisleitfaden zur Umsetzung von Grundschutz++
• Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++
• BSI IT-Grundschutz
• Grundschutz++ Seite des BSI mit Meilensteinplan (Stand Oktober 2026)
• 30 Jahre IT-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024
• Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025
• Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)
• Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025
• Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025