Grundschutz++ Einführung und Aufbau

Diese Seite ist derzeit noch ein Entwurf. Weitere Informationen sowie Diskussionen über Änderungen an diesem Entwurf gibt es evtl. auf der Diskussion-Seite.

---

Dieser Artikel bietet einen schrittweisen Überblick über BSI Grundschutz++ und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.

Einführung in Grundschutz++

Grundschutz++ ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.

Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.

Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.

Wesentliche Neuerungen

• OSCAL/JSON-basiertes Regelwerk: Der IT-Grundschutz wird in ein maschinenlesbares JSON-Format überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
• Prozessorientierte Struktur: Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
• Leistungskennzahlen: Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
• Harmonisierung mit ISO 27001: Die Anforderungen werden stärker mit internationalen Standards wie ISO 27001:2022 abgestimmt, um Doppelzertifizierungen zu vereinfachen.
• Erweiterung um moderne Technologien: Geplant sind auch spezifische Module für Cloud-Security, KI und IoT, die aktuelle Bedrohungsszenarien abdecken.

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.

Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

Hinweis: Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller Starttermin für den Grundschutz++ war der 1.1.2026. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf GitHub veröffentlicht.

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 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.

Satzschablonen

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

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

Praktik: Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. Liste der gültigen Praktiken.

Zielobjekt: Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). Liste der Gültigen Zielobjekte.

Modalverb: Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN).

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.

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.

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 kein spezifisches Zielobjekt benannt.

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

Priorisierung

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

• Stufe 0: Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (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.

Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.

Leistungskennzahlen

Leistungskennzahlen dienen der Messung und Bewertung der Umsetzung von Sicherheitsanforderungen im Grundschutz++. 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.

Bewertungskriterien

Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:

• Vertraulichkeit (C)
• Integrität (I)
• Verfügbarkeit (A)

Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.

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.

Was bleibt erhalten?

Standards und Vorgehen

Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:

1. Festlegung des Geltungsbereichs
2. Strukturanalyse
3. Schutzbedarfsfeststellung
4. Modellierung
5. IT-Grundschutzcheck (GSC)
6. Risikoanalyse

bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der Modellierung und den Grundschutzchecks). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

MUSS-Anforderungen sind weiterhin verpflichtend für eine Zertifizierung, sollen aber deutlich rediziert werden.

SOLLTE-Anforderungen bleiben auch weiter grundsätzlich verpflichtend, können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich KANN-Anforderungen sind optional.

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.

Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++

Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) 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 kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. 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 nicht bekannt.
	Das Kompendium ist (Stand 2023) in 10 Schichten mit insgesamt 111 Bausteine gegliedert, die statisch die jeweiligen Anforderungen enthalten.	Praktiken und Zielobjekte/Zielobjektkategorien (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Maßnahmen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden. 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 Zielobjekten zugeordnet. Zielobjekte entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor unklar!
	Drei Stufen (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.	Es sind zukünftig sechs Stufen (0–5) geplant, 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.	Zielobjekte werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und Modellierung haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
	Modalverben MUSS, SOLLTE, KANN bestimmen die Verbindlichkeit von Anforderungen.	Die Bedeutung der Modalverben (MUSS, SOLLTE, KANN) bleibt 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 voraussichtlich bis 2029	Gültig ab 1.1.2026. Zertifizierbar geplant ab 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.	Zielobjekt sind zukünftig das was bislang die Bausteine waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjekten zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe steht noch aus.

Blaupausen

Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.

Funktion der Blaupausen

Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.

Ziel und Nutzen

• Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
• Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
• Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.

Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.

Umsetzung

Umgesetzt werden Blaupausen technische als OSCAL-Profile mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem System Security Plan (SSP) weiter entwickelt werden.

Grundlagen und Standards

• BSI-Standard 200-1: Anforderungen an ein ISMS.
• BSI-Standard 200-2: IT-Grundschutz Methodik ( <- Wird neu erstellt )
  • Methodik zum Grundschutz++ (Aktuell in Erstellung, ersetzt 200-2)
• BSI-Standard 200-3: Risikomanagement mit Grundschutz.
• BSI-Standard 200-4: Business Continuity Management
• OSCAL (Open Security Controls Assessment Language).

Schritt-für-Schritt-Methodik

Die Methodik-Grundschutz++ folgt einem 5-stufigem PDCA-basierten Prozess mit Fokus auf Anforderungsmodellierung und maschinenlesbarer Verarbeitung. Hier das praktische Vorgehen:

Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance)

1. Kontextanalyse (intern/extern) durchführen
2. Interessierte Parteien identifizieren und Anforderungen erfassen
3. Geltungsbereich (Scope) durch Institutionsleitung festlegen und freigeben
4. Geschäftsprozesse priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
5. Sicherheitsleitlinie erstellen (Ziele, Strategie, Verpflichtung Leitung)
6. Sicherheitsorganisation etablieren (Rollen: ISB, Asset-Owner, etc.)
7. Compliance-Management initialisieren (Rechts-/Vertragskatalog)

Ergebnis: Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse​

Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung)

1. Informationsverbund definieren (techn./org. Abgrenzung)
2. Assets für wichtigsten Geschäftsprozess erfassen
3. Asset → Zielobjektkategorien mapping (Hierarchie + Vererbung)
4. Anforderungspaket generieren:
   • ISMS-Praktiken (vollständig)
   • Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
   • Zielobjektlose Anforderungen prüfen
5. Ergänzungen: Externe Verpflichtungen, anforderungslose Assets
6. Risikobetrachtung bei hohem Schutzbedarf oder Niveauerhöhung
7. Parameter setzen (Zuständigkeiten, Werte)

Ergebnis: Individuelles Anforderungspaket pro Informationsverbund​

Schritt 3: Realisierung (DO - Umsetzung)

1. Umsetzungsstatus aller Anforderungen prüfen (ja/nein)
2. Nicht-umgesetzte MUSS/SOLLTE → Risikobetrachtung
3. Umsetzungsplan erstellen:
   • Priorisierung (Risiko, Aufwand, Synergien)
   • Zuständigkeiten + Fristen zuweisen
4. Freigabe durch Institutionsleitung
5. Fortschritt tracken (Ticketsystem/Projektmanagement)
6. Ausnahmen dokumentieren (Begründung + Leitungsfreigabe)

Ergebnis: Umsetzungsplan + Status-Dokumentation​

Schritt 4: Überwachung (CHECK - Monitoring/Evaluation)

1. Leistungsbewertung (KPIs, Umsetzungsfortschritt, Vorfälle)
2. Compliance-Überwachung (gesetzlich/vertraglich)
3. Auditprogramm risikobasiert durchführen
4. Managementbewertung → Managementbericht erstellen
5. Monitoring-Tools einsetzen (SIEM, Vulnerability Scanner)
6. Anforderungspaket validieren (Aktualität prüfen)

Ergebnis: Auditberichte, Managementbericht​

Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung)

1. Nicht-Konformitäten analysieren
2. Verbesserungspotenziale identifizieren
3. Korrektur-/Verbesserungsplan → in Umsetzungsplan integrieren
4. Wirksamkeit prüfen nach Umsetzung
5. Sicherheitsniveau bewerten (Trendanalyse)
6. Compliance-Verstöße behandeln

Ergebnis: Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus​

Praktische Hinweise

• Tool-gestützt: JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
• Iteration: Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
• Risikobetrachtung: Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
• Dokumentation: bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

Zyklusdauer: Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

Fazit

Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele 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 erheblichen Risiken und 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 realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind 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 konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). 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 Methodik und Modellierung 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 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 Mitte 2026.
• 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 IT-Grundschutz
• 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
• Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.
• Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.
• Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++