NIS2 über ein ISMS umsetzen: ISO 27001 und IT-Grundschutz als Vehikel

Problem in der Praxis

In der Praxis treten zwei gegensätzliche Fehlannahmen auf. Die erste lautet: NIS2 ist etwas Neues und braucht eine eigene Struktur. Es entstehen ein separates NIS2-Projekt, eigene Register, eigene Richtlinien und ein paralleler Nachweisapparat neben dem ISMS. Das Ergebnis sind doppelte Pflege, widersprüchliche Aussagen und ein hoher Aufwand ohne Sicherheitsgewinn.

Die zweite Fehlannahme ist das Gegenteil: Ein vorhandenes ISO/IEC-27001-Zertifikat oder ein IT-Grundschutz-Testat decke NIS2 bereits vollständig ab. Diese Annahme ist gefährlich, weil ein Zertifikat die Konformität eines ISMS mit einer Norm bestätigt, nicht die Erfüllung einer gesetzlichen Pflicht. Aufsicht und Sanktionierung nach NIS2 richten sich nach dem Recht, nicht nach dem Zertifikat. Wesentliche Einrichtungen unterliegen einer proaktiven Aufsicht; ein Zertifikat ersetzt diese Prüfung nicht.

Beide Fehler haben dieselbe Wurzel: Es fehlt eine saubere Abbildung der NIS2-Anforderungen auf das vorhandene Steuerungsmodell, inklusive einer ehrlichen Aussage darüber, was das ISMS abdeckt und was nicht.

CISO-Einordnung

Der Kern der Umsetzung ist eine Abbildung (Mapping) der Artikel-21-Bereiche auf die Controls des gewählten ISMS. Aus Managementsicht lassen sich die Bereiche in drei Kategorien ordnen, ohne ihren Pflichtcharakter zu relativieren:

• Bereiche, die ein ISMS strukturell bereits trägt: Risikoanalyse und Informationssicherheit, Bewältigung von Sicherheitsvorfällen, Aufrechterhaltung des Betriebs mit Backup- und Krisenmanagement, Wirksamkeitsbewertung, Cyberhygiene und Schulungen, Kryptografie, Personalsicherheit, Zugriffskontrolle und Asset-Management. Sie entsprechen weitgehend dem, was ein etabliertes ISMS ohnehin betreibt.
• Bereiche, die im ISMS vorhanden, für NIS2 aber meist zu vertiefen sind: Sicherheit der Lieferkette, Sicherheit bei Erwerb, Entwicklung und Wartung inklusive Schwachstellenmanagement sowie Multi-Faktor-Authentifizierung und gesicherte Kommunikation einschließlich Notfallkommunikation. Hier reicht ein generisches Control oft nicht; die NIS2-Erwartung ist konkreter.
• Pflichten, die ein ISMS nicht automatisch erfüllt: die dreistufigen Meldepflichten nach Artikel 23 mit Frühwarnung binnen 24 Stunden, Vorfallmeldung binnen 72 Stunden und Abschlussbericht binnen eines Monats nach der Vorfallmeldung, die Verantwortungspflichten der Leitungsorgane nach Artikel 20 sowie Registrierungs- und Nachweispflichten nach nationalem Recht.

Diese Dreiteilung ist eine Managementhilfe, kein normatives Mapping und keine erschöpfende Maßnahmenliste. Sie zeigt, wo das ISMS trägt, wo es zu schärfen ist und wo NIS2 über das ISMS hinausreicht.

Umsetzungsperspektive

Die Wahl des Vehikels hängt vom Kontext ab. ISO/IEC 27001 ist risikobasiert, international anerkannt und schlank in der Struktur; sie eignet sich, wenn internationale Kunden, Konzernvorgaben oder Zertifizierungsziele relevant sind. Der IT-Grundschutz des BSI ist methodisch ausführlicher und stärker vorstrukturiert; er eignet sich bei hohem Detaillierungsgrad, Behördennähe oder nationalem Bezug. Beide sind valide Wege; maßgeblich ist nicht die Norm, sondern ein betriebenes Steuerungsmodell.

Der eigentliche Hebel ist die Doppelnutzung. Ein einmal betriebenes ISMS kann mehrere Anforderungen gleichzeitig bedienen: NIS2 als Rechtspflicht, vertragliche Kundenanforderungen, Zertifizierungsziele und weitere regulatorische Erwartungen. Nachweise wie Risikobewertungen, interne Audits, Wiederanlauftests, Schwachstellen- und Patch-Kennzahlen oder Awareness-Nachweise entstehen einmal im Regelbetrieb und werden mehrfach verwendet. So wird das ISMS zur einzigen Quelle der Wahrheit statt zur Quelle widersprüchlicher Parallelregister.

Zwei Punkte sind dabei verbindlich. Erstens der Scope: Der Geltungsbereich des ISMS muss die für NIS2 relevanten Netz- und Informationssysteme abdecken; ein engerer Scope trägt die Umsetzung nicht. Zweitens die Ergänzung um die rechtlichen Pflichten: Der Incident-Prozess ist um den regulatorischen Meldekanal mit den Fristen aus Artikel 23 zu erweitern, und die Managementbewertung ist mit den Billigungs- und Überwachungspflichten der Leitungsorgane nach Artikel 20 zu verzahnen.

Bei verbindlichen Details gilt: Die Richtlinie (EU) 2022/2555 setzt den Rahmen, die nationale Umsetzung konkretisiert ihn. In Deutschland geschieht das über das NIS2-Umsetzungsgesetz, dessen Stand vor verbindlichen Festlegungen zu prüfen ist. Mitgliedstaaten können zudem die Nutzung bestimmter Normen oder zertifizierter Produkte verlangen; ob und welche, ergibt sich aus dem nationalen Recht.

Typische Fehler

1. NIS2 wird als separates Projekt neben dem ISMS aufgebaut, statt die Anforderungen auf das vorhandene Steuerungsmodell abzubilden.
2. Ein ISO/IEC-27001-Zertifikat oder IT-Grundschutz-Testat wird mit NIS2-Compliance gleichgesetzt.
3. Der ISMS-Scope deckt die NIS2-relevanten Systeme nicht vollständig ab, das Mapping bleibt dadurch lückenhaft.
4. Die rechtlichen Pflichten aus Artikel 23 (Meldefristen) und Artikel 20 (Governance, Haftung) werden nicht in das ISMS integriert.
5. Die Norm wird vor der Steuerung gewählt: Es entsteht ein Normprojekt statt eines betriebenen Regelkreises mit Wirksamkeitsnachweis.

Risiken und Trade-offs

Der erste Trade-off liegt zwischen Effizienz und Vollständigkeit. Die Doppelnutzung eines ISMS spart erheblichen Aufwand, verleitet aber dazu, NIS2-spezifische Pflichten zu übersehen, die im Standard-ISMS nicht vorgesehen sind. Wer Effizienz überbetont, riskiert eine Scheinabdeckung; wer jede Pflicht separat abbildet, baut teure Doppelstrukturen.

Ein zweiter Trade-off betrifft die Normwahl. ISO/IEC 27001 ist flexibel, verlangt aber eigene Tiefenentscheidungen; der IT-Grundschutz nimmt diese Entscheidungen teilweise ab, kann aber für kleinere Einrichtungen schwergewichtig wirken. Ein dritter Punkt ist die Lieferkette: Sie ist NIS2-Pflichtbereich und ISMS-Thema zugleich, ihre Durchsetzbarkeit gegenüber Anbietern bleibt jedoch begrenzt und ist über Verträge, Anbieter-Risikobewertung und Eskalationswege abzuwägen.

Schließlich besteht das Risiko, nationale Besonderheiten als unionsweit fix anzunehmen. Schwellen, Fristenauslegung, Registrierungs- und Nachweispflichten ergeben sich aus der nationalen Umsetzung und können abweichen.

Entscheidungspunkte

• Welches Vehikel passt zum Kontext: ISO/IEC 27001, IT-Grundschutz oder eine kombinierte Nutzung?
• Deckt der ISMS-Scope alle NIS2-relevanten Netz- und Informationssysteme ab, und wie wird eine Lücke geschlossen?
• Wie werden die Artikel-21-Bereiche konkret auf vorhandene Controls abgebildet, und welche Bereiche sind zu vertiefen?
• Wie werden die Meldepflichten nach Artikel 23 und die Governance-Pflichten nach Artikel 20 in das ISMS integriert?
• Welche nationalen Konkretisierungen sind verbindlich, bevor Schwellen, Fristen und Registrierung festgelegt werden?

Praktische Empfehlungen

1. Nutzen Sie das vorhandene ISMS als Vehikel und bilden Sie die NIS2-Anforderungen darauf ab, statt eine separate NIS2-Struktur aufzubauen.
2. Erstellen Sie ein Mapping der Artikel-21-Bereiche auf Ihre Controls und markieren Sie je Bereich, ob er abgedeckt, zu vertiefen oder außerhalb des ISMS liegt.
3. Prüfen Sie zuerst den Scope: Erweitern Sie den ISMS-Geltungsbereich, bis er die NIS2-relevanten Systeme vollständig erfasst.
4. Ergänzen Sie das ISMS bewusst um die rechtlichen Pflichten: den Meldekanal mit den Fristen aus Artikel 23 und die Verzahnung mit den Leitungsorganen nach Artikel 20.
5. Behandeln Sie das Zertifikat als Nebenprodukt, nicht als Ziel, und prüfen Sie verbindliche Details gegen die nationale Umsetzung.

Relevante Normreferenzen

• Richtlinie (EU) 2022/2555 (NIS2), insbesondere Artikel 21 (Risikomanagementmaßnahmen), Artikel 20 (Governance) und Artikel 23 (Meldepflichten): rechtsverbindlicher Rahmen, EU-Recht, mit Quellenangabe zitierbar.
• Nationale Umsetzung, in Deutschland das NIS2-Umsetzungsgesetz: maßgeblich für verbindliche Details, Schwellen, Fristen und Registrierung.
• ISO/IEC 27001: Referenz für ein ISMS als Vehikel der NIS2-Umsetzung; die aktuelle Ausgabe löst die Vorgängerfassung ab.
• IT-Grundschutz (BSI): alternative methodische Referenz für die Umsetzung über ein ISMS.