Was der Anwenderkatalog Grundschutz++ enthält
Der Anwenderkatalog Grundschutz++ ist Teil der Stand-der-Technik-Bibliothek, die das BSI auf GitHub veröffentlicht. Das BSI schreibt dazu auf seiner Grundschutz++-Seite: „Sie löst das IT-Grundschutz-Kompendium ab.“ Der Katalog enthält die technischen und organisatorischen Anforderungen und zusätzlich die normativen Inhalte der Methodik, die das BSI aus dem BSI-Standard 300-1 in eigene Anforderungen überführt hat (300-1, Kap. 3.4.1). Wer nach 300-1 arbeitet, hat damit zwei Texte vor sich: den Standard, der das Vorgehen beschreibt, und den Katalog, aus dem das eigene Anforderungspaket entsteht.
Die Anforderungen liegen als JSON im OSCAL-Format vor. So lassen sich die Anforderungen direkt in Werkzeuge laden und dort auswerten; das BSI nennt die automatisierbare Prüfung als Zweck des Formats. Für Bereiche mit normalem Schutzbedarf liegt dem Katalog eine allgemeine Risikobetrachtung des BSI zugrunde. Bei normalem Schutzbedarf ist deshalb grundsätzlich keine eigene Risikobetrachtung nötig, mit drei Ausnahmen nach Kap. 2.11 von 300-1: wenn ein Geschäftsprozess bei mindestens einem Schutzziel hohen Schutzbedarf hat, wenn ein relevantes Asset durch die Zielobjektkategorien und ihre Anforderungen nicht hinreichend abgedeckt ist und wenn eine anwendbare SOLLTE-Anforderung dauerhaft nicht erfüllt wird. Für SOLLTE-Anforderungen, die eingeplant, aber noch nicht erfüllt sind, verlangt Kap. 2.11 außerdem eine Restrisikobetrachtung mit Freigabe durch die Institutionsleitung.
Laut BSI beschreibt der Anwenderkatalog „nur noch Anforderungen, die nicht auf spezifische IT-Lösungen abzielen“. Produktnahe Umsetzungsbeschreibungen liegen getrennt im Implementation Layer der Bibliothek. Diese Komponentendefinitionen beschreiben eine mögliche Umsetzung; das Repository betont, dass sie keine tatsächliche Implementierung sind und das Handeln der verantwortlichen Stelle nicht ersetzen.
Datei-Wegweiser: welche Datei wofür
Die Bibliothek enthält mehr als den Anwenderkatalog. Für ein Anforderungspaket nehmen Sie die aufgelöste Datei. Das README des Repositorys beschreibt aufgelöste Kataloge als direkt in einer Institution verwendbar; Quellkataloge und Profile unter sources/ richten sich an Editoren. Die Tabelle gibt den Stand von Commit c3f37859 vom 30.10.2026 wieder.
| Datei (Pfad im Repository) | Inhalt | Wofür Sie sie brauchen | Hinweis |
|---|---|---|---|
control_layer/Grundschutz++/Grundschutz++-resolved_catalog.json | Aufgelöster Anwenderkatalog Grundschutz++, 1.000 Anforderungen in 20 Praktiken, Build 2026-10-29 | Anforderungspaket bilden, Daten in ein ISMS-Werkzeug übernehmen | Die einzige Datei, die Methodik-, Risikomanagement- und technisch-organisatorische Anforderungen zusammen enthält |
control_layer/Grundschutz++/sources/profiles/Grundschutz++-profile.json | Profil, das festlegt, was in den aufgelösten Katalog kommt | Nachvollziehen, warum eine Anforderung enthalten ist oder fehlt | Übernimmt den Methodik-Katalog und den Kernel vollständig, aus dem Risikomanagement-Katalog nur RISK.1.1, RISK.1.3, RISK.1.5 und RISK.1.10; setzt den Parameter von GC.1.1 auf „BSI Grundschutz++“ und einen Parameter von NOT.1.1.4 auf „BSI-Standard 200-4“ |
control_layer/Grundschutz++/sources/catalogs/Methodik-Grundschutz++/BSI-Methodik-Grundschutz++-catalog.json | 95 Methodik-Anforderungen in GC, STM, UMS, VRB und PERF | Methodik-Anforderungen getrennt lesen | Quellkatalog; ergibt allein kein Anforderungspaket |
control_layer/Kernel/BSI-Stand-der-Technik-Kernel-catalog.json | Quellkatalog der technischen und organisatorischen Anforderungen | Abgleiche, Arbeit als Editor | Im aufgelösten Katalog stammen 901 Anforderungen aus dem Kernel |
control_layer/Risikomanagement/BSI-Anforderungen-zum-Risikomanagement-catalog.json | 10 Anforderungen RISK.1.1 bis RISK.1.10, Stand 22.10.2026 | Risikoverfahren abgleichen | Nur vier davon stehen im Anwenderkatalog, Einzelheiten auf Risiko-Mindestkriterien |
control_layer/Mappings/IT-GS2023-zu-GSpp/ITGS-to-GS++-mapping_collection.json | 1.185 Zuordnungen von IT-Grundschutz 2023 zu Grundschutz++, last-modified 21.07.2026, laut Metadaten exportiert am 09.06.2026 (generated-at) | Altbestand übertragen | Status „draft“, also Entwurf. Die Zielkennungen passen vollständig (1.185 von 1.185) zu den Katalogständen vom 05.03. bis 20.04.2026, zuletzt Commit 333c147 vom 20.04.2026 (eigene Auflösung gegen alle 23 Katalogstände im Repository). In fünf Stufen, mit den Builds vom 28.05., 24.06., 03.07., 16.07. und 26.07.2026, hat das BSI danach Kennungen umgehängt; die UUIDs blieben gleich. Schon gegen den Build vom 28.05.2026 stimmen nur noch 1.150 der 1.185 Zuordnungen, 35 nicht. Das Datum 09.06.2026 ist nur das Exportdatum der Mappingdatei. Gegen den Build vom 29.10.2026 passen 1.039 der 1.185 Zuordnungen direkt über die Kennung; bei 90 zeigt die Kennung inzwischen auf eine andere Anforderung, 40 Kennungen gibt es nicht mehr (die Anforderung ist nur noch über die UUID auffindbar), und 16 Ziele (VRB.1.2) fehlen im Build ganz (eigene Auszählung). Verknüpfen Sie deshalb über die UUID (oscal_uuid im Mapping, alt-identifier im Katalog) und prüfen Sie jede Zuordnung fachlich |
control_layer/Mappings/ISO-27001-zu-GSpp/ISO27001-AnnexA-to-GS++-mapping_collection.json | Zuordnung ISO/IEC 27001 Annex A zu Grundschutz++ | ISO-Bestand abgleichen | Laut Dateiname nur Annex A |
control_layer/WLAN/, control_layer/Lieferkettensicherheit/ | Weitere aufgelöste Kataloge mit eigenem Profil | Themen mit eigener Anforderungsauswahl | Ob es sich um Blaupausen im Sinne von 300-1 Kap. 3.3 handelt, erklärt das Repository nicht ausdrücklich |
control_layer/Mindeststandard-TLS/Entwurf-Mindeststandard-TLS-catalog.json | Entwurf eines Mindeststandards | Nicht für das Anforderungspaket | Der Dateiname kennzeichnet den Entwurf |
documentation/namespaces/ | Vokabulare: Praktiken, Zielobjektkategorien, Modalverben, Sicherheitsniveaus, Aufwandsstufen, Gefährdungen | Felder im Katalog richtig lesen | CSV-Dateien in UTF-8 mit Kopfzeile |
implementation_layer/ | Komponentendefinitionen, u. a. Passwortrichtlinie, Netzarchitektur, Keycloak | Ideen für die Umsetzung | Beschreiben eine Umsetzung, sind selbst keine |
assessment_layer/ | Vorgesehen für Prüfpläne, Prüfergebnisse und Maßnahmenpläne | Derzeit nichts | Laut README noch keine Artefakte veröffentlicht |
Wie eine Anforderung im Katalog aufgebaut ist
Jede Anforderung folgt einer Satzschablone aus Praktik, Modalverb, Ergebnis und Handlungswort. Ein Beispiel ist UMS.1.1 „Ermittlung des Umsetzungsstatus“. Im Katalog steht: „Umsetzung MUSS den Umsetzungsstatus der Anforderungen im Anforderungspaket vollständig {{ insert: param, ums.1.1-prm1 }} überprüfen.“ Der Platzhalter ist ein Parameter mit der Bezeichnung „regelmäßig“; einen festen Wert setzt der Katalog hier nicht. Gelesen heißt der Satz also: Der Umsetzungsstatus wird vollständig und regelmäßig überprüft. Was „regelmäßig“ für Sie bedeutet, legen Sie beim Erstellen des Anforderungspakets fest (300-1, Kap. 3.5).
Die wichtigsten Felder, die Sie beim Import oder beim Lesen der Datei antreffen:
| Feld im Katalog | Bedeutung | Werte im Build 2026-10-29 |
|---|---|---|
id, title | Kennung und Titel der Anforderung, z. B. UMS.1.1 | 1.000 Kennungen, verschachtelt bis zur vierten Ebene |
modal_verb | Verbindlichkeit: MUSS, SOLLTE oder KANN | 149 MUSS, 627 SOLLTE, 224 KANN |
sec_level | Sicherheitsniveau: „normal-SdT“ (Standard-Sicherheitsstufe) oder „erhöht“ | 773 normal-SdT, 227 erhöht |
target_object_categories | Zielobjektkategorie, an der die Anforderung hängt | 636 Anforderungen mit, 364 ohne Zielobjektkategorie |
params | Parameter wie „regelmäßig“, von der Institution zu konkretisieren | je Anforderung null bis mehrere |
effort_level | Aufwandsstufe 0 bis 5; 0 heißt laut Namespace: Der Aufwand „wird nicht bewertet, da ihre Implementierung in jedem Fall zwingend erforderlich ist“, 1 steht für Quick Wins, 5 für aufwändige, komplexe Maßnahmen | 0: 148, 1: 52, 2: 171, 3: 281, 4: 159, 5: 189 |
threats | Zugeordnete elementare Gefährdungen (G 0.1 bis G 0.47) | 901 Anforderungen mit Gefährdungszuordnung |
confidentiality, integrity, availability, authenticity | Wirkung der Anforderung auf das jeweilige Schutzziel, Stufen 0 bis 2 | bei 901 bzw. 900 Anforderungen gesetzt |
guidance | Erläuterungstext zur Anforderung | Fließtext, teils mit Beispielen |
documentation | Empfohlene Art der Dokumentation, z. B. „ISMS-Regelwerk“ | bei 961 Anforderungen gesetzt |
Der Katalog in Zahlen: 20 Praktiken, Build 2026-10-29
Wir haben den aufgelösten Katalog rekursiv über alle Ebenen gezählt: 652 Anforderungen auf der ersten, 327 auf der zweiten, 19 auf der dritten und 2 auf der vierten Ebene, zusammen 1.000. Wer nur zwei Ebenen zählt, kommt auf 979. Nach Herkunft stammen 95 Anforderungen aus dem Methodik-Katalog, 4 aus dem Risikomanagement-Katalog und 901 aus dem Kernel. Der Schwerpunkt jeder Praktik stammt aus der Namespace-Datei practices.csv.
| Kürzel | Praktik | Schwerpunkt | Anforderungen |
|---|---|---|---|
| GC | Governance und Compliance | Methodik | 35 |
| STM | Strukturmodellierung | Methodik | 15 |
| UMS | Umsetzung | Methodik | 11 |
| VRB | Verbesserung | Methodik | 10 |
| PERF | Monitoring-Evaluation | Methodik | 24 |
| RISK | Risikomanagement | Methodik | 4 |
| ASST | Informationen und Assets | Organisatorisch | 58 |
| PERS | Personal | Organisatorisch | 30 |
| BES | Beschaffungsmanagement | Organisatorisch | 109 |
| DLS | Dienstleistersteuerung | Organisatorisch | 18 |
| TEST | Änderungen und Tests | Organisatorisch | 36 |
| GEB | Gebäudemanagement | Organisatorisch | 75 |
| SENS | Sensibilisierung | Organisatorisch | 87 |
| NOT | Notfallplanung | Organisatorisch | 37 |
| ARCH | Architektur | Technisch | 63 |
| BER | Berechtigung | Technisch | 92 |
| DET | Detektion | Technisch | 82 |
| REA | Sicherheitsvorfallsbehandlung | Technisch | 23 |
| KONF | Konfiguration | Technisch | 157 |
| DEV | Entwicklung | Technisch | 34 |
Die Methodik-Anforderungen sind fast alle MUSS-Anforderungen (76 MUSS, 19 SOLLTE, dazu die vier RISK-Anforderungen mit MUSS). Im Kernel überwiegt SOLLTE mit 608 Anforderungen, dazu 224 KANN und 69 MUSS. Alle 224 KANN-Anforderungen haben das Sicherheitsniveau „erhöht“.
Prüfliste: arbeiten Sie mit dem richtigen Katalogstand?
Das BSI veröffentlicht den Katalog fortlaufend neu. Eine Zahl oder ein Anforderungstext ohne Build-Datum lässt sich später nicht mehr nachprüfen. Diese Punkte prüfen wir, bevor wir mit einer Katalogdatei arbeiten:
| Prüfpunkt | Was Sie prüfen | Wert im hier verwendeten Stand |
|---|---|---|
| 1. Richtige Datei | Pfad endet auf Grundschutz++-resolved_catalog.json, im Feld metadata.title steht „Anwenderkatalog Grundschutz++“ | erfüllt |
| 2. Build-Datum | metadata.last-modified und metadata.version notieren; der Katalog hat als Version einen Zeitstempel, keine fortlaufende Nummer | 2026-10-29T08:03 |
| 3. Commit | Commit-Hash des Repositorys zu jedem Export und jeder Zählung festhalten | c3f37859, 30.10.2026 |
| 4. Zählprobe | Rekursiv über alle controls-Ebenen zählen; weicht Ihre Zahl ab, liegt es an der Zählweise oder an der Datei | 1.000 |
| 5. Vollständigkeit im Werkzeug | Sind die 95 Methodik-Anforderungen und die vier RISK-Anforderungen enthalten? Ein Import nur des Kernels lässt die Methodik weg | 95 + 4 + 901 |
| 6. Bezeichnungen der Zielobjektkategorien | Der Katalog verwendet teils kürzere Namen als Anhang 1 von 300-1, etwa „Archiv“ statt „Datenträgerarchiv“ oder „Faxanwendungen“ statt „Fax(-anwendungen)“ | 39 Kategorien |
| 7. Mapping-Stand | Mappings haben ein eigenes Datum und einen eigenen Status; getrennt notieren und die Ziele über die UUID gegen den verwendeten Build abgleichen, weil das Mapping zu den Katalogständen vom 05.03. bis 20.04.2026 passt und das BSI Kennungen ab dem Build vom 28.05.2026 umgehängt hat | 21.07.2026, Entwurf; 146 von 1.185 Zielkennungen passen nicht mehr zum Build 2026-10-29 |
| 8. Bekannte Abweichungen zum Standard | Stellen, an denen Katalogtext und 300-1 auseinanderliegen, im Anforderungspaket vermerken (nächster Abschnitt) | drei Punkte |
| 9. Lizenz | Die Bibliothek steht unter CC BY-SA 4.0; Herkunft und eigene Änderungen kennzeichnen. Was das für Ihr Werkzeug bedeutet, gehört zur Prüfung durch Ihre Rechtsabteilung | CC BY-SA 4.0 |
| 10. Neuer Build | 300-1 nennt Anpassungen an den Anforderungen der Bibliothek ausdrücklich als Anlass für die Validierung des Anforderungspakets (Kap. 5.5) | Abgleich einplanen |
Wo Katalog und Standard noch auseinanderliegen
Der Build vom 29.10.2026 ist an drei Stellen nicht deckungsgleich mit dem Text von BSI-Standard 300-1. Der Build stammt vom 29.10.2026, der Standard ist vom 20.10.2026. Halten Sie die Abweichungen mit Katalogstand in Ihrem Anforderungspaket fest.
Erstens der Umsetzungsstatus. Die Erläuterung zu UMS.1.1 lautet: „Der Umsetzungsstatus einer Anforderung kann grundsätzlich nur ‚umgesetzt‘ (‚ja‘) oder ‚nicht umgesetzt‘ (‚nein‘) sein.“ Der Standard kennt drei Werte, nämlich „erfüllt“, „nicht erfüllt“ und „nicht anwendbar“ (300-1, Kap. 4.1.1).
Zweitens die Anforderungen ohne Zielobjektkategorie. Nach 300-1 sind sie verpflichtend in das Anforderungspaket aufzunehmen (Kap. 3.4.1). Die Erläuterung zu STM.2.1.5 sieht dagegen eine Relevanzentscheidung vor: Nicht relevante Anforderungen „werden aus dem Anforderungspaket gestrichen“, mit Begründung.
Drittens die Sicherheitsniveaus. Nach 300-1 enthalten Anforderungen mit dem Sicherheitsniveau „erhöht“ das Modalverb KANN (Kap. 3.4.2). Drei Anforderungen im Build sind mit „erhöht“ und SOLLTE gekennzeichnet: BES.1.4 „Outsourcing-Strategie“, DET.4.12.1 „Auslastung des Netzes“ und REA.2.5 „IT-Forensik“.
Wir richten uns in diesen Fällen nach dem Standardtext und halten die Abweichung mit Katalogstand im Anforderungspaket fest. Wie Sie Status und Abweichungen im Einzelnen dokumentieren, steht auf der Seite Anforderungen bewerten, Abweichungen dokumentieren.
Von den BSI-Bausteinen zu den Praktiken
Im IT-Grundschutz-Kompendium waren die Anforderungen in Bausteinen gebündelt und nach Schichten geordnet: prozessorientiert ISMS, ORP, CON, OPS und DER, systemorientiert INF, NET, SYS, APP und IND (200-2, Kap. 2.4). Grundschutz++ ordnet nach Praktiken. Die folgende Gegenüberstellung zeigt, was sich beim Lesen und Modellieren ändert.
| Merkmal | IT-Grundschutz-Kompendium (200-2) | Anwenderkatalog Grundschutz++ (300-1) |
|---|---|---|
| Ordnung | Bausteine in zehn Schichten | 20 Praktiken mit Schwerpunkt Methodik (6), Organisatorisch (8) und Technisch (6) |
| Zuordnung zum Informationsverbund | Bausteine werden auf Zielobjekte modelliert (200-2, Kap. 8.3) | Assets werden 39 Zielobjektkategorien zugeordnet, übergeordnete Kategorien gelten mit (300-1, Kap. 3.4.2) |
| Gefährdungsbezug | Kreuzreferenztabelle je Baustein | G0-Kennung direkt an der Anforderung (300-1, Anhang 4) |
| Erläuterung | Umsetzungshinweise zu vielen Bausteinen | Erläuterungstext je Anforderung |
| Format | Dokument | OSCAL-JSON |
Was sich bei Anforderungsstufen, Modalverben und Umsetzungsstatus methodisch ändert, steht im Vergleich IT-Grundschutz 2023 und Grundschutz++.
Wohin die alten Schichten im Entwurfs-Mapping zeigen
Das BSI-Mapping von IT-Grundschutz 2023 auf Grundschutz++ hat den Status Entwurf. Wir haben die 1.185 Zuordnungen nach der Schicht der alten Anforderung und nach der Praktik der Zielkennung in der Mappingdatei ausgezählt. Die Ziele liegen in 18 der 20 Praktiken; STM und RISK kommen nicht vor. 16 dieser Ziele (VRB.1.2) gibt es im Build vom 29.10.2026 nicht mehr; ohne sie zeigen aus ISMS 10 und aus DER 28 Zuordnungen auf VRB. Die Tabelle zeigt nur die Richtung, keine geprüfte Eins-zu-eins-Übertragung.
| Schicht 2023 | Zuordnungen | Häufigste Ziel-Praktiken (Anzahl) |
|---|---|---|
| ISMS | 45 | UMS (14), VRB (13), GC (6) |
| ORP | 45 | UMS (18), PERS (8), ARCH (6) |
| CON | 62 | DEV (26), TEST (11), ARCH (6), DET (6) |
| OPS | 162 | DET (61), TEST (49), ARCH (28) |
| DER | 113 | DET (40), VRB (32), UMS (22) |
| INF | 87 | ARCH (43), TEST (17), DET (13) |
| NET | 271 | ARCH (219), DET (34), UMS (7) |
| SYS | 140 | ARCH (63), DET (55), KONF (9) |
| APP | 194 | KONF (60), DET (36), ARCH (30) |
| IND | 66 | DET (21), ARCH (16), TEST (10) |
Für die Arbeit heißt das: Ein alter Baustein verteilt sich auf mehrere Praktiken. Wer aus einem bestehenden Grundschutz-Check überträgt, sucht deshalb besser je Anforderung als je Baustein. Welche Änderungen das für Ihre Unterlagen bedeutet, beschreibt der Vergleich IT-Grundschutz 2023 und Grundschutz++, die Durchführung die Seite Migration.
Was der Katalog nicht leistet
Der Katalog liefert Anforderungen, keine fertigen Maßnahmen. Welche Maßnahme eine Anforderung erfüllt, legen Sie in der Umsetzungsplanung fest (300-1, Kap. 4.3). Laut Meilensteinplan des BSI (Stand Oktober 2026) soll das Konzept zur Leistungsmessung am 26.02.2027 in die Methodik integriert sein, Leistungskennzahlen für jede Methodik-Anforderung folgen zum 31.03.2027. Solange einheitliche Vorgaben fehlen, sind Institutionen in der Ausgestaltung der Leistungsbewertung frei (300-1, Kap. 5.1).
Blaupausen, also vorgefertigte Anforderungskataloge für bestimmte Anwendungsszenarien, sieht der Standard vor; für bestimmte Institutionen kann es verpflichtende Blaupausen geben (300-1, Kap. 3.3). Welche das sind, nennen die hier ausgewerteten Quellen (Stand 01.11.2026) nicht.
Bei hohem Schutzbedarf reicht der Katalog allein nicht aus. Dann verlangt der Standard eine eigene Risikobetrachtung, für die die Anforderungen mit Sicherheitsniveau „erhöht“ ein Fundus sind (300-1, Kap. 2.11 und 3.4.2). Wie das abläuft, zeigt die Seite Risikoanalyse.
Zum Lesen im Browser verweist das BSI-Repository auf einen Stand-der-Technik-Viewer (https://bsi-community.github.io/Stand-der-Technik-Viewer/). Für das Anforderungspaket bleibt die Datei mit dokumentiertem Stand die Grundlage. Wenn Sie einen Altbestand aus dem IT-Grundschutz-Kompendium 2023 abgleichen wollen, unterstützt Sie das Team von Blackfort Technology mit der Readiness-Analyse und der Migration; die Leistungen stehen auf der Seite Beratung.
Rechtehinweis: Zitate von der BSI-Seite zu Grundschutz++ (abgerufen am 01.11.2026) und aus BSI-Standards sind © Bundesamt für Sicherheit in der Informationstechnik. Sie stehen nicht unter CC BY-SA 4.0; der Lizenzhinweis am Seitenende gilt nur für die Auszüge aus den Katalogdaten.
Häufige Fragen
Gibt es im Grundschutz++ noch BSI-Bausteine?
Wie viele Anforderungen hat der Grundschutz++ Katalog?
Wo kann ich den Anwenderkatalog Grundschutz++ herunterladen?
control_layer/Grundschutz++/Grundschutz++-resolved_catalog.json. Notieren Sie beim Herunterladen Commit und Build-Datum.