Governance, Betrieb, Technik, Produkt
Informationssicherheit wird auf vier Ebenen verhandelt. Auf jeder gelten andere Regelwerke, und jede verlangt andere Nachweise. Grundschutz++ setzt auf der Ebene des Managementsystems an und verbindet die Leitungsebene mit dem Betrieb. Es ersetzt weder IT-Service-Management noch Produktsicherheit, liefert ihnen aber Anforderungen und nimmt ihre Nachweise auf.
| Ebene | Leitfrage | Typische Regelwerke | Nachweis |
|---|---|---|---|
| Governance | Wer trägt Verantwortung, welches Risiko ist tragbar? | § 38 BSIG, ISO/IEC 27014, COBIT, IKS | Leitlinie, Risikoappetit, Managementbewertung |
| Managementsystem | Wie wird Sicherheit geplant, umgesetzt, geprüft und verbessert? | Grundschutz++ (300-1), ISO/IEC 27001, 200-4, ISO 22301 | Zertifikat, Testat, interne Audits |
| Betrieb und Technik | Wie laufen Change, Incident, Konfiguration und Schwachstellenmanagement? | ITIL, NIST CSF 2.0, Anwenderkatalog GS++, Stand der Technik | Tickets, Konfigurationsstände, Scans, Kennzahlen |
| Produkt | Ist das Produkt mit digitalen Elementen sicher entwickelt und wird es gepflegt? | Cyber Resilience Act, IEC 62443, Maschinenverordnung | Konformitätserklärung, CE-Kennzeichnung, SBOM, Meldungen |
ITIL: Wo das ISMS im IT-Betrieb ankommt
Grundschutz++ formuliert, was erreicht werden muss. Ob es im Alltag gelingt, entscheidet der IT-Betrieb. ITIL beschreibt diesen Betrieb in Praktiken; 2026 hat PeopleCert ITIL (Version 5) eingeführt, ITIL 4 läuft parallel weiter. Information Security Management ist dort selbst eine Praktik.
Bewährt hat sich die Trennung in Plan, Build, Run: Das ISMS plant und gibt Anforderungen vor, Projekte bauen sie in neue Services ein, der Betrieb hält sie im Run aufrecht und liefert die Nachweise zurück.
| ITIL-Praktik | Bezug in Grundschutz++ / ISO 27001 | Nachweis aus dem Betrieb |
|---|---|---|
| Information Security Management | Methodik 300-1, Kap. 4 bis 10 ISO 27001 | ISMS-Dokumentation, Risikoregister |
| Change Enablement | Änderungsmanagement im Anwenderkatalog, ISO 27001 A.8.32 | Change-Tickets mit Sicherheitsbewertung |
| Incident Management | Behandlung von Sicherheitsvorfällen, A.5.24 bis A.5.28, Meldepflicht § 32 BSIG | Vorfallprotokolle, Meldefristen |
| Service Configuration Management | Assets und Zielobjektkategorien (Kap. 3.2) | CMDB als Quelle für das Anforderungspaket |
| Supplier Management | Lieferanten und Dienstleister, A.5.19 bis A.5.22, Lieferkette § 30 BSIG | Verträge, AVV, Lieferantenbewertungen |
| Service Continuity Management | Verweis auf das BCMS (Kap. 2.5), BSI-Standard 200-4 | BIA, Wiederanlaufpläne, Übungsberichte |
| Measurement and Reporting | Leistungsbewertung (Kap. 5.1), Kennzahlen laut BSI ab 2027 | Kennzahlen aus Tickets und Monitoring |
Der größte Hebel liegt in der CMDB: Ist sie sauber geführt, ergibt sich das Anforderungspaket nach Grundschutz++ fast von selbst, und jede Änderung im Bestand ist auch eine Änderung im ISMS.
NIST Cybersecurity Framework 2.0
Das NIST Cybersecurity Framework (CSF) 2.0 von 2024 gliedert Cybersicherheit in sechs Funktionen. Es eignet sich gut, um der Leitung den Stand zu zeigen, und ist international verbreitet. Grundschutz++ ist mit dem NIST über OSCAL verbunden: Das Datenformat des Anwenderkatalogs stammt von dort.
| CSF-Funktion | Inhalt | Entsprechung bei BSI |
|---|---|---|
| Govern | Strategie, Rollen, Risikoappetit, Lieferkette | Kap. 2.7, 2.8 von 300-1; § 38 BSIG |
| Identify | Assets, Risiken, Verbesserung | Geschäftsprozesse, Schutzbedarf, Anforderungspaket (Kap. 2 und 3) |
| Protect | Zugriff, Schulung, Datenschutz, Plattformsicherheit | MUSS- und SOLLTE-Anforderungen des Anwenderkatalogs |
| Detect | Überwachung, Erkennung von Ereignissen | Detektion im Anwenderkatalog, Leistungsbewertung |
| Respond | Vorfallbehandlung, Kommunikation | Vorfallbehandlung, Meldepflichten |
| Recover | Wiederherstellung | BSI-Standard 200-4, Notfallvorsorge |
Für international aufgestellte Organisationen heißt das: Ein CSF-Profil und ein Anforderungspaket nach Grundschutz++ lassen sich über ein Master Control Framework verbinden. Die Logik dazu beschreiben wir bei den Frameworks.
Cyber Resilience Act und Produktsicherheit
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) richtet sich an Hersteller, Importeure und Händler von Produkten mit digitalen Elementen. Er regelt die Sicherheit des Produkts, nicht die der Organisation. Seit dem 11.09.2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, danach Abschlussbericht. Ab dem 11.12.2027 gelten die übrigen Pflichten, darunter die grundlegenden Anforderungen aus Anhang I, Konformitätsbewertung und CE-Kennzeichnung.
Wo CRA und ISMS sich treffen
| Thema | CRA (Produkt) | ISMS (Organisation) |
|---|---|---|
| Risiko | Cybersicherheitsrisikobewertung des Produkts | Risikobetrachtung mit den 35 Mindestkriterien |
| Schwachstellen | Schwachstellenbehandlung über den Supportzeitraum, SBOM | Patch- und Schwachstellenmanagement im Betrieb |
| Vorfälle | Meldung an CSIRT und ENISA über die zentrale Meldeplattform | Vorfallbehandlung, Meldung nach § 32 BSIG |
| Entwicklung | Security by Design, sichere Standardkonfiguration | Anforderungen an Entwicklung und Beschaffung |
| Lieferkette | Sorgfalt bei Komponenten Dritter | Lieferantenanforderungen, CRA-Konformität als Beschaffungskriterium |
Wer ein ISMS betreibt, hat Vorfall-, Schwachstellen- und Lieferantenprozesse schon. Für den CRA werden sie auf das Produkt erweitert, nicht neu erfunden. Betreiber profitieren umgekehrt: Die CRA-Konformität von Komponenten wird zum prüfbaren Nachweis in der eigenen Lieferkette.
Unser Vorgehen beim CRA
- Betroffenheit und Einstufung Welche Produkte fallen unter den CRA, in welche Kategorie (Standard, wichtig Klasse I oder II, kritisch)? Welche Rolle hat Ihr Unternehmen?
- Meldefähigkeit Meldeweg für 24 und 72 Stunden, Zuständigkeiten, Anbindung an PSIRT und Vorfallbehandlung, denn diese Pflichten gelten bereits.
- Lückenanalyse Anhang I Produktanforderungen und Schwachstellenbehandlung gegen den Ist-Stand, einschließlich SBOM und Supportzeitraum.
- Prozesse integrieren Ein Risikoverfahren und ein Schwachstellenprozess für ISMS und Produkt, abgestimmt mit Qualitätsmanagement und Entwicklung.
- Konformität nachweisen Technische Dokumentation, Konformitätsbewertung, Vorbereitung auf benannte Stellen, wo nötig.
KRITIS-Nachweise nach § 39 BSIG
Betreiber kritischer Anlagen weisen die Umsetzung ihrer Maßnahmen dem BSI regelmäßig nach, durch Prüfungen von Prüfteams mit Prüfverfahrenskompetenz nach § 39 Abs. 2 BSIG. Ein ISMS nach Grundschutz++ ist dafür eine starke Grundlage, aber kein Automatismus: Entscheidend ist, dass der Geltungsbereich die kritische Dienstleistung vollständig abdeckt und branchenspezifische Sicherheitsstandards berücksichtigt sind.
- Gemeinsame Basis: Geschäftsprozesse und Anlagen aus der KRITIS-Betrachtung sind dieselben, die Grundschutz++ in Kap. 2.5 erfasst.
- Nachweise doppelt nutzen: Interne Audits und Kennzahlen nach Kap. 5 von 300-1 liefern Prüfmaterial für die KRITIS-Prüfung.
- Physische Resilienz: Mit dem KRITIS-Dachgesetz kommen Pflichten zur physischen Resilienz hinzu; die Notfallvorsorge nach 200-4 wird damit noch wichtiger.
ATM Consulting prüft als Prüfteam nach § 39 BSIG und schult KRITIS-Auditoren nach dem Curriculum des BSI. Schulung KRITIS-Auditor →
Datenschutz: TOM, AVV und DSFA
Die DSGVO verlangt in Art. 32 technische und organisatorische Maßnahmen (TOM) unter Berücksichtigung des Stands der Technik. Das ist derselbe Maßstab, den Grundschutz++ für die Informationssicherheit anlegt. Wer beides getrennt führt, beschreibt dieselben Maßnahmen zweimal.
| DSGVO | Inhalt | Anknüpfung an Grundschutz++ |
|---|---|---|
| Art. 30 VVT | Verzeichnis der Verarbeitungstätigkeiten | An die Geschäftsprozesse aus Kap. 2.5 koppeln |
| Art. 32 TOM | Sicherheit der Verarbeitung nach dem Stand der Technik | Anforderungspaket mit Umsetzungsstatus als TOM-Nachweis |
| Art. 28 AVV | Vertrag mit Auftragsverarbeitern, TOM als Anlage | Lieferantenanforderungen; TOM-Anlage aus denselben Anforderungen ableiten |
| Art. 35 DSFA | Folgenabschätzung bei hohem Risiko für Betroffene | Schutzbedarf „hoch“ und eigene Risikobetrachtung als Eingang |
| Art. 25 | Datenschutz durch Technikgestaltung und Voreinstellungen | Anforderungen an Entwicklung und Beschaffung, beim Produkt auch CRA |
Methodisch hilft das Standard-Datenschutzmodell (SDM) der Datenschutzkonferenz. Es übersetzt die DSGVO in Gewährleistungsziele wie Vertraulichkeit, Integrität, Verfügbarkeit, Datenminimierung, Transparenz und Intervenierbarkeit. Die ersten drei decken sich mit den Schutzzielen der Informationssicherheit; die übrigen ergänzt der Datenschutz. Wichtig bleibt der Perspektivwechsel: Die DSGVO schützt die betroffenen Personen, das ISMS die Institution.
IT-Grundschutz als Anforderung und als Nachweis
IT-Grundschutz ist längst mehr als eine Methode. Gesetzgeber, Fördergeber und Aufsichten nutzen ihn als Maßstab, und Zertifikat oder Testat dienen als Nachweis gegenüber Dritten. Mit Grundschutz++ stellt sich überall dieselbe Frage: Welcher Nachweis gilt künftig?
| Kontext | Anforderung heute | Typischer Nachweis | Mit Grundschutz++ |
|---|---|---|---|
| Förderprogramme für Kommunen | Mindestniveau als Fördervoraussetzung, z. B. Bayern | Testat Basis-Absicherung oder ISO-27001-Zertifikat | Offen; Landkarte und Empfehlungen |
| Bundesverwaltung | IT-Grundschutz und Mindeststandards des BSI | Sicherheitskonzepte, Prüfungen | Grundschutz++ als Nachfolger des Kompendiums |
| Fachverfahren mit EU-Mitteln, z. B. Agrarzahlstellen | Zulassungskriterien verlangen Informationssicherheit nach ISO/IEC 27001 | ISO-27001-Zertifikat, Prüfung durch bescheinigende Stelle | ISO 27001 auf Basis Grundschutz++ ab 2027 möglich |
| Betreiber kritischer Anlagen | § 30 und § 39 BSIG | Prüfung nach § 39 BSIG | Zertifikat als Baustein, Geltungsbereich beachten |
| Cloud-Dienste | Mindeststandard, EVB-IT Cloud, § 393 SGB V | C5-Testat | C5 bleibt eigener Katalog |
| Auftragsverarbeitung | Art. 28 und 32 DSGVO | AVV mit TOM-Anlage | TOM aus dem Anforderungspaket ableiten |
Für Fördergeber und Aufsichten empfehlen wir, Anforderungen an Schutzniveaus zu knüpfen, nicht an Vorgehensweisen. Ein Satz wie „ISMS nach IT-Grundschutz mit mindestens Basis-Absicherung oder Grundschutz++ mit erfüllten MUSS-Anforderungen“ bleibt über den Umstieg hinweg gültig.
Ein Vorgehen für alle Regelwerke
Wir arbeiten in jedem Projekt nach demselben Muster, egal ob ISMS, KRITIS, CRA oder Datenschutz im Vordergrund steht:
- Kontext Geschäftsprozesse, Produkte und Pflichten erfassen, eine Prozesslandkarte für alle Systeme.
- Anforderungen bündeln Alle geltenden Regelwerke in einem Master Control Framework, Grundschutz++ als Kern.
- Risiko einmal bewerten Eine Methode, die die 35 Mindestkriterien erfüllt und für BCM, Datenschutz und Produkt trägt.
- Im Betrieb verankern Plan, Build, Run: Anforderungen in Change, Incident und Konfiguration einbauen.
- Nachweisen Kennzahlen, interne Audits und externe Prüfungen aus derselben Datenbasis.
Beratung und Prüfung trennen wir strikt: Ein System, das wir mit aufbauen, prüfen wir nicht selbst. ATM Consulting →