Grundschutz++ Migration

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

---

Die Einführung von Grundschutz++ im Januar 2026 markiert einen grundlegenden Wandel für Unternehmen und Institutionen, die bislang auf klassischen IT-Grundschutz nach BSI gesetzt haben. Diese Seite beschreibt die wichtigsten Herausforderungen bei der Migration auf das neue, OSCAL/JSON-basierte und prozessorientierte Regelwerk. Im Vordergrund stehen der Abgleich alter und neuer Methodik, die Bewertung des zu erwartenden Umsetzungsaufwands, hilfreiche Strategien zur Vorbereitung und Durchführung sowie konkrete Handlungsempfehlungen für alle relevanten Phasen der Migration – von der Bestandsaufnahme bis zur vollständigen Auditierung. Alle Informationen basieren auf dem aktuellen Entwicklungsstand sowie anerkannten Fachquellen.

Ausgangslage: Aktuelle vs. neue Methodik

• Der klassische IT-Grundschutz basiert auf statischen Bausteinen, festen Katalogen (PDF/Excel), drei Schutzstufen und klaren Zuordnungslisten. Basis sind die BSI-Standards 200-1 bis 200-3, die Methoden und Vorgehen für Geltungsbereich, Strukturanalyse, Schutzbedarfsfeststellung, Modellierung, Grundschutz-Check und Risikoanalyse vorschreiben.
• Grundschutz++ stellt ab 2026 radikal auf ein modulares, prozessorientiertes System mit OSCAL/JSON-Struktur um. Die Anforderungshierarchie wird granularer (Praktiken, Zielobjektkategorien, Teilanforderungen), Redundanzen werden eliminiert, die Pflege dynamisch, Leistungskennzahlen und Prioritäten werden eingeführt. Die Methodik bleibt grundsätzlich erhalten, die Umsetzung jedoch wird teils automatisierbar, verlangt aber tiefgreifend neue Toollandschaften und Umdenkprozesse.

Zielsetzung dies Leitfadens

Dieser Leitfaden unterstützt die Organisationen dabei, bestehende ISMS und vorhandene Sicherheitskonzepte auf Basis des IT-Grundschutzes schrittweise auf die Methodik Grundschutz++ zu übertragen. Er soll den Übergang fachlich einordnen, die wesentlichen methodischen Unterschiede verständlich machen und eine praktikable Orientierung für die Migration von Anforderungen, Strukturen, Rollen und Nachweisen geben.

Ziel ist es, die generelle Migration des ISMS und der vorhandenen Sicherheitskonzepte so zu strukturieren, dass auch unter den derzeit noch unvollständig beschriebenen Rahmenbedingungen eine nachvollziehbare, konsistente und auditierbare Weiterentwicklung möglich bleibt. Der Leitfaden richtet sich damit insbesondere an Personen, die bereits Sicherheitskonzepte nach IT-Grundschutz betreiben und nun eine belastbare Grundlage für die Umstellung auf Grundschutz++ benötigen.

Zweck und Abgrenzung

Der Leitfaden soll keine abschließende Norm oder verbindliche Referenzimplementierung ersetzen. Er versteht sich vielmehr als praktische Arbeitshilfe für die Übergangsphase, in der viele Details der Grundschutz++-Methodik noch nicht vollständig ausgereift oder öffentlich ausreichend spezifiziert sind.

Er soll daher auch dort nutzbar sein, wo methodische Lücken bestehen, indem er bekannte Inhalte aus dem IT-Grundschutz, den veröffentlichten Leitfaden zur Grundschutz++-Methodik und die aktuell vorhandene Dokumentation zu einem handhabbaren Migrationsvorgehen zusammenführt.

Entscheidungshilfe

Ob eine Migration von IT-Grundschutz zu Grundschutz++ sinnvoll ist, hängt vor allem vom Reifegrad des bisherigen ISMS, den bestehenden Nachweispflichten und der strategischen Zielsetzung der Organisation ab. Je stabiler, besser dokumentiert und auditfähig das vorhandene ISMS ist, desto eher kommt eine schrittweise Migration in Betracht; je größer die Unsicherheit über die neue Methodik ist, desto eher ist ein paralleler Neuaufbau als Übergangslösung sinnvoll.

Wenn aktuell eine Zertifizierung besteht oder kurzfristig aufrechterhalten werden muss, sollte eine Migration nur sehr kontrolliert und mit klarer Übergangsstrategie erfolgen. In diesem Fall ist meist ein paralleler Betrieb sinnvoll: Das bestehende Sicherheitskonzept bleibt für Audit- und Nachweiszwecke zunächst erhalten, während Grundschutz++ schrittweise aufgebaut, getestet und auf einzelne Bereiche angewendet wird. So lassen sich Risiken für die Zertifizierung reduzieren und methodische Unsicherheiten abfangen.

Wenn keine laufende Zertifizierung besteht und das ISMS noch nicht sehr weit entwickelt ist, kann ein direkter Aufbau nach Grundschutz++ sinnvoll sein. Das gilt besonders dann, wenn ohnehin eine grundlegende Überarbeitung geplant ist und keine große Menge historischer Dokumentation oder Altsysteme übernommen werden muss. In solchen Fällen ist es oft effizienter, nicht zu migrieren, sondern Grundschutz++ als neues Zielmodell zu nutzen und nur ausgewählte Inhalte aus dem bisherigen IT-Grundschutz zu übernehmen.

Ein weiterer wichtiger Faktor ist die Frage, ob überhaupt auditiert wird. Wo keine externe Auditierung oder Zertifizierung im Raum steht, kann mehr Experimentierfreiheit bestehen, und die Organisation kann Grundschutz++ zunächst als neues Strukturmodell erproben. Wo jedoch Audits, interne Prüfungen oder vertragliche Nachweispflichten bestehen, sollte die Umstellung deutlich vorsichtiger erfolgen und mit klarer Dokumentation, Rückfalloptionen und Übergangsregeln verbunden sein.

Für die Entscheidung lassen sich drei Grundszenarien unterscheiden:

• Weiterbetrieb ohne Migration, wenn das bestehende ISMS stabil, ausreichend wirksam und für die Organisation derzeit ausreichend ist.
• Paralleler Neuaufbau, wenn Grundschutz++ zwar künftig das Zielbild sein soll, das bestehende ISMS aber für Audit, Betrieb oder Zertifizierung noch benötigt wird.
• Schrittweise Migration, wenn das vorhandene ISMS bereits gut strukturiert ist und die Organisation bereit ist, bestehende Inhalte kontrolliert in die neue Methodik zu überführen.

Als Faustregel gilt: Je höher der operative Druck durch Audit, Zertifizierung und laufende Nachweispflichten, desto eher ist ein paralleles Vorgehen sinnvoll. Je höher der Modernisierungsdruck und je niedriger die Bindung an bestehende Strukturen, desto eher ist eine echte Migration oder ein Neuaufbau nach Grundschutz++ die bessere Wahl.

Entscheidungskriterien

Für die praktische Entscheidung sollten mindestens folgende Fragen beantwortet werden:

• Wie reif ist das bestehende ISMS inhaltlich und organisatorisch?
• Gibt es laufende oder bevorstehende Audits?
• Bestehen Zertifizierungen, die erhalten werden müssen?
• Gibt es vertragliche oder regulatorische Nachweispflichten?
• Wie viel historisches Material, Sonderlogik und individuelle Anpassung ist im bisherigen Sicherheitskonzept enthalten?
• Gibt es personelle und zeitliche Ressourcen für eine Doppelpflege?
• Soll Grundschutz++ mittelfristig als Zielmodell oder nur als Testansatz genutzt werden?

Praktische Einordnung

Ein geregeltes Vorgehen ist meist besser als eine sofortige Komplettumstellung. In vielen Fällen ist es sinnvoll, zunächst nur einen abgegrenzten Bereich oder einen priorisierten Geschäftsprozess nach Grundschutz++ aufzubauen und das bestehende IT-Grundschutz-System parallel weiterzuführen. So kann die Organisation Erfahrungen sammeln, ohne die Stabilität des laufenden ISMS zu gefährden.

Die Entscheidung sollte deshalb nicht nur technisch, sondern vor allem organisatorisch und risikoorientiert getroffen werden. Maßgeblich ist nicht, was methodisch elegant erscheint, sondern was für die Organisation unter den gegebenen Rahmenbedingungen realistisch, sicher und nachweisbar umsetzbar ist.

Herausforderungen der Migration

• Strukturbruch: Mengenmäßig und konzeptionell unterscheiden sich Anforderungen und Modellierung deutlich (von Bausteinen/Schichten zu Praktiken und objektbasierten Modulen). Alte Zuordnungen sind meist nur bedingt übertragbar (keine 1:1-Mappings, häufige Umstrukturierungen und agile Zuordnungen erschweren den Umstieg zusätzlich).
• Fehlende Automatisierung: Eine automatische, verlustfreie Migration existiert nicht – jede Fachanforderung/Control muss individuell, meist manuell, neu bewertet und dokumentiert werden (möglicherweise mit Unterstützung durch KI soweit zulässig).
• Datenformate/Tools: Wechsel auf JSON/OSCAL verlangt Anpassungen und Updates sämtlicher genutzter ISMS- und ggf. Risikomanagement-Tools. Übergangsweise fehlen Schnittstellen und Exporte. Alte Tools können meist keine semantischen Übersetzungen liefern.
• Aufwand Abschätzung: Der initiale Migrationsaufwand hängt stark von der Zahl der Zielobjekte, dem Komplexitätsgrad und davon ab, wie „nah am Standard“ das bisherige ISMS geführt wurde. Individuell abweichende Modellierungen, Customizing und Altsysteme verursachen signifikant Mehraufwand.
• Doppelpflege in der Übergangsphase: Während der Transition müssen ggf. zwei Stände synchron gepflegt werden, um sowohl laufende Zertifizierungspflichten als auch neue Grundschutz++-Anforderungen zu erfüllen (Auditierbarkeit, Kontinuität).
• Fehlende Migrationsstrategien/Begleitinformationen: Die neue Struktur und Zergliederung der (Teil-)Anforderungen, inhaltliche Neuerungen und Kontextwechsel (z.B. aus Redundanzen) können bislang weitgehend nur manuell umgesetzt werden.

Wesentliche Änderungen anhand des neuen Vorgehens

Die Methodik von Grundschutz++ folgt einem fünfstufigen, PDCA-basierten Prozess mit Fokus auf Anforderungsmodellierung und, wenn möglich, maschinenlesbarer Verarbeitung. Hier eine Kurzbeschreibung des praktischen Vorgehens:

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

Du legst hier die strategische Basis für Dein ISMS, indem du den Kontext deiner Organisation analysierst, Compliance-Pflichten (z.B. DSGVO, BDSG, brachenspezifische Gesetze und Regelungen) und Erwartungen interessierter Parteien (Kunden, Geschäftspartner, Behörden, Mitarbeitende) feststellst. Anschließend entwickelst du eine Informationssicherheitsleitlinie mit SMART-Zielen und einer Strategie, definierst den Geltungsbereich des ISMS (Scope: welche Prozesse, Standorte, Systeme), klassifizierst den Schutzbedarf kritischer Geschäftsprozesse ("normal" oder "hoch"), richtest Rollen wie den unabhängigen ISB ein und initiierst Risikomanagement sowie Dokumentationspflichten – alles freigegeben von der Leitung.

Unterschied zu BSI-Standard 200-2: Während 200-2 mit Bausteinen und Risikoanalyse startet, integriert Grundschutz++ Governance und Compliance früher und stärker in den PDCA-Planungszyklus, mit Fokus auf maschinenlesbare Strukturen und Organisationsleitungspflicht – weniger asset-zentriert, mehr prozess- und rolleorientiert ab Schritt 1.

Vorgehen in der Migration

1. Kontextanalyse (intern/extern) durchführen
2. Interessierte Parteien identifizieren und Anforderungen erfassen
3. Geltungsbereich (Scope) durch Organisationsleitung 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, aktualisierte Sicherheitsleitlinie, priorisierte Prozesse

Weiterführende Informationen:

• Informationssicherheitsleitlinie
• IS-Strategie
• Geschäftsprozesse

Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung)

Starte mit der Abgrenzung des Informationsverbunds (technische, organisatorische Einheit innerhalb des Geltungsbereichs), erfasse Assets (z.B. Server, Daten, Rollen) pro priorisiertem Geschäftsprozess und ordne sie Zielobjektkategorien zu (z.B. „Anwendung“ mit Vererbung übergeordneter Kategorien). Modelliere dann Anforderungen aus GS++-Praktiken (ISMS-weit plus assetbezogen), ergänze bei Bedarf externe Pflichten oder risikobasierte Anforderungen (nach Risikobetrachtung), prüfe das Sicherheitsniveau ("normal SdT" oder "erhöht") und treffe Gestaltungsentscheidungen (z.B. Parameter wie Zuständigkeiten) – Ergebnis: individuelles Anforderungspaket.

Unterschied zu BSI-Standard 200-2: Statt starrer Baustein-Zuordnung und manueller Risikoanalyse nutzt Grundschutz++ eine modellbasierte, hierarchische Anforderungsableitung via Assets und Zielobjektkategorien (OSCAL-fähig, maschinenlesbar), mit automatisierbarer Vererbung und klarer Trennung von Standard- (SdT) und ergänzenden Anforderungen – skalierbarer und zyklischer als die lineare 200-2-Methodik.

Vorgehen in der Migration

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

Weiterführende Informationen:

• Strukturanalyse
• Das OSCAL-basierte Grundschutz++ Kompendium auf Github.

Schritt 3: Realisierung (DO - Umsetzung)

In diesem Schritt setzt du das Anforderungspaket aus Schritt 2 um, indem du den Ist-Zustand aller Anforderungen bewertest (Umsetzungsstatus ermittelst), fehlende Umsetzungen priorisierst (nach Risiko und Aufwand), einen Umsetzungsplan mit Zuständigkeiten und Fristen erstellst, Ausnahmen dokumentierst und freigibst sowie den Fortschritt verfolgst – inklusive Compliance-Sicherstellung durch regelmäßige Checks.

Unterschied zu BSI-Standard 200-2: Während 200-2 Maßnahmen aus Bausteinen direkt umsetzt und manuell dokumentiert, strukturiert Grundschutz++ die Realisierung zentral über das modellierte Anforderungspaket mit automatisierbarer Priorisierung und Nachverfolgung, stärker in den PDCA-Do-Zyklus eingebettet und skalierbar für große Verbünde.

Vorgehen in der Migration

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

Weiterführende Informationen:

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

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

Hier überprüfst du die Wirksamkeit des ISMS durch Leistungsbewertung (z.B. KPIs), Compliance-Monitoring, Audits (mit Bewertungsschemata und Berichten), Management-Reviews und Validierung der Anforderungen gegen aktuelle Bedrohungen – Tools wie Monitoring-Software unterstützen die kontinuierliche Erfassung.

Unterschied zu BSI-Standard 200-2: Grundschutz++ erweitert die Überwachung (PDCA-Check) um maschinenlesbare Audit-Modelle und Validierung des Anforderungspakets, statt isolierter Baustein-Checks; es integriert dynamische Monitoring-Tools und Managementbewertungen enger, für zyklische Anpassung statt einmaliger Prüfung.

Vorgehen in der Migration

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

Weiterführende Informationen:

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

Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung)

Du behandelst hier deine Erkenntnisse aus Schritt 4, indem du Nicht-Konformitäten analysierst, Verbesserungspotenziale identifizierst, Korrektur- und Verbesserungspläne erstellst, deren Wirksamkeit prüfst und Compliance-Verstöße behebst – so bleibt das ISMS dynamisch und anpassbar an neue Risiken.

Unterschied zu BSI-Standard 200-2: Im Gegensatz zur reaktiven 200-2-Verbesserung (nach Risikoanalyse) schließt Grundschutz++ den PDCA-Act-Zyklus modellbasiert ab, mit systematischer Integration von Audit-Ergebnissen ins Anforderungspaket und automatisierbarer Wirksamkeitsprüfung – prozessorientierter und weniger manuell.

Vorgehen in der Migration

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

Weiterführende Informationen:

Praktische Hinweise

• Tool-gestützt: Vorhandene ISMS-Tools sollten die Migration unterstützen indem sie die Struktur des Informationsverbunds und die Umsetzung der Anforderungen soweit möglich übernehmen, und die Nachzupflegenden Punkte klar kennzeichnen.
• Iteration: Eine Migrations in einem Schritt ist praktisch kaum durchführbar, ein interatives Vorgehen auf jeden Fall sinnvoll. 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)

Der wichtigste Migrationsgedanke ist: Nicht alles aus dem IT-Grundschutz wird ersetzt, sondern die vorhandenen Inhalte werden in eine neue Struktur überführt und methodisch neu sortiert. Besonders kritisch sind die Bereiche Schutzbedarf, Anforderungsmodellierung, Rollenmodell und Dokumentationslogik, weil sich dort die größten methodischen Unterschiede zeigen.

Migrationsstrategie: Phasen und empfohlene Maßnahmen

Frühzeitige Bestandsaufnahme & Konsolidierung

• Welche Dokumente und Artefakte aus dem IT-Grundschutz existieren bereits?
• Welche Bausteine, Schutzbedarfe, Maßnahmen, Risikoanalysen und Nachweise sind vorhanden?
• Welche Geschäftsprozesse, Anwendungen, IT-Systeme, Netze, Räume und externen Dienstleistungen sind schon strukturiert erfasst?
• Wo gibt es Lücken, Inkonsistenzen oder veraltete Annahmen?
• Analyse des aktuellen Umsetzungsstands je Zielobjekt/Asset, möglichst auf Ebene einzelner Teilanforderungen (mit Dokumentation aller MUSS/SOLL/KANN-Nachweise getrennt für jede Instanz).
• Auflösung redundanter und historisch gewachsener Strukturen, klare Gruppierung der Assets/Zielobjekte nach aktuellem Betriebsmodell.

Governance und Organisation

• Anpassung von Rollen, Zuständigkeiten und Freigaben.
• Einordnung der Leitungsebene, des ISB und der führenden Zuständigkeiten.
• Aktualisierung der Informationssicherheitsleitlinie und des Geltungsbereichs gemäß den Anforderungen im GS++.
• Integration von Compliance- und Risikomanagement in die neue Methodik.

Migration der Schutzbedarfslogik

• Überführen der bisherigen Schutzbedarfsfeststellung in die GS++-Informationssicherheitseinstufung.
• Prüfen, ob Schutzbedarfe auf Geschäftsprozesse und Informationen sauber genug beschrieben sind.
• Prüfen, wo bestehende Begründungen für Vertraulichkeit, Integrität und Verfügbarkeit wiederverwendbar sind.
• Klären, wo neue oder feinere Zuordnungen zu Assets und Zielobjektkategorien nötig werden.

Tool- und Prozess-Umstellung

• Kontaktaufnahme und Abgleich mit Herstellern der eingesetzten ISMS-Tools betreffend Grundschutz++-Kompatibilität, geplante Schnittstellen (JSON/OSCAL) und Erprobung der neuen Prozesse.
• Export/Backup alter Datenstrukturen; Aufbau einer Prototyp-Instanz/Entwicklungsumgebung zum Test neuer Modellierungen.
• Parallelpflege der Alt- und Neuansichten während der Übergangszeit und Aufbau von Reports (Synchronisierung der Nachweise für Audits).
• Welche Datenstrukturen, Exporte und Nachweise können übernommen werden?
• Wie wirkt sich der Wechsel zu maschinenlesbaren Anforderungen auf Dokumentation und Pflege aus?
• Welche Systeme für Modellierung, Nachweisführung und Auswertung müssen angepasst werden?
• Wie ist mit Medienbrüchen und manuellen Altbeständen umzugehen?

Mapping und Bewertung der Anforderungen

• Zuordnung der vorhandenen IT-Grundschutz-Bausteine zu GS++-Praktiken (aktuell kaum möglich da keine Mappingtabellen vorhanden sind).
• Nutzung und kritische Analyse ggf. zukünftig angebotenen Migrationshilfen und Tabellen zur Zuordnung bestehender Maßnahmen/Anforderungen zu Grundschutz++ Praktiken (bisher nicht verfügbar).
• Überführung der bisherigen Strukturanalyse in die neue Asset-Sicht unter Beachtung des jeweiligen Bezugs zu dem Geschäftsprozessen.
• Ableitung von Zielobjektkategorien aus bestehenden Bausteinzuordnungen.
• Identifikation von Anforderungen, die schon heute praktisch „verbundweit“ gelten und künftig als übergreifende ISMS-Anforderungen geführt werden können.

• Identifikation fehlender, neuer oder anders formulierter Anforderungen: Welche Maßnahmenpunkte sind entfallen, welche sind neu, welche wurden nur sprachlich restrukturiert? (aktuell kaum möglich da keine Mappingtabellen vorhanden sind).
• Bewertung und Priorisierung der Differenzen: Welche müssen zwingend zu Beginn (Stufe 0 und 1), welche mittelfristig umgesetzt werden?

Migration der Anforderungen

• Überführen der bestehenden Anforderungen in ein GS++-Anforderungspaket.
• Trennen zwischen Anforderungen ohne Zielobjektbezug und solchen, die an Zielobjektkategorien hängen.
• Vermeiden von Dubletten durch Konsolidierung und Vererbung.
• Neuformulierung von Anforderungen in verständlicher Form, soweit die neue Struktur dies ermöglicht.

Pilotierung und schrittweise Migration

• Durchführung einzelner Pilotmigrationen (z.B. für ausgewählte kleine Verbünde oder Bereiche), um Prozesse, Workflows und Tool-Funktionen zu validieren und Lessons Learned zu sammeln.
• Iterative Anpassung der eigenen Umsetzungsstrategie nach ersten Erfahrungswerten, insbesondere hinsichtlich der Auswirkungen auf den Dokumentationsumfang, den Pflegeaufwand und die Auditierbarkeit.
• Schulung und begleitende Kommunikation für das gesamte ISMS-Team/alle Rollen, um Change-Akzeptanz und Know-how sicherzustellen.

Übergangsmodell

• Paralleler Betrieb von IT-Grundschutz und GS++ für einen definierten Zeitraum.
• Priorisierung von Kernbereichen zuerst, statt Big-Bang-Migration.
• Kriterien für die Abschaltung alter Artefakte.
• Erfolgskriterien für den Abschluss der Migration.

Ganzheitliche Umstellung und Abschluss

• Vollständige Überführung aller Zielobjekte und ISMS-Elemente, Migration der Nachweise und historischer Schutzbedarfe sowie Abschluss aller offenen Adaptionspunkte aus den vorherigen Phasen.
• Durchführung eines abschließenden internen Audits nach Grundschutz++, um die vollständige Umsetzung und Auditierbarkeit für Zertifizierungen zu gewährleisten.

Weitere Empfehlungen

• Laufende Information über den Reifegrad und die Verfügbarkeit von Umsetzungsleitfäden, offiziellen Hilfsmitteln und Schnittstellen.
• Engmaschige Projekt-Dokumentation der Umstellung zur Nachvollziehbarkeit für spätere Re-Audits und externe Anfragen.
• Frühzeitig externe Ressourcen mit Migrationserfahrung einbinden, um typische Migrationsfehler und höhere Reibungsverluste zu vermeiden.

Fazit

Die Migration von IT-Grundschutz (Kompendium/Kataloge) zu Grundschutz++ ist ein komplexes Change-Projekt, das ein detailliertes Mapping, intensive Tool-Anpassung sowie hohe Prozessdisziplin voraussetzt. Ein direktes und fehlerfreies Übersetzen der bestehenden Umsetzung ist nicht möglich; viele Nachweispflichten müssen neu bewertet und gepflegt werden. Eine strukturierte, schrittweise und ressourcengestützte Umstellung ist essenziell, um Compliance und Sicherheitsniveau während und nach der Übergangsphase sicherzustellen.