Grundschutz++ erklärt: Was der neue BSI IT-Grundschutz für Unternehmen verändert

Wo stehen wir heute? Grundschutz++ ist im Juli 2026 noch kein fertig ausgerollter Nachfolger des bisherigen IT-Grundschutzes, sondern eine anwendbare Pilotfassung, die das BSI gemeinsam mit Pilotpartnern erprobt.

Relevant bleibt das Thema trotzdem, denn die Richtung steht fest: Der IT-Grundschutz wird digitaler, stärker an Prozessen ausgerichtet und so strukturiert, dass Werkzeuge seine Inhalte direkt verarbeiten können. Für Unternehmen und Behörden beginnt deshalb jetzt die Zeit der Vorbereitung und Weichenstellung, um Fehlinvestitionen, Mehrfachaufwände und Ressourcenengpässe zu vermeiden.

Grundschutz++ ist die umfassende Modernisierung des BSI IT-Grundschutzes. Die Anforderungen werden in der Stand-der-Technik-Bibliothek als maschinenlesbare OSCAL-Daten im JSON-Format bereitgestellt. Der aktuelle BSI-Stand nennt 19 Praktiken und 921 Anforderungen. Die Pilotierungsphase läuft bis zum 30. September 2026; die Veröffentlichung der Methodik ist für die it-sa 2026 vom 27. bis 29. Oktober vorgesehen. Zertifizierungsanträge nach ISO 27001 auf Basis von Grundschutz++ sollen ab dem 1. Januar 2027 möglich sein.

Grundschutz++ ist weder ein neues Gesetz noch ein zusätzliches Compliance-Framework, das Unternehmen und Behörden neben ISO 27001, NIS2 und DORA „auch noch“ einführen müssen. Es ist die Reform der BSI-Vorgehensweise, mit der Organisationen ein Informationssicherheits-Managementsystem aufbauen, betreiben und nachweisen können.

Der bisherige IT-Grundschutz ist stark durch umfangreiche Norm- und Methodikdokumente, Anforderungskataloge, Umsetzungshinweise und periodische Editionen geprägt. Grundschutz++ verschiebt den Schwerpunkt auf eine prozessorientierte Methodik und eine strukturierte Datenbasis. Das Ziel des BSI: Inhalte modernisieren und den Aufwand im ISMS reduzieren, insbesondere dort, wo sich Prozesse automatisieren oder Daten mehrfach nutzen lassen.[1][2]

Der entscheidende Begriff lautet deshalb nicht „weniger Kontrollen“, sondern besser verarbeitbare Kontrollen. Dieser stammt aus dem OSCAL-Datenmodell, in dem einzelne Anforderungen als Controls geführt werden; gemeint sind die bekannten Grundschutz-Anforderungen, keine zusätzliche Kontrollebene. Anforderungen sollen eindeutig strukturiert, versionierbar, filterbar und in Werkzeugen weiterverwendbar sein.

Das eröffnet Spielraum für eine stärker datengetriebene Sicherheitssteuerung, zum Beispiel durch Dashboards zum Umsetzungsstand, Hinweise bei Katalogänderungen oder Kennzahlen aus verknüpften Nachweisen. Es nimmt der Organisation aber nicht die Verantwortung für Entscheidungen, Risiken, Maßnahmenumsetzung oder Wirksamkeitskontrolle ab.

Strategisch gewinnt Grundschutz++ zusätzlich durch NIS2 an Gewicht. Wichtige und besonders wichtige Einrichtungen müssen angemessene Maßnahmen unter Berücksichtigung des Stands der Technik treffen. Die Stand-der-Technik-Bibliothek macht BSI-Sicherheitsanforderungen maschinenlesbar zugänglich und bietet damit eine wichtige fachliche Orientierung. Ob ein Unternehmen betroffen ist und welche Maßnahmen im konkreten Kontext angemessen sind, bleibt eigenständig zu prüfen.[3][6][7]

OSCAL steht für Open Security Controls Assessment Language. Das offene Datenmodell beschreibt Sicherheitsanforderungen und zugehörige Informationen in maschinenlesbarer Form. Das BSI stellt seine digital strukturierten Sicherheitsanforderungen in der Stand-der-Technik-Bibliothek bereit; der Grundschutz++-Anwenderkatalog liegt dort als JSON-Datei vor.[2][3]

Für die Praxis sind vor allem fünf Effekte relevant:

1. Änderungen werden technisch vergleichbar: Statt zwei PDF-Ausgaben manuell gegeneinander zu lesen, können Werkzeuge Versionen und Deltas auswerten.
2. Inhalte lassen sich kontinuierlich pflegen: Änderungen bleiben einer konkreten Katalogversion zugeordnet und damit nachvollziehbar.
3. Kataloge kommen als offizielle Datenquelle in die Werkzeuge: Unterstützte ISMS- und GRC-Werkzeuge können den versionierten Originalkatalog einlesen, statt Inhalte jeweils proprietär zu übertragen.
4. Profile lassen sich zielgerichteter zusammenstellen: Ein Profil ist ein gefiltertes, organisationsspezifisches Anforderungspaket: Die Organisation übernimmt die für ihren Kontext relevanten Inhalte und verarbeitet sie weiter.
5. Nachweise lassen sich systematischer anbinden: Ein Ticket kann die Umsetzung einer Anforderung dokumentieren, ein Messwert ihre Wirksamkeit belegen und eine Richtlinie den organisatorischen Rahmen nachweisen. In integrierten Werkzeugen kann die Bewertung dadurch weitgehend aus verknüpften Quellen unterstützt werden.

Das ist die Grundlage für „Compliance as Code“ – sofern Prozesse, Daten und Nachweise sauber integriert sind. Eine JSON-Datei allein macht noch keine Organisation compliant.

Der aktuelle Pilotkatalog organisiert die Inhalte in 19 Praktiken. Das BSI unterscheidet organisatorische, technische und übergreifende ISMS-Praktiken. Die Methodik folgt damit stärker den Aufgaben, die eine Organisation dauerhaft beherrschen muss: von Governance und Strukturmodellierung bis zu Detektion, Reaktion und kontinuierlicher Verbesserung in einer Bedrohungslandschaft, die sich durch den Einsatz von KI in der Cyberkriminalität weiter verändert. [4]

Die fünf ISMS-Praktiken bilden den Steuerungskreislauf:

• GC – Governance und Compliance: Ziele, Rahmenbedingungen und Verpflichtungen verankern.
• STM – Strukturmodellierung: den Informationsverbund erfassen und ein passendes Anforderungspaket ableiten.
• UMS – Umsetzung: Sicherheitsmaßnahmen planen, realisieren und dokumentieren.
• PERF – Monitoring-Evaluation: Wirksamkeit, Fortschritt und Eignung überprüfen.
• VRB – Verbesserung: Abweichungen behandeln und das ISMS weiterentwickeln.

Hinzu kommen jeweils sieben organisatorische und technische Praktiken. Diese Struktur soll wiederkehrende Sicherheitsaufgaben näher an Verantwortlichkeiten und operative Abläufe bringen. Für Unternehmen bedeutet das: Ein künftiges Mapping sollte nicht nur fragen „Welcher alte Baustein entspricht welchem neuen Eintrag?“, sondern auch „Welcher Prozess liefert den Nachweis, wer trägt die Verantwortung und aus welchem System kommen die Daten?“

Die bisherigen Absicherungsstufen Basis, Standard und erhöhter Schutzbedarf sollen laut BSI durch flexible Leistungszahlen mit dynamischen Schwellwerten abgelöst werden. Ergänzend sind Priorisierung und Gewichtung der Anforderungen als Entscheidungshilfe für die Umsetzungsreihenfolge vorgesehen. Wie die Leistungszahlen konkret berechnet werden, ist im Pilotstand noch nicht final festgelegt. [1]

Einen niederschwelligen Einstieg bieten die WiBA-Checklisten (Weg in die Basis-Absicherung), die fester Bestandteil von Grundschutz++ werden sollen. Ausgangspunkt ist der maschinenlesbare Anwenderkatalog. Aus ihm sollen zukünftig Anforderungen gefiltert werden, die zum jeweiligen Anwendungsfall passen, orientiert an Zielobjektkategorien und institutionellem Kontext. Kleine Institutionen können damit grundlegende Anforderungen umsetzen, ohne zuvor ein vollständiges ISMS aufzubauen. Die genauen Erzeugungsregeln entwickelt das BSI im laufenden Prozess weiter.

Der offizielle Fahrplan trennt Pilotierung, Auswertung, Veröffentlichung und Zertifizierbarkeit.

• 1. April 2026: Start der Pilotierungsphase mit einer anwendbaren Fassung der Methodik.
• 30. September 2026: Ende der Pilotierungsphase; Rückmeldungen fließen in die Weiterentwicklung ein.
• 27. bis 29. Oktober 2026: geplante Veröffentlichung der Methodik auf der it-sa 2026.
• 1. Januar 2027: Grundschutz++ soll zertifizierbar sein; Zertifizierungsanträge nach ISO 27001 auf Basis von Grundschutz++ können laut BSI gestellt werden.

Für die Unternehmensplanung folgt daraus ein nüchterner Schluss: 2026 ist das Jahr für Vorbereitung und begrenzte Pilotierung, nicht für eine unkritische Vollmigration. Organisationen können Daten, Rollen, Werkzeuge und Prozesse bereits ausrichten. Methodische Details, die das BSI erst nach der Pilotphase finalisiert, sollten sie jedoch nicht vorwegnehmen.

Für Bestandszertifikate gilt: Der aktuelle BSI-Fahrplan nennt keinen sofortigen Wegfall der Edition 2023 und noch kein verbindliches Ende der Übergangsphase. Wer 2026 oder 2027 eine Re-Zertifizierung plant, sollte die konkrete Planung deshalb mit Zertifizierungsstelle und aktuellem BSI-Stand abgleichen.

Ein etabliertes ISMS wird durch Grundschutz++ nicht wertlos. Im Gegenteil: Wer Geltungsbereich, Asset- und Risikoverantwortung, Richtlinien, Maßnahmen, Auditprozesse und Nachweise sauber organisiert hat, besitzt die wichtigsten Ausgangsdaten bereits.

Weiterverwendbar sind insbesondere:

• der definierte Scope des ISMS,
• das Inventar von Informationen, Prozessen, Anwendungen, Infrastruktur und Dienstleistern,
• Rollen und Freigabewege,
• Risiko- und Ausnahmeregelungen,
• Umsetzungspläne, Findings und Maßnahmenverfolgung,
• technische und organisatorische Nachweise.

Neu zu denken ist die Daten- und Prozesslogik. Dokumente sollten nicht länger nur als abgeschlossene Dateien betrachtet werden. Entscheidend wird, ob eine Organisation Informationen richtig managen und zuordnen kann: Welche Anforderung gilt für welchen Kontext? Wer ist zuständig? Was beweist die Umsetzung? Wann wurde dieser Nachweis zuletzt geprüft? Welche Änderung im Katalog betrifft uns?

Grundschutz++ kann dabei helfen, Nachweise oder regulatorische Anforderungen konsistenter zu organisieren. Die geplante Zertifizierung bleibt eine ISO-27001-Zertifizierung auf Basis von IT-Grundschutz. Nicht ersetzt werden die NIS2-Betroffenheitsanalyse und die eigenständige Bewertung weiterer regulatorischer Pflichten.

Prüfen Sie, ob Ihre Strukturdaten die heutige Realität abbilden: von Cloud- und SaaS-Diensten über ausgelagerte Betriebsleistungen bis zu Schnittstellen, Benutzerkonten und Berechtigungen. Erfassen Sie auch Datenflüsse und kritische Abhängigkeiten. Eine veraltete Inventarliste wird auch durch OSCAL nicht besser.

Benennen Sie Owner nicht nur für Assets, sondern auch für Risiken, Sicherheitsprozesse und Evidenz. Eine Anforderung ist erst steuerbar, wenn klar ist, wer entscheidet, wer umsetzt und wer die Wirksamkeit bestätigt.

Erstellen Sie ein Evidenzinventar. Ordnen Sie Richtlinien, Tickets, Protokolle, technische Messwerte und Auditberichte den relevanten Anforderungen zu. Achten Sie auf Version, Gültigkeit, Quelle und Prüftermin. Das ist unabhängig vom finalen Grundschutz++-Stand schon jetzt sinnvoll.

Fragen Sie Hersteller konkret nach OSCAL-Import und -Export, Versionsvergleich, Profilbildung, Parametrisierung, API-Anbindung und vollständigem Audit Trail. Lassen Sie sich konkrete Produktstände und Exportmöglichkeiten zeigen. Vermeiden Sie Lösungen, die Daten ausschließlich proprietär speichern und einen späteren Wechsel unnötig erschweren.

Starten Sie mit einem überschaubaren, aber relevanten Bereich – etwa einem Cloud-Service, einem Kernprozess oder einer klar abgegrenzten Plattform. Mappen Sie vorhandene Kontrollen und Nachweise auf den Pilotkatalog. Dokumentieren Sie dabei nicht nur fachliche Lücken, sondern auch Daten-, Rollen- und Toolprobleme. Erst danach lässt sich der Aufwand für eine größere Migration seriös schätzen.

Grundschutz++ wird häufig als Toolthema verkauft. Das greift zu kurz, aber die Werkzeugwahl kann den Übergang deutlich erleichtern oder dauerhaft blockieren. Für eine belastbare Bewertung sollten mindestens diese Fragen beantwortet sein:

• Kann das Werkzeug OSCAL-JSON nativ importieren und wieder exportieren?
• Werden Katalogversionen und Änderungen nachvollziehbar verglichen?
• Lassen sich Profile, Parameter und organisationsspezifische Ergänzungen getrennt verwalten?
• Können Nachweise aus Ticketing, Cloud-Plattformen, IAM, Vulnerability Management oder SIEM angebunden werden?
• Bleiben Entscheidungen, Ausnahmen, Freigaben und Prüfhistorien revisionssicher erhalten?
• Ist ein Wechsel des Werkzeugs möglich, ohne das gesamte Kontroll- und Evidenzmodell neu aufzubauen?

Die Liste ist nicht vollständig, bietet aber einen belastbaren ersten Anhaltspunkt, bevor der gesamte Funktionsumfang und weitere Auswahlfaktoren eines GRC- oder ISMS-Werkzeugs bewertet werden.

Grundschutz++ hat das Potenzial, mehrere Probleme der traditionellen Methodik dauerhaft zu entschärfen. Die Stand-der-Technik-Bibliothek und OSCAL schaffen eine Grundlage, um Sicherheitsanforderungen schneller zu verarbeiten, Änderungen gezielter zu erkennen und Nachweise konsistenter zu organisieren.

Die Umstellung ist kein Selbstläufer. Sie verlagert Arbeit – weg von redundanter Dokumentpflege, hin zu sauberer Datenhaltung, klaren Verantwortlichkeiten, integrationsfähigen Werkzeugen und überprüfbarer Wirksamkeit.

Der seriöse Weg lautet daher: Grundlagen ordnen, Pilotbereich auswählen, BSI-Entwicklung beobachten und nach der Pilotphase neu bewerten. So wird Grundschutz++ nicht zum nächsten Compliance-Sonderprojekt, das im Big-Bang-Chaos versinkt, sondern zur logischen Weiterentwicklung eines funktionierenden ISMS.

Wir prüfen Scope, Rollen, Evidenzmodell und Toollandschaft und entwickeln daraus einen belastbaren Readiness- und Migrationspfad – abgestimmt auf ISO 27001, IT-Grundschutz und Ihre regulatorischen Anforderungen.

Quellen:

_[1] BSI: Grundschutz++ – Meilensteine und aktueller Stand

_[2] BSI: Pilotierung Grundschutz++ im Anwenderkatalog

_[3] BSI: Stand-der-Technik-Bibliothek

_[4] BSI: Grundschutz++-Anwenderkatalog, OSCAL/JSON, Stand 24. Juni 2026

_[5] BSI: IT-Grundschutz++ – aktueller Umfang des digitalen Katalogs

_[6] BSI: Stand der Technik – Auftrag und Bibliothek

_[7] BSI: Fragen und Antworten zu NIS2