NIS2-Betroffenheit geklärt — und jetzt? Die operativen Lücken nach dem ISMS
Sie haben geprüft, ob Ihr Unternehmen unter NIS2 fällt. Die Antwort ist ja. Sie haben ein ISMS. Und jetzt stellen Sie fest: Zwischen dem, was Ihr ISMS abdeckt, und dem, was NIS2 operativ verlangt, klafft eine Lücke. Dieser Artikel zeigt, wo sie liegt – und wie Sie sie schließen.
NIS2-Betroffenheit geklärt — und jetzt? Die operativen Lücken nach dem ISMS
Die Betroffenheitsprüfung ist erledigt – über das BSI-Tool, über eine interne Analyse oder mit Unterstützung von Beratern. Ihr Unternehmen ist eine besonders wichtige oder wichtige Einrichtung im Sinne des BSIG. Sie haben sich beim BSI registriert oder sind dabei. Und jetzt?
Die meisten Unternehmen haben an diesem Punkt ein ISMS, eine Registrierung und eine offene Frage: Was müssen wir jetzt eigentlich noch tun? Die Antwort liegt nicht in weiterer Dokumentation, sondern in operativen Fähigkeiten, die ein ISMS allein nicht liefern kann.
Direkt zu:
- Die Lücke, die niemand erwartet
- Sechs operative Anforderungen, die Ihr ISMS nicht abdeckt
- Der Fahrplan: Vom ISMS zur NIS2-Compliance
Der typische Stand der Dinge
Wenn Unternehmen ihre NIS2-Betroffenheit feststellen, passiert in der Regel Folgendes:
Schritt 1: Die BSI-Betroffenheitsprüfung ergibt, dass das Unternehmen in den Anwendungsbereich fällt – als besonders wichtige oder wichtige Einrichtung. Rund 80 % der betroffenen Unternehmen wissen das laut Brancheneinschätzungen noch nicht oder haben gerade erst damit begonnen, sich damit auseinanderzusetzen.
Schritt 2: Das Unternehmen stellt fest, dass es bereits ein ISMS hat – oft nach ISO 27001 zertifiziert, eingebettet in ein GRC-Tool. Die erste Erleichterung: „Wir haben schon vieles, was NIS2 verlangt."
Schritt 3: Eine Gap-Analyse zeigt, dass ISO 27001 tatsächlich rund 70 % der NIS2-Anforderungen abdeckt – insbesondere die Governance-Aspekte aus Artikel 20 und weite Teile von Artikel 21.
Schritt 4: Dann kommt die unbequeme Erkenntnis: Die verbleibenden 30 % sind nicht einfach „weitere Dokumentation." Es sind operative Fähigkeiten, die das ISMS nicht abbildet und für die es nicht konzipiert wurde.
Genau hier bleiben viele Unternehmen stehen. Nicht aus Nachlässigkeit, sondern weil der nächste Schritt nicht offensichtlich ist. Das ISMS liefert eine Landkarte – aber kein Fahrzeug.
Die Lücke, die niemand erwartet {#die-luecke}
Die Lücke zwischen ISMS und NIS2-Compliance ist keine Dokumentationslücke. Es ist eine Fähigkeitslücke.
Ein ISMS beantwortet die Frage: „Haben wir einen Prozess für X?" NIS2 stellt eine andere Frage: „Können wir X unter Zeitdruck, gegenüber Dritten, nachweisbar operativ umsetzen?"
Dieser Unterschied durchzieht die gesamte Richtlinie. Drei Bereiche sind besonders betroffen:
Meldepflicht: Ein ISMS hat einen Incident-Response-Plan. NIS2 verlangt die Fähigkeit, innerhalb von 24 Stunden eine koordinierte Frühwarnung an das BSI zu liefern – während der Vorfall läuft. Das ist kein Dokumentationsunterschied. Das ist ein Betriebsmodellunterschied.
Lieferkettensicherheit: Ein ISMS hat einen Lieferantenbewertungsprozess. NIS2 verlangt kontinuierliche Überwachung der Sicherheitslage direkter Zulieferer – mit anlassbezogenen Re-Assessments und jederzeit abrufbaren Nachweisen. Einmal im Jahr ein Fragebogen reicht nicht.
Nachweispflicht: Ein ISMS bereitet auf Audits vor. NIS2 gibt Aufsichtsbehörden die Befugnis, jederzeit Nachweise anzufordern. Evidenz muss kontinuierlich verfügbar sein, nicht erst für den nächsten Audit-Termin zusammengestellt werden.
Die gute Nachricht: Das ISMS bleibt die Grundlage. Es muss nicht ersetzt werden. Aber es muss ergänzt werden – um eine operative Schicht, die das umsetzt, was das ISMS dokumentiert.
Sechs operative Anforderungen, die Ihr ISMS nicht abdeckt {#sechs-anforderungen}
1. Incident Management unter Zeitdruck
Was NIS2 verlangt: Frühwarnung innerhalb von 24 Stunden, qualifizierte Meldung innerhalb von 72 Stunden, Abschlussbericht innerhalb eines Monats (Art. 23, § 32 BSIG). Parallelsteuerung mit DSGVO-Meldepflichten und vertraglichen Obligations.
Was das ISMS liefert: Einen Incident-Response-Plan mit Rollen, Eskalationswegen und Prozessbeschreibungen.
Was fehlt: Die operative Infrastruktur für Echtzeit-Koordination zwischen Security, Legal, Kommunikation und Geschäftsführung. Versionierte Dokumentation während des Vorfalls. Templates für regulatorische Meldungen. Ein System, das unter Druck funktioniert – nicht nur ein Plan, der beschreibt, wie es funktionieren sollte.
→ Vertiefung: NIS2-Meldepflicht: Die 24-Stunden-Frist operativ einhalten
2. Kontinuierliche Lieferantenüberwachung
Was NIS2 verlangt: Sicherheit der Lieferkette einschließlich der spezifischen Schwachstellen jedes direkten Zulieferers. Berücksichtigung der Gesamtqualität der Cybersicherheitspraktiken. Laufende Risikobewertung, nicht punktuelle Momentaufnahmen (Art. 21(2)(d), § 30 BSIG).
Was das ISMS liefert: Lieferantenkategorisierung, jährliche Assessment-Zyklen, dokumentierte Bewertungsergebnisse.
Was fehlt: Laufendes Monitoring (Zertifikate, Schwachstellen, Vorfälle beim Lieferanten). Trigger-basierte Re-Assessments, wenn sich etwas ändert. Eine integrierte Übersicht über den aktuellen Sicherheitsstatus aller relevanten Lieferanten. Strukturierte Kommunikation mit Lieferanten bei Änderungen.
→ Vertiefung: NIS2-Lieferkettensicherheit: Warum jährliche Lieferantenbewertungen nicht mehr reichen
3. Nachweise auf Abruf
Was NIS2 verlangt: Verfahren zur Bewertung der Wirksamkeit von Maßnahmen (Art. 21(2)(f)). Das BSI kann jederzeit Nachweise anfordern, Vor-Ort-Inspektionen und Audits durchführen (§§ 61-65 BSIG).
Was das ISMS liefert: Audit-Vorbereitung in geplanten Zyklen. Dokumentation von Maßnahmen und Kontrollen.
Was fehlt: Jederzeit abrufbare Artefakte mit Metadaten (Versionsstatus, Gültigkeit, Verantwortliche, Änderungshistorie). Integrierte Nachweisführung, die Kontrollen, Lieferantenbewertungen und Vorfallberichte verknüpft. Evidenz als kontinuierlicher Output, nicht als Audit-Vorbereitung.
→ Vertiefung: NIS2-Nachweispflicht: Von Dokumentation zu kontinuierlicher Evidenz
4. Geschäftsführerverantwortung operationalisieren
Was NIS2 verlangt: Die Geschäftsführung muss Risikomanagementmaßnahmen billigen, ihre Umsetzung überwachen und haftet persönlich für Verstöße. Ein Verzicht auf Ersatzansprüche ist unwirksam (Art. 20, § 38 BSIG). Geschäftsführer müssen sich regelmäßig schulen lassen.
Was das ISMS liefert: Rollen- und Verantwortungsdefinitionen. Management-Reviews. Schulungsrichtlinien.
Was fehlt: Ein nachweisbarer Informationsfluss von operativen Sicherheitsthemen zur Geschäftsführung. Die Fähigkeit der Geschäftsführung, im Ernstfall auf aufbereitete, aktuelle Lageinformationen zuzugreifen. Dokumentation, die belegt, dass die Geschäftsführung ihre Überwachungspflicht tatsächlich wahrgenommen hat – nicht nur, dass sie eine Richtlinie unterschrieben hat.
5. Externe Kommunikation bei Vorfällen
Was NIS2 verlangt: Betroffene Einrichtungen müssen die Empfänger ihrer Dienste unverzüglich über erhebliche Vorfälle informieren, die sich auf die Diensterbringung auswirken könnten – einschließlich möglicher Gegenmaßnahmen (Art. 23(1)).
Was das ISMS liefert: Interne Kommunikationspläne. Eventuell eine PR-Eskalationsrichtlinie.
Was fehlt: Ein strukturierter Prozess für externe Vorfallkommunikation – gegenüber Kunden, Partnern und ggf. der Öffentlichkeit. Abgestimmte Sprachregelungen zwischen Legal, Kommunikation und Geschäftsführung. Versionierte, nachweisbare Kommunikation über einen definierten Kanal.
6. Koordinierte Zusammenarbeit mit Behörden
Was NIS2 verlangt: Zusammenarbeit mit dem BSI und ggf. dem CSIRT. Das BSI kann jederzeit Informationen anfordern, Anordnungen erlassen und Audits durchführen. Bei grenzüberschreitenden Vorfällen können mehrere nationale Behörden involviert sein.
Was das ISMS liefert: Einen benannten Ansprechpartner. Eventuell eine Kontaktliste.
Was fehlt: Ein etablierter Kommunikationskanal zum BSI, der über die Erstregistrierung hinausgeht. Die Fähigkeit, auf Informationsanfragen schnell und strukturiert zu reagieren. Vorbereitung auf Vor-Ort-Inspektionen, die nicht angekündigt werden müssen.
Der Fahrplan: Vom ISMS zur NIS2-Compliance {#der-fahrplan}
Die Lücke zu schließen ist kein Komplettumbau. Es ist ein systematischer Ausbau dessen, was bereits da ist. Fünf Schritte:
Phase 1: Gap-Analyse (Woche 1–2)
Mappen Sie Ihr bestehendes ISMS gegen die operativen NIS2-Anforderungen – nicht gegen die Governance-Anforderungen, die sind abgedeckt. Die sechs Punkte oben sind der Rahmen. Für jeden Punkt: Können wir das heute operativ umsetzen? Wenn nein: Was fehlt konkret?
Phase 2: Priorisierung nach Risiko (Woche 2–3)
Nicht alle Lücken sind gleich kritisch. Die Meldepflicht hat die höchste regulatorische Dringlichkeit – sie gilt jetzt und hat feste Fristen. Die Lieferkettensicherheit hat das höchste operatives Komplexitätsniveau. Die Nachweispflicht wird bei der ersten BSI-Anfrage zum Problem. Priorisieren Sie entsprechend.
Phase 3: Operative Systeme aufbauen (Monat 1–3)
Für die Meldepflicht: Incident-Management-System einrichten, Rollen definieren, Templates vorbereiten, erste Tabletop-Übung durchführen. Für die Lieferkette: Lieferantenregister auf NIS2-Anforderungen upgraden, Monitoring-Fähigkeit aufbauen, vertragliche Grundlagen prüfen. Für die Nachweispflicht: Evidenzmanagement von „Ablage" auf „Abruf" umstellen.
Phase 4: ISMS und operative Systeme verbinden (Monat 2–4)
Das ISMS bleibt das Steuerungsinstrument. Die operativen Systeme ergänzen es um die Fähigkeiten, die NIS2 zusätzlich verlangt. Die Verbindung muss in beiden Richtungen funktionieren: Das ISMS informiert die operative Umsetzung (Richtlinien, Risikoklassifizierungen). Die operativen Systeme liefern Nachweise zurück ins ISMS (aktuelle Assessments, Vorfallberichte, Evidenz).
Ein ISMS für die interne Governance. Ein Trust Center für die externe Kommunikation und Nachweisführung. Beide Seiten derselben Medaille.
Phase 5: Testen und iterieren (laufend)
Tabletop-Übungen für das Melderegime. Review-Zyklen für die Lieferantenüberwachung. Probeabrufe der Nachweisführung. NIS2-Compliance ist kein Projekt mit Endtermin – es ist ein operatives Betriebsmodell.
Die häufigsten Fehler an diesem Punkt
„Wir machen eine weitere Gap-Analyse." Gap-Analysen gegen ISO 27001 oder gegen die Governance-Anforderungen von NIS2 liefern immer das gleiche Ergebnis: „sieht gut aus." Die Lücke liegt nicht in der Governance. Sie liegt in der operativen Umsetzung. Eine Gap-Analyse, die nur prüft, ob Prozesse existieren, findet sie nicht.
„Wir erweitern unser GRC-Tool." GRC-Tools sind für Governance, Risk und Compliance konzipiert – für die Steuerungsebene. NIS2 verlangt zusätzlich operative Fähigkeiten: Echtzeit-Kommunikation, laufendes Monitoring, jederzeit abrufbare Nachweise. Ein GRC-Tool kann das in der Regel nicht leisten – es ist dafür nicht gebaut.
„Wir warten auf die ENISA-Zertifizierung." Artikel 46 der NIS2-Richtlinie sieht einen europäischen Zertifizierungsrahmen vor. Aber: Die Anforderungen gelten jetzt. Die Zertifizierung kommt später. Wer wartet, ist in der Zwischenzeit nicht compliant.
„Das macht der CISO." § 38 BSIG macht die Geschäftsführung persönlich haftbar. Der CISO kann die Umsetzung steuern, aber die Verantwortung liegt bei der Geschäftsführung. Das ist keine Formalität – es ist eine persönliche Haftungsfrage.
Quellen
- Richtlinie (EU) 2022/2555 (NIS2-Richtlinie) – Volltext – Artikel 20, 21 und 23 zu Governance, Risikomanagement und Meldepflichten.
- BSI – NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) – §§ 30, 32, 38 und 61-65 BSIG zu Risikomanagement, Meldepflichten, Geschäftsführerhaftung und Aufsichtsbefugnissen.
- BSI – NIS-2-Betroffenheitsprüfung – Orientierungshilfe zur Prüfung der NIS2-Betroffenheit.
- BSI – NIS-2: Was tun? – Leitfaden des BSI zur schrittweisen NIS2-Umsetzung.
- ENISA – Implementing Guidance on NIS2 Security Measures – Umsetzungsempfehlungen für die Risikomanagementmaßnahmen nach Artikel 21.