GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
Der IT-Grundschutz des BSI ist seit Jahren die wohl deutscheste Antwort auf eine sehr internationale Frage: Wie organisiert man Informationssicherheit so, dass sie im Alltag funktioniert, auditierbar bleibt und trotzdem mit der Technik Schritt hält? Mit „Grundschutz++“ kündigt sich nun die nächste Evolutionsstufe an – eine Fortentwicklung, die den Standard stärker digitalisiert, prozessorientierter macht und für die kommenden Jahre fit. Das BSI hat dazu im Sommer 2025 ausdrücklich den Dialog mit der Fachöffentlichkeit gesucht und den Namen „IT-Grundschutz++“ als Arbeitstitel gesetzt. Ziel: Modernisierung ohne Bruch, also Kontinuität dort, wo sie sinnvoll ist, und spürbare Vereinfachungen dort, wo die Praxis es braucht.
Dieser Beitrag ordnet den Kontext ein, erklärt die Design-Ideen hinter Grundschutz++, zeigt, was sich wahrscheinlich verändert (und was nicht), und gibt konkrete Hinweise, wie sich Organisationen – vom Mittelständler bis zur Behörde – heute so aufstellen, dass der Übergang locker gelingt. Wir stützen uns dabei auf die offiziellen BSI-Informationen zum IT-Grundschutz und auf frühe, öffentliche Berichte aus der Praxiscommunity, die die Digitalisierung und Maschinenlesbarkeit des Standards, eine stärkere Objekt-/Prozessorientierung sowie Übergangsfristen skizzieren.
Wenn ein Standard über Jahre erfolgreich genutzt wird, sammelt er zwangsläufig Ballast: Redundanzen, Wiederholungen, Detail-Abzweige für Spezialfälle. Gleichzeitig verändern sich IT-Landschaften dramatisch: Cloud-First, API-Ökosysteme, Software-defined Everything, DevOps und Automatisierung prägen die Realität. In genau diesem Spannungsfeld setzt Grundschutz++ an:
Kurz: Grundschutz++ zielt auf gleiche Sicherheit, weniger Papier, mehr Bits – und damit auf praktische Entlastung bei Planung, Betrieb und Audit.
Das BSI hat die Fortentwicklung des IT-Grundschutz ausdrücklich als Dialogprozess aufgesetzt („BSI im Dialog“). Der Arbeitstitel „IT-Grundschutz++“ ist dabei Programm: evolutionär, nicht revolutionär. Parallel berichten Community-Beiträge aus Herbst/Winter 2024 von Leitplanken: maschinenlesbare Inhalte, Objekt-/Prozessorientierung, Abbau von Redundanzen und Übergangsfristen für die Migration bestehender Umsetzungen. Natürlich sind das Zwischenstände – deshalb ist es sinnvoll, Aussagen als Road-Signals zu lesen, nicht als endgültige Normtexte.
Für die Grundidee, Arbeitsweise und Aufbau des „klassischen“ Grundschutz (BSI-Standards, Kompendium, methodische Schritte) bleibt die offizielle BSI-Dokumentation maßgeblich – und sie ist der wichtigste Anker, um Änderungen in Grundschutz++ einzuordnen.
a) Vom Papier zur API
Bislang leben viele Umsetzungen in PDFs, Tabellen, Wiki-Seiten. Künftig soll es offizielle, maschinenlesbare Standard-Artefakte geben (beispielsweise JSON/XML). Der Nutzen ist enorm:
Das ist exakt der Schritt, den viele Sicherheits- und DevOps-Teams sich seit Jahren wünschen.
b) Vom Baustein zur „Sicht aufs System“
Der Grundschutz war nie „nur Checkliste“, aber in der Praxis wurde er oft so benutzt. Die geplante, stärkere Objekt-/Prozessorientierung sorgt dafür, dass die Sicht auf Geschäftsprozesse, Services und Assets wieder ins Zentrum rückt – und dass dieselbe Anforderung nicht in x Kapiteln wiederholt wird. Ergebnis: kürzere Wege, weniger Doppelt-Dokumentation und ein klareres Verständnis, wo welche Controls wirken.
c) Evolution statt Big Bang
Das BSI stellt den Dialog und Übergangsfristen in Aussicht. Unternehmen müssen also nicht über Nacht die Welt neu erfinden, sondern können parallel arbeiten: bewährte Umsetzungen stabil halten, neue Artefakte erproben, Tool-Integrationen aufbauen. Das senkt Migrationsrisiken.
Weiterentwicklungen anhand offizieller Methodik einordnen. Prüfen Sie vor einer Umstellung die aktuellen BSI-Veröffentlichungen und den Status des jeweiligen Konzepts. Eine bestehende Schutzbedarfs- und Maßnahmenzuordnung sollte erst mit begründeter Entscheidung verändert werden.
Zeigt den Weg von Strukturanalyse und Schutzbedarf zu Modellierung und Maßnahmen. Unterstützt die systematische Absicherung und die Einbettung des IT-Grundschutzes in ein tragfähiges Sicherheitsmanagement.
Von Dr. Markus Groß
Bleibt: die Methodik
Die BSI-Standards 200-1/-2/-3 (ISMS, Grundschutz-Vorgehen, Notfallmanagement) haben das Vorgehen sauber strukturiert – Risiko- und Schutzbedarfsfeststellung, Modellierung, Umsetzung, Wirksamkeitskontrolle. Daran wird Grundschutz++ nicht den Grundpfeiler sägen. Die Modernisierung betrifft Form, Zugriff und Konsistenz der Inhalte, nicht den Sinn.
Ändert sich: die Bereitstellung
Statt monolithischer PDFs sind versionierte, maschinenlesbare Inhalte zu erwarten (z. B. als Datensätze mit eindeutigen IDs, Referenzen, Gültigkeiten). Fachlich ist das nichts anderes als heute – praktisch aber der Unterschied zwischen Analog und API
Ändert sich: Redundanz & Querverweise
Die Community erwartet weniger Wiederholungen, klare Objektbezüge (z. B. Endgerät, Anwendung, Cloud-Service) und präzisere Querverlinkungen. Die Konsequenz: Weniger „Suchen und interpretieren“, mehr „sehen und verknüpfen“.
Bleibt: Anschlussfähigkeit an ISO 27001
Der IT-Grundschutz war immer anschlussfähig an die ISO-Welt – bis hin zur ISO-27001-Zertifizierung auf Basis von IT-Grundschutz. Es gibt keinerlei Hinweis, dass Grundschutz++ diesen Brückenschlag aufgibt – im Gegenteil: maschinenlesbare Controls erleichtern sogar die Mappung auf andere Kataloge (ISO 27002, NIST CSF, DORA-Controlfamilien etc.).
Wenn Anforderungen maschinenlesbar sind, können Sie Ihr ISMS, Ihre CMDB, Ihr ITSM und Ihre Security-Werkzeuge enger koppeln. Drei unmittelbare Effekte:
Statt 20-seitiger Maßnahmenlisten mit Überlappung entsteht eine klare Sicht pro Prozess und pro Objekt. Für die Praxis heißt das:
Mit maschinenlesbaren Grundschutz-Artefakten wandelt sich Dokumentation von „PDF zum Abheften“ zu „Daten, die arbeiten“:
Niemand muss warten, bis jede Spezifikation final ist. Sie können heute beginnen – und gewinnen doppelt: Sie verbessern Ihr aktuelles Grundschutz-Niveau und räumen Hindernisse für Grundschutz++ aus dem Weg.
Schritt 1: Ihre „Daten-Hausaufgaben“
Die Digitalisierung eines Standards verpufft, wenn Ihr Asset- und Service-Inventar lückenhaft ist. Investieren Sie jetzt in:
Schritt 2: „Kontroll-Bausteine“ entmonolithisieren
Zerlegen Sie bestehende Policies in kleine, prüfbare Statements. Beispiel: Aus „Wir verschlüsseln mobile Endgeräte“ werden einzelne Assertions wie „BitLocker/ FileVault aktiv“, „TPM genutzt“, „Recovery-Keys sicher hinterlegt“, „Status täglich verifiziert“. Diese Atomic Controls sind die perfekte Brücke in eine maschinenlesbare Welt.
Schritt 3: Nachweis als Datenfluss denken
Definieren Sie für zentrale Controls Datenquellen (z. B. MDM-Inventar, IdP-Audit-Logs, Vulnerability-Scanner, Cloud Security Posture Management) und bauen Sie ETL-/API-Pipelines zum ISMS. Ziel: weniger manuelle Uploads, mehr automatische Evidenz.
Schritt 4: Reporting für Menschen, nicht für Schubladen
Designen Sie Management-Dashboards, die Fragen beantworten („Sind unsere kritischen Services nächste Woche audit-ready?“) statt Tabellenfriedhöfe zu stapeln. So wird der Mehrwert der Digitalisierung sichtbar – und politisch tragfähig.
Auditoren prüfen künftig weniger „Dokumente als Zustand“ und mehr „Daten als Verlauf“: Werkszustände, Änderungen, Ausnahmen, Wirksamkeitsmessungen. Das ist gut – für beide Seiten:
Weil die Grundmechanik des IT-Grundschutz erhalten bleibt, ist nicht zu erwarten, dass bestehende ISO-27001-Zertifizierungen auf Basis von IT-Grundschutz entwertet werden. Eher im Gegenteil: Mappings werden leichter, Vergleichsberichte verlässlicher.
„Das wird der große Bruch – alles neu.“
Nein. Es ist eine Weiterentwicklung. Wer heute sauber nach IT-Grundschutz arbeitet, steht bestens da – er kann viele Artefakte direkt migrieren und profitiert als Erster von der Digitalisierung.
„Wir warten lieber, bis alles hundertprozentig final ist.“
Das klingt vernünftig, kostet aber Zeitvorteil. Ihre Hausaufgaben (Inventare, Objektmodelle, Schnittstellen, atomare Controls) sind standards-unabhängig wertvoll – und exakt das, was Grundschutz++ erleichtern will.
„Das wird nur mehr Bürokratie – jetzt auch noch in JSON.“
Nur wenn man es falsch anlegt. Ziel ist Entlastung: einmal definieren, vielfach nutzen – mit Automatisierung statt Copy-Paste.
DORA, NIS2, KRITIS 2.0, ISO-Welt – kein Unternehmen arbeitet noch singulär nach nur einem Regelwerk. Die maschinenlesbare Bereitstellung von Grundschutz-Inhalten ist die Brücke, die viele seit Jahren vermissen: ein Control, mehrere Mappings. Das erleichtert:
Aus dem angekündigten Dialog lässt sich ablesen, womit man rechnen darf:
Für die Praxis entscheidend: Mitgestalten. Wer sich heute in den Dialog einbringt – über Verbände, Arbeitskreise, öffentliche Rückmeldungen – prägt mit, wie gut Grundschutz++ morgen in Tools und Prozessen landet.
Grundschutz++ ist kein Marketing-Label, sondern die logische Fortentwicklung eines bewährten Standards: digitaler, prozessorientierter, integrierter. Das BSI setzt dafür bewusst auf Dialog und Evolution statt Big Bang. Für Organisationen ist das eine große Chance:
Wer heute beginnt, Inventare, Objektmodelle, Schnittstellen und Atomic Controls sauber aufzusetzen, wird Grundschutz++ nicht „einführen“, sondern mit minimaler Reibung hineinwachsen – und genau darum geht es: Sicherheit, die arbeitet.
(Hinweis: „Grundschutz++“ ist ein Arbeitstitel der Fortentwicklung. Details befinden sich in laufender Erarbeitung und Konsultation. Oben genannte Nutzen, Beispiele und Vorgehensvorschläge sind praxiserprobte Interpretationen im Lichte der verfügbaren öffentlichen Informationen; maßgeblich bleiben die jeweils aktuellen Veröffentlichungen des BSI.)
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Deine Bewertung hilft bei der Einordnung der Inhalte.
Interessant für dein Netzwerk? Teile den Beitrag direkt.
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.
We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.
Comments 42
Eine Frage zur Umsetzung: wie aus der formalen Vorgabe eine wirksame Sicherheitsroutine wird. Welche Beobachtung wäre wichtiger als eine reine Vollständigkeitsquote?
Aus meiner Sicht sollte man mit einem kritischen, aber überschaubaren Fall beginnen. Daran werden fehlende Zuständigkeiten meist schneller sichtbar als in einer allgemeinen Bewertung.
Ein konkreter Fall hilft, aber die Zuständigkeit muss von Anfang an klar sein. Sonst ist zwar das Problem sichtbar, die notwendige Entscheidung bleibt aber liegen.
Ich würde ebenfalls mit einem konkreten Fall starten. Wichtig sind dabei eine eindeutige Zuständigkeit, ein überprüfbares Ergebnis und ein Termin, an dem die Wirkung erneut bewertet wird.
Damit wird es für mich deutlich greifbarer. Vor allem die vorher festgelegte Entscheidungsfolge verhindert, dass der Pilot nur als zusätzlicher Bericht endet.
Danke für die Einordnung. Wie gelingt ein überschaubarer Einstieg, wenn zunächst wenig Zeit zur Verfügung steht?
Ich würde die wichtigsten Anwendungen und Informationen abgrenzen. Für diesen Bereich lassen sich Zuständigkeiten und die dringendsten Maßnahmen zuerst klären.
Wie verhindert man, dass die Auswahl der Bausteine zu einer reinen Vollständigkeitsübung wird? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Für mich liegt der Schwerpunkt hier: Ich würde die Modellierung mit der tatsächlichen Umgebung abgleichen. Die Auswahl sollte begründbar sein und die relevanten Leistungen und Abhängigkeiten abbilden.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen.
Wie geht man mit Besonderheiten um, die ein Standardbaustein nicht vollständig abdeckt? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Das ist ein wichtiger Punkt. Diese Lücke würde ich ausdrücklich festhalten und gesondert bewerten. Ein passender Baustein wäre für mich ein Ausgangspunkt, keine Garantie für vollständige Abdeckung.
Ich lese das etwas anders. Für mich steht zuerst die Frage im Raum, ob der zugrunde liegende Bedarf überhaupt ausreichend geklärt ist. Meine Ausgangsfrage bleibt: Wie geht man mit Besonderheiten um, die ein Standardbaustein nicht vollständig abdeckt?
Eine überprüfbare Zuständigkeit wäre für mich die Basis. Dazu gehört auch, wer die notwendige Information liefert und wer handelt, wenn sie fehlt. Auf die Ausgangsfrage bezogen: Diese Lücke würde ich ausdrücklich festhalten und gesondert bewerten. Ein passender Baustein wäre für mich ein Ausgangspunkt, keine Garantie für vollständige Abdeckung.
Damit kann ich mehr anfangen. Die Grenze zwischen einem hilfreichen Nachweis und zusätzlichem Papier bleibt für mich der entscheidende Punkt. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Was wäre ein praktikabler erster Schritt für eine kleine Organisation?
Mein Vorschlag wäre: Ich würde den Untersuchungsumfang begrenzen und die wichtigsten Abläufe erfassen. Daraus ließe sich ein nachvollziehbarer Ausbau ableiten.
Reicht ein Prüfbericht des Anbieters, wenn die eigene Nutzung ganz anders aussieht? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Daran würde ich anknüpfen. Ich würde den betrachteten Dienst und die Grenzen des Berichts abgleichen. Eine Aussage über den Anbieter ersetzt für mich keine Prüfung der eigenen Konfiguration.
Guter Punkt. Ich würde zusätzlich fragen, was passieren soll, wenn sich die Voraussetzungen während des Betriebs ändern.
Dazu eine Rückfrage: Wie hält man ein umfangreiches Modell aktuell, wenn sich die IT laufend verändert? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Ich sehe darin vor allem eine Gestaltungsfrage. Ich würde die Pflege an Änderungen im Betrieb koppeln. Eine seltene Gesamtüberarbeitung könnte sonst lange mit einem veralteten Bild arbeiten.
Das klingt nachvollziehbar, aber der Aufwand ist damit noch nicht geklärt. Welchen Teil würdest du zuerst angehen? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Ich würde lieber einen vorhandenen Ablauf sinnvoll ergänzen als einen zweiten daneben aufbauen. Voraussetzung ist, dass der gemeinsame Ablauf die unterschiedliche Bedeutung der Aufgaben sichtbar lässt. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Wie verhindert man, dass eine Übung nur den gut vorbereiteten Idealfall testet? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Wie verhindert ihr bei Abgrenzung des Informationsverbunds, dass eine vorläufige Lösung ohne erneute Prüfung dauerhaft bestehen bleibt?
Ich würde einen festen Wiedervorlagetermin und eine klare Entscheidung über Fortführung oder Abschluss vorsehen. Wichtig ist, dass die Ausnahme nicht allein deshalb bestehen bleibt, weil niemand mehr nachfragt. Mit Blick auf Abgrenzung des Informationsverbunds würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Wer entscheidet, welches Restrisiko akzeptiert wird, und wie lange gilt diese Entscheidung? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Daran würde ich anknüpfen. Für mich müssten Zuständigkeit und Prüfanlass festgehalten werden. Eine einmalige Freigabe sollte nicht unbegrenzt weitergelten, wenn sich die Grundlage verändert.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Welche minimale Lösung wäre für Priorisierung offener Basisanforderungen vertretbar, wenn unter Zeitdruck eine Ausnahme erforderlich wird?
Ich würde die Ausnahme befristen und mit einem benannten Verantwortlichen sowie einer späteren Überprüfung verbinden. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Priorisierung offener Basisanforderungen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Welcher konkrete Prüfpunkt wäre bei Abgleich von Dokumentation und Umsetzung für einen ersten Umsetzungsschritt besonders hilfreich?
Für den Einstieg würde ich einen klar abgegrenzten Ablauf mit einem erwarteten Ergebnis wählen. So lässt sich früh erkennen, wo Verantwortlichkeit, Nachweis oder praktische Umsetzung noch fehlen. Für Abgleich von Dokumentation und Umsetzung würde ich den ersten Prüfschritt bewusst klein halten.
Wie würdet ihr Abgleich von Dokumentation und Umsetzung konkret prüfen, wenn verschiedene Systeme dieselbe Information unterschiedlich abbilden?
Mein Vorschlag wäre, eine maßgebliche Quelle bestimmen und Abweichungen gezielt untersuchen, bevor Kennzahlen daraus abgeleitet werden. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei Abgleich von Dokumentation und Umsetzung sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Ergänzend würde ich den Blick auf eine praktikable Grundschutz-Umsetzung richten. Welche Mindestinformation wird dafür im Alltag wirklich benötigt?
Für eine praktikable Grundschutz-Umsetzung sollte feststehen, welche Annahmen der Bewertung zugrunde liegen. Sonst wird ein Status zu lange fortgeschrieben.
Interessant finde ich hier vor allem eine praktikable Grundschutz-Umsetzung. Ein kleiner, sauber ausgewerteter Pilot wäre aussagekräftiger als eine breite Papierlösung.
Für die praktische Anwendung zählt aus meiner Sicht eine praktikable Grundschutz-Umsetzung. Sonst wirkt formal alles vollständig, ohne Entscheidungen zu verbessern.
Mich überzeugt besonders der Bezug zu eine praktikable Grundschutz-Umsetzung. Ein konkreter Anwendungsfall könnte zeigen, wo der Ansatz noch zu abstrakt bleibt.
Ich würde eine praktikable Grundschutz-Umsetzung zunächst an einem kritischen, aber überschaubaren Fall testen. Dann lassen sich Aufwand und Nutzen vernünftig vergleichen.