NIS2 Artikel 21 und 23: Warum ein ISMS seit NIS2 nicht mehr ausreicht

Die NIS2-Richtlinie hat die Spielregeln für den Umgang mit Cybersecurity-Risiken klar definiert, inklusive strenger Fristen für die Meldung von Sicherheitsvorfällen: 24 Stunden für die Frühwarnung und 72 Stunden für die formale Meldung. Für viele Unternehmen stellt sich nun die Frage: Reicht das bestehende Informationssicherheits-Managementsystem noch aus – oder braucht es mehr?

ISMS und ISO 27001 strukturieren die interne Governance. Trust Center übernehmen die operative Seite: Vendor- und Incident Management nach Artikel 21 und 23.

Sprungmarken:

Artikel 23: Meldung von Sicherheitsvorfällen
Artikel 21: Lieferkettensicherheit

Warum ein ISMS seit NIS2 nicht mehr ausreicht

Viele Organisationen haben heute ein Informationssicherheits-Managementsystem, kurz ISMS: an ISO 27001 orientiert, oft eingebettet in ein GRC-Tool – kombiniert mit Richtlinien, Risikoregister, Kontrollen und jährlichen Audits. Ein ISMS ist wertvoll und eine gute Grundlage, auf der die NIS2-Compliance aufbauen kann.

Die NIS2-Richtlinie bringt jedoch einen Paradigmenwechsel mit sich, der vielen Unternehmen erst schrittweise bewusst wird. Sie verschiebt den Schwerpunkt weg von der Einstellung „wir haben ein ISMS, alles ist gut dokumentiert" hin zu „wir als Unternehmen betreiben nachweisbar Cybersecurity, können auf zeitkritische Events adäquat reagieren und haben unsere Lieferkette jederzeit im Blick" – und zwar unter expliziter Verantwortung der Geschäftsleitung.

Dieser Wandel zeigt sich im Wortlaut der Richtlinie: Sie fordert „appropriate and proportionate technical, operational and organisational measures" (Artikel 21) – also Maßnahmen, die Risiken steuern und die Auswirkungen von Vorfällen minimieren. Das „operational" ist der Punkt, an dem die meisten ISMS-Lösungen schwächeln: Sie ermöglichen gute Dokumentation, funktionieren aber nicht als belastbares Betriebssystem. Was fehlt: die Kommunikation von Sicherheitsvorfällen, das laufende Kontrolle der Lieferantensicherheit und ein jederzeit abrufbarer Wirksamkeitsnachweis – etwa gegenüber Behörden.

In Deutschland ist die NIS2-Richtlinie inzwischen geltendes Recht: Das Umsetzungsgesetz wurde im Bundesgesetzblatt verkündet und trat ohne Übergangsfristen am 6. Dezember 2025 in Kraft. Dies betrifft Registrierungspflichten für rund 30.000 betroffene Unternehmen und konkret benannte Maßnahmenfelder zum Umgang mit Cybersicherheitsrisiken.

Wo ISMS zu NIS2 beiträgt – Governance (NIS2 Artikel 20)

Kurz gefasst: Ein gutes ISMS liefert die von NIS2 geforderte Governance-Struktur zum Umgang mit Cybersecurity-Risiken.

Artikel 20 Punkt 1 macht Governance explizit zur Chefsache -- Geschäftsführung und Management müssen die Maßnahmen nach Artikel 21 genehmigen, deren Umsetzung überwachen – und haften persönlich für Verstöße.

Ein ISMS unterstützt genau dabei. Dazu gehören:

Verantwortlichkeiten, Rollen, Eskalationsstufen
Richtlinien und Prozesse zur Bewertung von Risiken und Risikomaßnahmen
Risikomanagement und Asset-Management
Prüfkataloge und Dokumentationen zur Vorbereitung externer Audits
Sensibilisierungs- und Trainingsprogramme
Interne Reviews und Audits zur Optimierung von Unternehmensprozessen

Artikel 21 listet unter anderem explizit die Anforderungen „(a) policies on risk analysis, (c) business continuity (f) policies and processes to assess the effectiveness of cybersecurity risk-management measures, and (g) cybersecurity training" auf, die sich mit einem ISMS gut umsetzen lassen.

Darüber hinaus stellt NIS2 weitere Anforderungen mit Schnittstellen-Charakter, wie die Prüfung der Lieferkettensicherheit und die Meldung von Sicherheitsvorfällen, die ein ISMS als interne Lösung nicht abbilden kann.

Wo NIS2 über ISMS hinausgeht: Vendor- und Incident-Management (NIS2 Artikel 21 und 23)

Kurz gefasst: NIS2 erwartet mehr als Governance: operatives Management von Lieferkettenrisiken, laufendes Monitoring und die strukturierte Meldung von Sicherheitsvorfällen.

Artikel 23: Incident Management und Reporting ist ein operatives System, kein PDF-Dokument

Die NIS2-Richtlinie verlangt in Artikel 21 Punkt 2 (b) explizit Maßnahmen zum Umgang mit Sicherheitsvorfällen, englisch: Incident Management oder Incident Handling. Dabei führt Artikel 23 ein gestuftes Melderegime ein, inklusive enger Fristen: Nach Punkt 4 (a), (b) und (c) muss die Frühwarnung innerhalb von 24 Stunden erfolgen und eine anschließende ordnungsgemäße Meldung des Vorfalls innerhalb von 72 Stunden nach Bekanntwerden. Zusätzlich können zwischenzeitlich Statusberichte und Updates von der Behörde angefragt werden.

Hier zeigt sich der Unterschied: Unternehmen, die „wir haben einen Incident-Response-Plan" sagen können – und solche, die „wir können Ihnen in 24 Stunden faktenbasiert berichten" liefern. Plötzlich wird die Beantwortung inhaltlicher Fragen dringend und kritisch:

Was ist passiert? Wie gravierend ist der Vorfall?
Welche Auswirkungen kann er haben und was sind unsere Indikatoren dafür?
Wer entscheidet was und mit welcher Evidenz?
Wie synchronisieren sich Security, Legal, PR, Kundenbetreuung und Geschäftsleitung?
Wie wird die Kommunikation dokumentiert und versioniert – und das nachvollziehbar und später auditierbar?

Ein ISMS dokumentiert Vorfälle – meist erst im Nachhinein. NIS2 bewertet aber die operative Fähigkeit, unter Stress reproduzierbar zu reagieren – und das gelingt nur mit einem funktionsfähigen Incident-Management-System.

Artikel 21: Lieferkettensicherheit ist Pflicht

NIS2 schreibt in Artikel 21 Punkt 1 (d) explizit Maßnahmen zur Gewährleistung der Sicherheit der Lieferkette vor (Supply Chain Security). Ausdrücklich genannt werden hier sicherheitsrelevante Aspekte in Beziehungen zu direkten Zulieferern oder Dienstleistungsanbietern.

Viele ISMS ermöglichen punktuelle Lieferantenbewertungen (Vendor Management), etwa beim Onboarding oder einmal jährlich. Doch NIS2 meint etwas anderes: Es geht nicht darum, Lieferantenfragebögen auszufüllen und abzulegen.

Es geht darum, unternehmenskritische Risiken aus Abhängigkeiten beherrschbar zu halten – gerade in einer geopolitischen Realität, die sich laufend verändert. Dies führt automatisch zur Notwendigkeit einer kontinuierlich handhabbaren Schnittstelle zu Dienstleistern und Zulieferern.

Echtes Vendor-Management bedeutet: laufendes Monitoring mit Analytics, unaufwendige Re-Assessments bei Veränderungen, integrierte Nachweise und schnelle Kommunikation, wenn sich die Lage ändert.

3. Der Arbeitsaufwand für Wirksamkeitsnachweis und Auditierfähigkeit wird real (Artikel 21)

Artikel 21 verlangt ausdrücklich interne Richtlinien und Verfahren zur Bewertung der Wirksamkeit der getroffenen Risikomaßnahmen. Parallel baut NIS2 die externe Aufsicht aus: Behörden können Vor-Ort-Prüfungen, Audits und Scans durchführen – und vor allem jederzeit Informationen anfordern.

Nachweise sind nicht mehr „Audit-Dekoration", sondern kontinuierlicher Output der laufenden Arbeit. Konkret braucht es:

Beweisfähige Artefakte wie Systeme, Logs etc. – Dokumente oder reine Behauptungen reichen nicht aus
Artefakte benötigen Meta-Daten wie: Versionsstand, Gültigkeit, Verantwortliche, Änderungsverläufe
Die Fähigkeit, Auditoren jederzeit Kontrollmaßnahmen, aktuelle Lieferantenüberprüfungen, Meldungen von Sicherheitsvorfällen und Resilienz vorzeigen zu können

All dies ist gekoppelt an spürbare Konsequenzen: Für Verstöße gegen Artikel 21 oder 23 sind Bußgelder bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes für wesentliche Unternehmen vorgesehen, sowie bis zu 7 Millionen Euro oder 1,4 Prozent für wichtige Unternehmen.

ISMS und Trust Center: Zwei Seiten derselben Medaille

Die NIS2-Anforderungen lassen sich nicht mit einem einzigen System erfüllen. Governance braucht Struktur – dafür ist ein ISMS unverzichtbar. Doch die Artikel 21 und 23 verlangen darüber hinaus operative Fähigkeiten: schnelle Reaktion auf Vorfälle, laufende Kontrolle der Lieferkette, belastbare Nachweise auf Abruf.

Wer beide Welten verbindet, ist gut aufgestellt: Ein ISMS für die interne Steuerung, ein Trust Center für die externe Kommunikation und Nachweisführung. So wird aus Compliance-Aufwand ein funktionierendes System – und aus Dokumentation echte Resilienz.

NIS2 Artikel 21 und 23: Meldung von Sicherheitsvorfällen und Lieferkettensicherheit brauchen mehr als ein ISMS