A-R-C Consulting

Informationssicherheitsmanagement

Grundschutz++: Jetzt migrationsfähig werden, ohne eine fertige Methodik vorzutäuschen

Ein fertiger „Migrationsleitfaden zu Grundschutz++“ würde mehr Gewissheit versprechen, als die offizielle Lage am 2. August 2026 hergibt. Das BSI entwickelt Grundschutz++ als neuen, prozessorientierten und maschinenlesbaren Ansatz. Der Meilensteinplan mit Stand 26. März 2026 setzt das Ende der Pilotierung auf den 30. September 2026 und die Veröffentlichung der Methodik auf den 27. Oktober 2026.

Von Andreas Rühl · 1. August 2026 · Quellen geprüft am 2. August 2026

Hinweis: Allgemeine fachliche Einordnung; keine Rechtsberatung, Zertifizierungs- oder Auditgarantie.

Damit ist Grundschutz++ relevant, aber noch kein fertiges Zielbild, das Organisationen einfach verbindlich ausrollen sollten. Genau diese Zwischenphase erzeugt ein Managementproblem: Nichts zu tun kann später teure Nacharbeit verursachen. Zu früh alles umzubauen kann ebenso teuer werden, wenn Pilotfeedback und finale Methodik Details verändern.

Die belastbare Zwischenstrategie besteht in Vorarbeiten, die das ISMS migrationsfähig machen, ohne die heutige Steuerung zu destabilisieren.

Der Schmerz liegt in semantischer Altlast, nicht im Dateiformat

Viele Grundschutz-Umgebungen besitzen umfangreiche Dokumentation: Strukturanalysen, Modellierungen, Bausteinzuordnungen, Maßnahmenlisten, Prüfprotokolle und Richtlinien. Trotzdem sind zentrale Beziehungen oft nur für erfahrene Personen verständlich. Verantwortlichkeiten stehen in Freitext. Nachweise liegen in Ablagen, deren Logik nicht mit dem Kontrollmodell verbunden ist. Ausnahmen werden per E-Mail entschieden. Objektkennungen unterscheiden sich zwischen Inventar, Risikoliste und Auditplan.

Ein maschinenlesbares Regelwerk löst diese Probleme nicht automatisch. Wenn uneinheitliche Begriffe digitalisiert werden, entsteht lediglich schneller verarbeitbare Uneinheitlichkeit.

Eine hypothetische Betriebsszene zeigt die semantische Altlast. Im Inventar heißt ein Dienst „Zentraler Verzeichnisdienst“, in der Risikoanalyse „Identity Plattform“ und im Auditplan nur „IAM“. Drei Teams meinen weitgehend dasselbe, aber kein System kann die Beziehungen zuverlässig auflösen. Fällt die verantwortliche Person aus, wird aus vermeintlich vollständiger Dokumentation eine Suchaufgabe. Vor einer Migration müsste dann nicht nur ein Format konvertiert, sondern Bedeutung rekonstruiert werden.

Genau deshalb beginnt Migrationsfähigkeit mit stabilen Beziehungen. Ein Objekt muss wiedererkennbar bleiben, wenn sein Name geändert, eine Maßnahme angepasst oder ein Nachweis erneuert wird. Anforderungen, Umsetzung, Evidenz und Entscheidung dürfen getrennte Datensätze sein; ihre Verbindung darf jedoch nicht nur aus Ablagepfaden oder Erfahrungswissen bestehen. Erst diese semantische Ordnung macht spätere Regeln auswertbar.

Ein PDF wird nicht zum Prozess, nur weil es in einer Prozessbibliothek liegt. Der Mechanismus ist einfach: Ein Prozess braucht Auslöser, Rollen, Eingaben, Entscheidungen, Ergebnisse und Rückkopplung. Ein Dokument kann das beschreiben, aber nicht allein betreiben.

Semantische Ordnung ist deshalb keine Aufräumübung für das ISMS-Team, sondern eine Vereinbarung zwischen Fachbereichen, Betrieb, Risikomanagement und Audit. Der Fachbereich kennt die Bedeutung eines Dienstes, der Betrieb seine technische Zusammensetzung, das Risikomanagement die akzeptierten Auswirkungen und Audit die erforderliche Nachweisführung. Wird nur eine dieser Perspektiven zum führenden Datenmodell erklärt, entstehen scheinbar saubere, aber unbrauchbare Zuordnungen. Ein technisches System kann beispielsweise mehreren Geschäftsprozessen dienen; dieselbe Kontrolle kann je nach Nutzung unterschiedliche Evidenz oder Verantwortliche benötigen. Migrationsfähigkeit verlangt nicht, diese Unterschiede einzuebnen. Sie verlangt, sie ausdrücklich abzubilden und Änderungen kontrolliert durch die betroffenen Rollen zu führen.

Die typische Fehlsteuerung besteht darin, Datenqualität als einmaliges Bereinigungsprojekt zu finanzieren. Ein Projektteam harmonisiert Namen, schließt leere Felder und liefert ein grünes Dashboard. Sechs Monate später erzeugen Beschaffung, Change Management und Organisationsänderungen wieder neue Objekte, ohne dieselben Regeln zu verwenden. Management muss daher einen Erhaltungsmechanismus für Kennungen, Beziehungsfreigaben, Review-Auslöser und eskalationspflichtige Qualitätsabweichungen verlangen. Erst dann wird aus Datenbereinigung Governance.

Was das BSI derzeit tatsächlich ankündigt

Die BSI-Seite beschreibt Grundschutz++ als flexible, vollständig prozessorientierte Neuentwicklung mit Mindestanforderungen. Anforderungen sollen als standardisierte Regeln erfasst werden, damit Programme sie interpretieren und auswerten können. Die „Stand der Technik“-Bibliothek soll das bisherige IT-Grundschutz-Kompendium ablösen und technische sowie organisatorische Anforderungen bereitstellen. Das BSI stellt außerdem dynamische Priorisierung, Leistungsmessung und anpassbare Checklisten in Aussicht. Die bisherigen Absicherungsstufen lassen sich nach der offiziellen Darstellung nicht auf Grundschutz++ übertragen.

Das ist ein relevantes Architekturversprechen. Es ist aber noch keine Einladung, den bestehenden IT-Grundschutz sofort als erledigt zu betrachten. Die Pilotierung soll praktische Erfahrungen in die Weiterentwicklung einbringen. Der Meilensteinplan staffelt die nächsten Schritte: Veröffentlichung der Methodik am 27. Oktober 2026, Schulungskonzept am 31. Oktober, Ausbildungsbeginn am 1. November, Zertifizierungsanträge für ISO 27001 auf Basis von Grundschutz++ ab 1. Januar 2027, Veröffentlichung der Leistungsmessung am 26. Februar 2027 und der Leistungskennzahlen am 31. März 2027.

Organisationen sollten daher drei Ebenen sauber trennen:

  1. Heute gültige Praxis: bestehende ISMS- und Grundschutz-Verpflichtungen, laufende Audits, vereinbarte Nachweise und die bis zu einer geregelten Umstellung benötigten Kompendiumsbezüge.
  2. Offiziell angekündigte Zielrichtung: prozessorientierte, regelbasierte, maschinenlesbare Anforderungen und flexiblere Priorisierung.
  3. Eigene Vorbereitung: reversible Verbesserungen, die unabhängig von finalen Details nützlich sind.

Fünf migrationsfähige Vorarbeiten mit geringem Reuepotenzial

1. Eindeutige Objekte und Verantwortliche schaffen

Jedes relevante Objekt – Prozess, Anwendung, System, Standort, Lieferant oder Informationswert – braucht eine stabile Kennung und einen verantwortlichen Eigentümer. Diese Kennung sollte in Inventar, Risiko, Kontrolle, Nachweis und Maßnahmenplan wiederverwendet werden.

Das ist keine Grundschutz++-Spezialanforderung. Es ist saubere Steuerung und verhindert, dass Migration später zu einer manuellen Zuordnungsübung wird.

In einem begrenzten hypothetischen Test erhält deshalb zunächst ein Geschäftsprozess eine stabile Kennung. Anwendungen, Systeme, Risiken und Nachweise werden nicht umbenannt, sondern über diese Kennung verbunden. Schon dabei zeigt sich, ob zwei Bereiche denselben Prozess unterschiedlich abgrenzen oder ob ein System zwar technisch betreut wird, aber niemand die fachliche Risikoverantwortung übernimmt. Die Entscheidung ist dann konkret: Abgrenzung harmonisieren, Verantwortung zuweisen oder die Differenz bewusst dokumentieren. Eine neue Plattform ist dafür nicht erforderlich.

2. Anforderungen von Umsetzungsdetails trennen

Formulieren Sie, welches Sicherheitsergebnis erreicht werden soll, getrennt davon, wie es heute umgesetzt wird. Eine lösungsunabhängige Anforderung kann mit mehreren technischen oder organisatorischen Maßnahmen erfüllt werden. Diese Trennung erleichtert spätere Regelzuordnung, Toolunterstützung und Änderungskontrolle.

Wichtig: Bestehende Baustein- und Maßnahmenlogik wird nicht vorschnell verworfen. Sie wird so strukturiert, dass Beziehungen exportierbar und überprüfbar werden.

3. Evidenz als erstklassiges Steuerungsobjekt behandeln

Für jede wesentliche Kontrolle sollte bekannt sein, welche Evidenz ihre Durchführung und Wirksamkeit belegt, wo sie liegt, wer sie liefert, welchen Zeitraum sie abdeckt und wann sie erneuert wird. Ein Screenshot ohne Kontext oder ein Prüfprotokoll ohne Objektbezug ist nur eingeschränkt wiederverwendbar.

Evidenz-Metadaten sind ein besonders migrationssicherer Baustein. Sie helfen heutigen Audits und künftiger Automatisierung gleichermaßen.

Hypothetisch betrachtet ein Auditteam einen Screenshot, der eine aktivierte Sicherheitseinstellung zeigt. Ohne Zeitstempel, Objektbezug, Ersteller und Prüfschritt bleibt offen, ob er das produktive System, eine Testumgebung oder einen inzwischen überholten Zustand abbildet. Mit diesen Metadaten wird aus einer Datei ein einordenbarer Nachweis. Der Mechanismus ist unspektakulär, aber wirksam: Automatisierung braucht nicht mehr Wahrheit als Menschen, nur deutlich weniger Toleranz für fehlenden Kontext.

Für die Steuerung folgt daraus eine einfache Entscheidungsfolge. Zuerst wird festgelegt, welche Aussage eine Kontrolle belegen soll. Danach wird bestimmt, welche Evidenz diese Aussage trägt und in welchem Turnus sie erneuert werden muss. Erst dann ist sinnvoll zu entscheiden, ob die Gewinnung manuell, teilautomatisiert oder vollständig automatisiert erfolgt. Wer mit dem Tool beginnt, automatisiert sonst womöglich nur die Produktion hübscher Dateien.

4. Ausnahmen und Risiken entscheidungsfähig machen

Abweichungen brauchen einen Bezug zu Objekt und Anforderung, eine Risikobegründung, kompensierende Maßnahmen, einen autorisierten Entscheider und ein Ablaufdatum. Freitext darf die Entscheidung erläutern, aber nicht ihre Struktur ersetzen.

Ohne Ablaufdatum und Review-Auslöser wird eine temporäre Ausnahme leicht zum Normalbetrieb, ohne erneut entschieden zu werden.

Angenommen, eine hypothetische Altanwendung kann eine Anforderung derzeit nicht vollständig erfüllen. Die Ausnahme verweist auf das betroffene Objekt und die konkrete Anforderung, beschreibt eine kompensierende Überwachung und endet mit dem geplanten Austausch der Anwendung. Verschiebt sich das Projekt, öffnet sich die Entscheidung erneut. Das Management kann dann die Übergangskontrolle verstärken, die Restlaufzeit begrenzen oder den Ersatz priorisieren.

5. Exportierbarkeit testen, bevor ein Zieltool gewählt wird

Organisationen müssen jetzt kein Grundschutz++-Tool auswählen. Sie sollten aber prüfen, ob aktuelle Daten aus Inventar, Risiko-, Maßnahmen- und Evidenzverwaltung strukturiert exportiert werden können. Proprietäre Freitextfelder und manuelle Verknüpfungen sind Migrationsrisiken.

Ein einfacher Test exportiert zehn Kontrollen samt Objekt, Verantwortlichem, Status, Nachweis und letzter Entscheidung in einen konsistenten strukturierten Datensatz. Wo das nicht gelingt, besteht sinnvoller Vorbereitungsbedarf – unabhängig vom späteren Format der BSI-Bibliothek.

Ein hypothetischer Betriebsfall macht die Wechselwirkungen sichtbar

Ein mittelgroßer, ausdrücklich hypothetischer Dienstleister wählt für sein Readiness-Lab den Prozess „Benutzerzugänge bereitstellen und entziehen“. Der Prozess nutzt eine zentrale Identitätsplattform, ein Ticketsystem, einen extern betriebenen Verzeichnisdienst und manuelle Freigaben für privilegierte Rollen. Im aktuellen Sicherheitskonzept sind die Komponenten beschrieben. In der Praxis besitzen Fachbereich, IT-Betrieb und Revision jedoch unterschiedliche Listen der privilegierten Konten. Eine automatisierte Auswertung würde diese Uneinigkeit nicht beseitigen, sondern drei widersprüchliche Ergebnisse in vorbildlicher Geschwindigkeit liefern.

Das Lab beginnt deshalb mit einer stabilen Prozesskennung und verbindet daran Systeme, Rollen, Anforderungen, Maßnahmen und Evidenz. Beim ersten Export fällt auf, dass das Ticketsystem den Genehmiger dokumentiert, aber nicht die fachliche Rolle, auf deren Risiko die Freigabe erfolgt. Der externe Dienst liefert einen monatlichen Bericht, dessen Betrachtungszeitraum nicht mit der internen Stichprobe übereinstimmt. Außerdem besitzt eine alte Ausnahme für technische Konten weder einen aktuellen Owner noch ein belastbares Ende. Keine dieser Lücken beweist, dass die Kontrolle unwirksam ist. Gemeinsam verhindern sie aber eine nachvollziehbare Aussage darüber, was kontrolliert wurde, für welchen Zeitraum und auf wessen Entscheidung.

Die organisatorische Folge ist kein sofortiger Toolwechsel. Der Process Owner bestätigt die Prozessgrenze, der Betrieb ordnet die technischen Objekte zu, das Risikomanagement öffnet die Ausnahme und die Revision präzisiert die erwartete Aussage der Evidenz. Danach wird derselbe Datensatz erneut exportiert. Management erkennt, welche Beziehungen zuverlässig sind, welche Annahmen manuell bestätigt werden und welche Lücke eine Entscheidung benötigt. So wird kein perfektes Modell vorweggenommen, sondern die Fähigkeit aufgebaut, Unklarheit sichtbar zu machen und kontrolliert zu bearbeiten.

Ein zweigleisiger Fahrplan bis zur Methodik-Veröffentlichung

Die erste Spur stabilisiert den heutigen Betrieb. Laufende IT-Grundschutz-Aktivitäten, Audits, Sicherheitskonzepte und Verbesserungsmaßnahmen werden nicht gestoppt. Bestehende Kompendiumsbezüge und interne Verpflichtungen bleiben nachvollziehbar, bis eine belastbare Umstellung auf Methodik und „Stand der Technik“-Bibliothek beschlossen ist; eine unveränderte Übernahme der bisherigen Absicherungsstufen wird nicht unterstellt.

Die zweite Spur ist ein begrenztes Readiness-Lab. Wählen Sie einen überschaubaren Informationsverbund oder Prozess. Harmonisieren Sie Kennungen, Anforderungen, Evidenzmetadaten und Ausnahmen. Dokumentieren Sie Annahmen ausdrücklich. Jede Änderung muss rücknehmbar sein und einen heutigen Nutzen besitzen.

Das Lab sollte keine Parallelwelt mit Sonderbegriffen und handverlesenen Vorzeigeobjekten bauen. Sinnvoller ist ein kleiner, aber normaler Ausschnitt mit echten Unschärfen: ein Prozess mit mehreren Anwendungen, einem externen Dienst und mindestens einer offenen Maßnahme. Dort lässt sich prüfen, ob Beziehungen exportierbar sind, ob Verantwortliche dieselben Begriffe verwenden und ob eine Änderung von der Anforderung bis zur Entscheidung verfolgt werden kann. Scheitert der Test, ist das kein Projektfehler, sondern die gewünschte frühe Erkenntnis.

Die Freigabegrenze bleibt klar. Das Lab darf Datenmodell und Arbeitsweise erproben, aber weder eine finale Grundschutz++-Konformität behaupten noch laufende Grundschutz-Verpflichtungen ersetzen. Seine Ergebnisse sind Hypothesen mit dokumentierter Herkunft. Nach Veröffentlichung der Methodik werden sie gegen den offiziellen Stand geprüft; erst bestätigte Beziehungen werden zur Grundlage einer breiteren Migration.

Nach Ende der Pilotierung und Veröffentlichung der geplanten Methodik folgt ein formales Delta. Es erfasst bestätigte Annahmen, fehlende Datenfelder und Beziehungen, wiederverwendbare Artefakte und neu aufzubauende Elemente. Erst dann wird über Zielarchitektur, Tooling, Schulung und Migrationswellen entschieden.

Damit diese Entscheidung nicht von der Dynamik eines bereits gestarteten Programms überrollt wird, braucht das Lab vorab messbare Abbruch- und Ausbaukriterien. Ein Ausbau ist plausibel, wenn die ausgewählten Beziehungen stabil gepflegt werden, der Export reproduzierbar ist und heutige Audit- oder Steuerungsarbeit erkennbar profitiert. Ein Stopp oder eine Korrektur ist angezeigt, wenn Sonderfelder wachsen, Begriffe nur im Lab funktionieren oder operative Teams parallele Pflege leisten müssen. Das sind keine technischen Nebensächlichkeiten. Sie bestimmen, ob spätere Skalierung Arbeitsaufwand reduziert oder lediglich eine zweite Wahrheitsschicht erzeugt.

Für das Management verschiebt sich dadurch auch die Investitionslogik. Vor Veröffentlichung der Methodik werden Budgets an Lernziele, Reversibilität und heutigen Nutzen gebunden, nicht an behauptete Endkonformität. Nach der formalen Delta-Analyse können Investitionen nach bestätigter Wiederverwendbarkeit priorisiert werden: zuerst tragfähige Datenbeziehungen und Rollen, danach notwendige Prozessänderungen, anschließend Tooling und Schulung. Diese Reihenfolge reduziert das Risiko, organisatorische Unklarheit in Software zu übertragen.

Was das Management jetzt nicht freigeben sollte

Nicht sinnvoll ist ein unternehmensweiter „Big Bang“ auf Basis von Folien und Vorabständen. Ebenso riskant sind voreilige Zertifizierungsversprechen, pauschale Ablösung des aktuellen Kompendiums oder ein Toolkauf ohne überprüfbares Datenmodell.

Freigabefähig sind dagegen begrenzte, reversible Maßnahmen: Datenbereinigung, Rollenklärung, Evidenzmetadaten, strukturierte Ausnahmen, Exporttests und ein definierter Entscheidungszeitpunkt nach Veröffentlichung der Methodik.

Prüfkriterien für die Managementfreigabe

  • Der BSI-Meilensteinplan mit Stand 26.03.2026 und der Pilotstatus zum 02.08.2026 sind dokumentiert.
  • Bestehende Grundschutz- und ISMS-Aktivitäten laufen ohne Governance-Lücke weiter.
  • Zentrale Objekte besitzen stabile Kennungen und benannte Verantwortliche.
  • Anforderungen, Maßnahmen, Evidenz und Entscheidungen sind getrennt, aber verknüpft.
  • Ausnahmen besitzen Ablaufdaten und Review-Auslöser.
  • Relevante Daten lassen sich strukturiert exportieren.
  • Das Readiness-Lab bleibt klein, reversibel und unabhängig nützlich.
  • Nach dem 27.10.2026 ist ein formaler Delta- und Investitionsentscheid vorgesehen.
  • Weder Zertifizierung noch finale Methodik werden vorweggenommen.

Fazit: der A-R-C-Impuls

Grundschutz++ sollte weder ignoriert noch vorzeitig als fertig behandelt werden. Die robuste Position dazwischen heißt Migrationsfähigkeit: bessere Datenbeziehungen, klare Verantwortlichkeiten, prüfbare Evidenz und reversible Experimente.

Der A-R-C-Impuls: Exportieren Sie zehn zentrale Kontrollen mit Objekt, Anforderung, Maßnahme, Verantwortlichem, Evidenz und letzter Entscheidung. Markieren Sie jede Beziehung, die nur im Kopf einer Person existiert. Diese Lücken sind Ihr sinnvollster Vorbereitungsscope. So wird Informationssicherheit steuerbar, prüfbar und managementfähig – heute und für eine spätere Migration.

Abgrenzung

Dieser Beitrag ist eine fachliche Governance-Einordnung auf Basis des BSI-Meilensteinplans mit Stand 26.03.2026, geprüft am 02.08.2026. Er ist keine Rechtsberatung, keine verbindliche BSI-Auslegung und keine Zertifizierungsberatung. Er garantiert weder Migrationskompatibilität noch einen Zertifizierungserfolg. Finale Entscheidungen sollten nach Prüfung der veröffentlichten Methodik und der eigenen Rahmenbedingungen getroffen werden.

Quellen

Über den Autor

Andreas Rühl unterstützt Unternehmen als Interim CISO und ISMS/GRC-Berater. Sein Schwerpunkt liegt darauf, Informationssicherheit steuerbar, prüfbar und managementfähig zu machen.

Passende A-R-C-Leistung: BSI IT-Grundschutz