Grundschutz++ im Regulatory
DORA bleibt die verbindliche regulatorische Basis. Grundschutz++ ergänzt sie als strukturierte BSI-Sicht auf Anforderungen, Assets, Umsetzung, Überwachung und Verbesserung.
Maschinenlesbare Anforderungen statt statischer Linkliste
Das BSI stellt in der Stand-der-Technik-Bibliothek strukturierte Sicherheitsanforderungen als OSCAL-Daten bereit. Der Control Layer enthält Kataloge, Profile, aufgelöste Kataloge und Mappings. Für den Regulatory-Bereich ist deshalb die aktuelle Bibliothek die bevorzugte BSI-Quelle für konkrete GS++-Anforderungen.
Fünf Schritte – passend zu unserer Framework-Logik
Grundschutz++ verbindet Governance und Compliance mit Strukturmodellierung, Umsetzung, Monitoring/Evaluation und Verbesserung. Anforderungen werden über Geschäftsprozesse, Assets und Zielobjektkategorien zu einem individuellen Anforderungspaket modelliert.
BSI ergänzt – es ersetzt weder DORA noch die originäre Fachmethode
| Frage | Bevorzugte Quelle |
|---|---|
| Was ist verbindlich? | DORA · RTS · ITS mit Artikel |
| Wie wird ein IT-Service-Prozess methodisch organisiert? | z. B. ITIL, wenn dort die originäre Practice liegt |
| Welche BSI-Anforderungen passen zum Informationsverbund und zu Assets? | Grundschutz++ / Stand-der-Technik-Bibliothek |
| Wie wird ein ISMS, Risiko oder BCM methodisch aufgebaut? | BSI 200-1 bis 200-4, wenn genau dieser methodische Aspekt gemeint ist |
| Was gilt technisch als geeignete Konkretisierung? | originäre technische Quelle; ggf. BSI TR, TeleTrusT oder GS++ |
Ein lebender Gegencheck
Die Stand-der-Technik-Bibliothek wird sukzessive ergänzt. Deshalb verankert der Regulatory-Bereich nicht blind einzelne Controls als unveränderliche Wahrheit. Die fachliche Praktik-Zuordnung bleibt sichtbar; konkrete Controls werden bei einer späteren Detailprüfung immer gegen den dann aktuellen aufgelösten Katalog geprüft.
Externe Verpflichtungen werden in das Anforderungspaket integriert
Genau hier passt Grundschutz++ zu unserem Regulatory: Die Methodik sieht ausdrücklich vor, Anforderungen aus dem individuellen Compliance-Umfeld zu identifizieren, zu modellieren, auf Redundanzen zu prüfen und in das Anforderungspaket zu integrieren. DORA bleibt dabei die Rechtsquelle; GS++ liefert eine mögliche strukturierte Verarbeitungslogik.
Asset-Modellierung und Zielobjektkategorien helfen anschließend dabei, Anforderungen nicht abstrakt, sondern auf konkrete Schutzobjekte, Geschäftsprozesse und Verantwortlichkeiten zu beziehen.
Warum GS++ zu unserem Cross-Regulatory-Modell passt
Der Leitfaden Grundschutz++ beschreibt ausdrücklich die Ergänzung des Anforderungspakets aufgrund externer Verpflichtungen. Regulatorische Anforderungen werden identifiziert, modelliert, konsolidiert und in das Anforderungspaket integriert. Der Regulatory-Bereich nutzt diese Logik als Umsetzungshilfe – die Rechtswirkung stammt weiterhin ausschließlich aus der jeweiligen Regulierung.