Was die Datei enthält
Die Zuordnungen liegen im Repository der Stand-der-Technik-Bibliothek unter control_layer/Mappings/IT-GS2023-zu-GSpp/ITGS-to-GS++-mapping_collection.json, im OSCAL-Format „mapping-collection“. Am Commit c3f37859 vom 30.10.2026 ist sie die einzige Datei in diesem Ordner. Die folgenden Angaben stammen aus der Datei selbst, die Zahlen aus unserer Auszählung:
| Merkmal | Wert in der Datei | Was es für Sie bedeutet |
|---|---|---|
| Status | draft an beiden Zuordnungsblöcken und in der Herkunftsangabe | Entwurf; keine Zuordnung ist als freigegeben gekennzeichnet |
| Stand | last-modified 21.07.2026, erzeugt laut generated-at am 09.06.2026 | passt zum Katalogstand von April 2026 (Build 20.04.2026); 09.06.2026 ist das Exportdatum. Nicht passend zum Build vom 29.10.2026, gegen den Sie heute arbeiten |
| Verfahren | method: human, matching-rationale: semantic, erzeugt mit dem Werkzeug „gsmap“ | inhaltliche Zuordnung durch Menschen; begründet wird keine einzelne Zuordnung, ein Bemerkungsfeld ist in keiner gefüllt |
| Weitere Kennzeichen | mode: draft, only_done: false | Die Datei erklärt die Kennzeichen nicht. Dem Namen nach sind auch noch nicht abgeschlossene Prüfentscheidungen enthalten. |
| Zuordnungsblöcke | 1.013 Zuordnungen auf den Kernel-Katalog, 172 auf den Methodik-Katalog | zusammen 1.185; im Anwenderkatalog sind beide Teile zusammengeführt |
| Quelle | 824 verschiedene Teilanforderungen mit dem Zusatz -UA.n, etwa NET.1.1.A2-UA.2, aus 510 Anforderungen der Edition 2023 | Der Wortlaut der Teilanforderungen steht nicht in der Datei; die referenzierte Quelldatei itgs-source-catalog.json liegt nicht im Ordner. Welcher Satz einer alten Anforderung gemeint ist, lässt sich deshalb nicht ablesen. |
| Ziel | 339 verschiedene Kennungen, jeweils mit der UUID der Zielanforderung | Die UUID ist der verlässlichere Schlüssel (siehe Abgleich) |
| Gefährdungen | an jeder Zuordnung elementare Gefährdungen, insgesamt 3.647 Angaben; an 207 Zuordnungen zusätzlich Schutzziele (C, I, A) | hilfreich, um eine Zuordnung über die Gefährdung zu plausibilisieren |
Die fünf Beziehungsarten richtig lesen
Jede Zuordnung verbindet genau eine alte Teilanforderung (Quelle) mit genau einer neuen Anforderung (Ziel) und nennt eine Beziehung. Die Datei erläutert die Werte nicht. Wir lesen sie wörtlich, von der Quelle zum Ziel; diese Lesart liegt den Beispielen unten zugrunde.
| Beziehung | Anzahl | Unsere Lesart | Was Sie prüfen |
|---|---|---|---|
equal-to | 21 | alte und neue Anforderung sind inhaltlich gleich | Modalverb, Sicherheitsniveau und Parameter trotzdem vergleichen |
equivalent-to | 118 | gleichwertig, bei abweichender Formulierung | ob der Prüfgegenstand derselbe ist oder nur das Thema |
subset-of | 464 | die alte Teilanforderung ist ein Teil der neuen | was die neue zusätzlich verlangt; die alte Maßnahme reicht allein nicht |
superset-of | 187 | die alte verlangt mehr als die neue | ob der Rest der alten Anforderung woanders zugeordnet ist oder entfällt |
intersects-with | 395 | beide überschneiden sich teilweise | beide Richtungen; 156 dieser Zuordnungen haben das Merkmal relationship_defaulted: true, die Beziehung wurde dem Namen nach voreingestellt und nicht entschieden |
Für die Arbeit heißt das: Nur ein Bruchteil der Zuordnungen behauptet Gleichheit. Bei den übrigen ist der Normalfall, dass eine alte Maßnahme eine neue Anforderung teilweise abdeckt. Den Umsetzungsstatus nach Grundschutz++ müssen Sie in jedem Fall neu ermitteln; ein alter Status „ja“ ist kein „erfüllt“.
Abgleich mit dem Katalog-Build: Kennung oder UUID
Die Zuordnungen passen vollständig zum Katalogstand von März und April 2026: Gegen die Builds vom 05.03. bis 20.04.2026, zuletzt Build 20.04.2026 (Commit 333c147), zeigen bei allen 1.185 Zuordnungen Kennung und UUID auf dieselbe Anforderung. Exportiert wurde die Datei laut Metadaten am 09.06.2026. Ab dem Build vom 28.05.2026 hat das BSI Kennungen im Katalog in fünf Stufen umgehängt, zuletzt mit dem Build vom 26.07.2026; die UUIDs der Anforderungen blieben dabei gleich. Wer die Zuordnungen über die Kennung mit dem aktuellen Anwenderkatalog verknüpft, landet in 90 Fällen bei der falschen Anforderung. Die Zuordnungen nennen zur Kennung aber auch die UUID der Zielanforderung, und dieselbe UUID steht im Anwenderkatalog als alt-identifier an der Anforderung. Unser Abgleich mit dem Build vom 29.10.2026:
| Ergebnis | Zuordnungen | Beispiel |
|---|---|---|
| Kennung und UUID zeigen auf dieselbe Anforderung | 1.039 | NET.1.1.A2-UA.2 → ARCH.2.5 „Netzplan“ |
| Kennung existiert, UUID gehört zu einer anderen Anforderung | 90 (30 Kennungen) | Ziel TEST.3.1.10 ist im Build „Lasttest“; die UUID gehört zu TEST.3.1.11 „Penetrationstest bei Änderungen“ |
| Kennung fehlt im Build, UUID lässt sich auflösen | 40 (16 Kennungen) | GC.8.1.1.1 gibt es nicht mehr; die UUID gehört zu GC.9.1.1.1 „Informationssicherheitsbeauftragter“ |
| weder Kennung noch UUID im Build | 16 | alle 16 zeigen auf VRB.1.2; im Build gibt es in VRB.1 nur VRB.1.1 |
In den Fällen mit verschobener Kennung, die wir uns angesehen haben, passt die über die UUID gefundene Anforderung inhaltlich zur alten Anforderung, die über die Kennung gefundene nicht. Unsere Empfehlung: Verknüpfen Sie über die UUID und behandeln Sie die 16 nicht auflösbaren Zuordnungen als offen. Schon im Build vom 28.05.2026 passten 35 Zuordnungen nicht mehr; seit dem Build vom 26.07.2026 ist der Stand unverändert (eigener Abgleich mit allen Builds dieses Zeitraums).
Arbeitsergebnis: sieben Zuordnungen durchgearbeitet
Die Zuordnungen stehen so in der Datei; Anforderungen der Edition 2023 geben wir mit Titel und in eigenen Worten wieder, Grundschutz++-Anforderungen im Wortlaut des Builds vom 29.10.2026, Parameter in eckigen Klammern. Die Spalte „Prüfung“ gibt unsere fachliche Einschätzung wieder; das BSI hat sie nicht bestätigt.
| Nr. | Zuordnung laut Datei | Ziel im Build 29.10.2026 | Prüfung | Ergebnis |
|---|---|---|---|---|
| 1 | NET.1.1.A2-UA.2 „Dokumentation des Netzes“ (Basis) equal-to ARCH.2.5 | ARCH.2.5 „Netzplan“, normal-SdT: „Architektur für Netze SOLLTE einen Netzplan dokumentieren.“ Kennung und UUID stimmen überein. | Inhaltlich gleich für den Teil Netzplan. Die alte Anforderung war eine Basis-Anforderung mit MUSS, die neue ist eine SOLLTE-Anforderung; eine Nichterfüllung lässt sich jetzt als temporär oder dauerhaft einordnen. Die übrigen Teile von NET.1.1.A2 verteilt die Datei auf ARCH.1.1, ARCH.1.1.1, ARCH.2.4 „Inventar der Netze“ und das nicht auflösbare VRB.1.2. | übernehmen; Netzplan als Nachweis der Maßnahme zuordnen, Status neu ermitteln |
| 2 | ISMS.1.A4-UA.1 „Benennung eines oder einer Informationssicherheitsbeauftragten“ (Basis) equal-to GC.8.1.1.1 | Kennung fehlt; über die UUID GC.9.1.1.1 „Informationssicherheitsbeauftragter“, normal-SdT: „Governance und Compliance MUSS die Zuständigkeit für Informationssicherheit [einer unabhängigen Person], welche unmittelbar der Institutionsleitung unterstellt ist, zuweisen.“ | Der Kern passt. Die neue Anforderung verlangt eine Unterstellung unter die Institutionsleitung und enthält einen Parameter zur Unabhängigkeit; die alte nennt Benennung, Ressourcen, ein Vortragsrecht bei Bedarf und frühe Beteiligung. Ob „gleich“ zutrifft, hängt davon ab, welchen Teil der alten Anforderung UA.1 meint. | übernehmen mit Auflage: Organigramm gegen die Unterstellung prüfen, Parameter festlegen |
| 3 | DER.3.2.A19-UA.1 „Überprüfung der gewählten Risikobehandlungsoptionen“ (Standard) equal-to UMS.2.1 | UMS.2.1 ist im Build „Umsetzungsplanung“; die UUID gehört zu UMS.1.2 „Bewertung des Restrisikos“, normal-SdT: „Umsetzung SOLLTE das bestehende Restrisiko durch die nicht umgesetzten Anforderungen festlegen.“ | Über die Kennung gelesen passt die Zuordnung nicht. Über die UUID passt das Thema: Die alte Anforderung lässt das Revisionsteam prüfen, ob die Restrisiken angemessen sind und die Leitung sie verbindlich übernommen hat; die neue lässt die Umsetzung das Restrisiko festlegen. Prüfender und Prüfgegenstand unterscheiden sich; wir werten das als Überschneidung. | korrigieren: auf UMS.1.2 verknüpfen, als Überschneidung behandeln; den Prüfaspekt ordnen wir dem internen Audit nach 300-1, Kap. 5.2, zu |
| 4 | OPS.1.1.1.A23-UA.1 „Durchführung von Penetrationstests“ (erhöhter Schutzbedarf) equivalent-to TEST.3.1.10 und equivalent-to DET.5.4 | TEST.3.1.10 ist im Build „Lasttest“; die UUID gehört zu TEST.3.1.11 „Penetrationstest bei Änderungen“, erhöht: „Änderungen und Tests KANN bekannte Schwachstellen bei kritischen Änderungen testen.“ DET.5.4 „Regelmäßige Penetrationstests“, erhöht: „Detektion für IT-Systeme KANN die tatsächliche Abwehrfähigkeit nach [einer anerkannten Vorgehensweise] [regelmäßig] überprüfen.“ | DET.5.4 passt als gleichwertig. TEST.3.1.11 erfasst nur Tests bei kritischen Änderungen; die alte Anforderung verlangt Penetrationstests für alle IT-Komponenten nach einem Konzept mit Methoden, Testtiefe und Erfolgskriterien. Wir lesen das als superset-of. Beide neuen Anforderungen sind KANN-Anforderungen. | DET.5.4 übernehmen; TEST.3.1.11 über die UUID verknüpfen und die Beziehung als Obermenge führen; das Testkonzept als Maßnahme behalten |
| 5 | NET.3.4.A9-UA.2 „Festlegung eines angepassten NAC-Regelwerkes“ (Standard) auf elf Ziele: ARCH.2.2, ARCH.2.2.1, ARCH.2.2.3, ARCH.5.1, ARCH.5.1.12 (subset-of), ARCH.2.2.2, ARCH.2.2.8, ARCH.2.2.9, ARCH.2.2.10 (intersects-with), ARCH.2.3 (equivalent-to), ARCH.4.1 (superset-of); dazu UA.3 und UA.4 auf ARCH.4.1.1 | alle elf Kennungen und UUIDs stimmen überein; ARCH.2.3 „Mikrosegmentierung“, erhöht: „Architektur für IT-Systeme KANN Verbindungen zu allen anderen IT-Systemen einschränken.“ ARCH.4.1.1 „Dynamische Netzzugangskontrolle“, SOLLTE | Ein Regelwerk für die Netzzugangskontrolle legt fest, welche Endgeräte welche Segmente erreichen. Das berührt die Segmentierungsanforderungen, ist aber keine Mikrosegmentierung aller IT-Systeme; equivalent-to für ARCH.2.3 halten wir für zu weit, eine Überschneidung trifft es besser. Die übrigen Beziehungen sind nachvollziehbar. | übernehmen mit Auflage: das NAC-Regelwerk als eine Maßnahme anlegen und allen passenden Zielen zuordnen, wie 300-1 es für Maßnahmen mit mehreren Anforderungen verlangt (Kap. 4.3); Status je Ziel getrennt ermitteln |
| 6 | ORP.2.A2 „Geregelte Verfahrensweise beim Weggang von Mitarbeitenden“ (Basis): UA.1 auf PERS.6.1.2, UA.4 auf BER.2.5 und PERS.6.1.1, UA.10 auf PERS.6.1, alle intersects-with mit relationship_defaulted | PERS.6.1 „Vorgehensweise für den Weggang“, PERS.6.1.1 „Entzug von Berechtigungen gemäß BER“, PERS.6.1.2 „Neubesetzung“, BER.2.5 „Deaktivierung bei Weggang“, alle SOLLTE; Kennungen und UUIDs stimmen überein | Die Ziele decken Vorgehensweise, Entzug der Rechte, Deaktivierung der Identität und Neuverteilung der Zuständigkeiten ab. Rückgabe von Unterlagen, Schlüsseln, Geräten und Ausweisen und die Erinnerung an Betriebs- und Geschäftsgeheimnisse stehen nicht im Anforderungstext, aber in der Erläuterung zu PERS.6.1. Für die Rückgabe kommt zusätzlich SENS.8.9 „Rückgabe nicht mehr benötigter Assets“ in Betracht, das die Datei nicht mit ORP.2.A2 verknüpft. Die Einweisung der Nachfolge deckt PERS.6.1.2 nur zum Teil ab; Interessenkonflikte, Konkurrenzverbote und Karenzzeiten haben in der Datei kein Ziel. | Beziehungen bestätigen; Rückgabe und Hinweis auf Verschwiegenheit als Teil der Maßnahme zu PERS.6.1 nachweisen, etwa mit der Austrittscheckliste; SENS.8.9 ergänzend prüfen; für Interessenkonflikte und Konkurrenzverbote selbst ein Ziel suchen oder als eigene Anforderung führen |
| 7 | 16 Zuordnungen auf VRB.1.2, etwa ISMS.1.A12-UA.6 „Management-Berichte zur Informationssicherheit“, OPS.1.1.3.A1-UA.3 „Konzept für das Patch- und Änderungsmanagement“ und NET.1.1.A2-UA.4, fast alle subset-of | weder Kennung noch UUID im Build; in VRB.1 steht nur VRB.1.1 „Verfahren zur kontinuierlichen Verbesserung“ | Im Build vom 28.05.2026 hieß VRB.1.2 „Änderungen im ISMS“ (MUSS: „Verbesserung MUSS ein Verfahren zum Umgang mit Änderungen im ISMS verankern.“). Mit dem Build vom 24.06.2026 ist sie entfallen, und im Build vom 29.10.2026 hat keine andere Anforderung ihre UUID; welche Anforderung an ihre Stelle getreten ist, lässt sich nicht ablesen. | neu zuordnen: je alte Anforderung ein eigenes Ziel suchen und begründen; beim nächsten Stand des Mappings erneut prüfen |
Die sieben Fälle zeigen die drei Fehlerarten, auf die Sie bei der Übertragung achten sollten: verschobene oder entfallene Kennungen (Fälle 2, 3 und 4 verschoben, Fall 7 entfallen), Beziehungen, die enger oder weiter sind, als die Datei angibt (Fälle 3, 4 und 5), und Teile der alten Anforderung, die kein auflösbares Ziel haben (Fall 1) oder nur in der Erläuterung eines Ziels auftauchen (Fall 6).
So prüfen Sie Ihre eigenen Zuordnungen
- Stand festhalten. Notieren Sie Commit und Datum der Zuordnungsdatei und den Build des Anwenderkatalogs. Beide ändern sich unabhängig voneinander.
- Über die UUID auflösen. Verknüpfen Sie
oscal_uuidder Zuordnung mitalt-identifierim Katalog. Kennungen nur zur Anzeige verwenden. - Je alte Anforderung alle Ziele sammeln. Eine Anforderung der Edition 2023 kann in der Datei mehrere Teilanforderungen haben, und 224 Teilanforderungen haben mehr als ein Ziel; bei 39 alten Anforderungen sind es fünf oder mehr verschiedene Ziele.
- Je Ziel inhaltlich prüfen: Prüfgegenstand, Modalverb, Sicherheitsniveau (normal-SdT oder erhöht), Parameter, Zielobjektkategorie und zuständige Rolle. Voreingestellte Beziehungen (
relationship_defaulted) besonders ansehen. - Lücken suchen. Lesen Sie die alte Anforderung Satz für Satz und prüfen Sie, ob jeder Teil ein Ziel hat. Anforderungen der Edition 2023 ohne Eintrag in der Datei ordnen Sie selbst zu.
- Ergebnis dokumentieren. Je Zuordnung eines von vier Ergebnissen: übernehmen, übernehmen mit Auflage, korrigieren, neu zuordnen; mit Begründung und Bearbeiter. Danach ermitteln Sie den Status nach 300-1 neu.
Als Prüfprotokoll reicht eine Tabelle mit den Spalten der Beispieltabelle oben, ergänzt um die UUID, das Datum der Prüfung und die prüfende Person. Wer die Zuordnungen in ein ISMS-Werkzeug importiert, sollte diese Spalten mit übernehmen, damit die Prüfung bei einem neuen Stand der Datei wiederholt werden kann.
Was das Mapping nicht leistet
- Kein Status. Die Datei sagt, welche neue Anforderung thematisch passt, nicht, ob Sie sie erfüllen. Ein „teilweise“ aus dem alten IT-Grundschutz-Check gibt es nach 300-1 nicht mehr; wie Sie alte Ergebnisse überführen, steht auf der Seite IT-Grundschutz-Check.
- Keine Modellierung. Bausteine wurden Zielobjekten zugeordnet, Anforderungen von Grundschutz++ hängen an Zielobjektkategorien. Wie Sie Assets den Kategorien zuordnen, zeigt die Seite Modellierung.
- Kein freigegebener Stand. Solange der Status „draft“ lautet, ist jede Zuordnung ein Vorschlag. Halten Sie Ihre Prüfergebnisse so fest, dass Sie sie bei einer neuen Fassung der Datei vergleichen können.
- Kein ISO-Mapping. Für ISO/IEC 27001 Annex A liegt im Repository eine eigene Zuordnungsdatei; welche Dateien es gibt, steht auf der Seite Anwenderkatalog Grundschutz++.
Wie die Prüfung der Zuordnungen in eine geordnete Überführung passt, beschreibt die Seite Migration; die methodischen Unterschiede zwischen beiden Welten der Vergleich IT-Grundschutz 2023 und Grundschutz++. Wenn Sie Ihre Zuordnungen für ein bestehendes ISMS prüfen lassen wollen, unterstützt Sie Blackfort Technology im Rahmen der Bestandsbewertung, siehe Beratung.
Rechtehinweis: Anforderungstitel aus dem IT-Grundschutz-Kompendium, Edition 2023, © 2023 Reguvis Fachmedien GmbH und © 2023 Bundesamt für Sicherheit in der Informationstechnik, Quelle: BSI-Seite zum IT-Grundschutz-Kompendium. Diese Titel stehen nicht unter CC BY-SA 4.0; der Lizenzhinweis am Seitenende gilt für die Auszüge aus Katalog- und Zuordnungsdaten.