Prüfstein technischer Reife: Warum ein grünes ISMS unter NIS-2 nicht reicht

Ein ISMS, das im Reifegrad-Assessment grün steht. Eine Zertifizierung, die seit Jahren Bestand hat. Und trotzdem: Wenn ein IT-Sicherheitsvorfall eintritt, lässt sich nicht belegen, wann er erkannt wurde, wer davon wusste und welche technische Maßnahme ihn hätte verhindern sollen. Genau diese Konstellation – Managementsystem in Ordnung, Technik darunter nicht nachweisbar – ist der Ausgangspunkt, den die NIS-2-Umsetzung für viele Unternehmen sichtbar macht.

Der Maßstab hat sich verschoben

Mit § 30 BSIG müssen besonders wichtige und wichtige Einrichtungen (Einordnung nach § 28 BSIG) geeignete, verhältnismäßige und wirksame Risikomanagementmaßnahmen treffen – und diese dokumentieren. Das Wort „wirksam” ist der entscheidende Unterschied zu einem reinen Dokumentationsregime: Ein Managementsystem, das beschreibt, was getan werden soll, erfüllt die Anforderung noch nicht. Verlangt wird der Nachweis, dass eine Maßnahme tatsächlich greift.

Auf Ebene der NIS-2-Richtlinie selbst zeigt sich dasselbe Muster in Art. 21 Abs. 2. Buchstabe a verlangt Risikoanalyse und Sicherheit für Informationssysteme, Buchstabe b die Bewältigung von Sicherheitsvorfällen. Wichtig für die Einordnung: Art. 21 Abs. 2 lit. b schreibt keine bestimmte Detektionstechnologie vor – die Lesart, Erkennung sei dort stillschweigend vorausgesetzt, trägt juristisch nicht. Was der Artikel stattdessen verlangt, ist Bewältigungsfähigkeit, und die lässt sich nur zeigen, wenn technische Prozesse tatsächlich laufen. Buchstabe i schließlich verlangt Konzepte für Personalsicherheit, Zugriffskontrolle und das Management von Anlagen – und deckt damit Asset-Management ausdrücklich mit ab. Diese Stelle ist die normative Brücke zwischen einem sauberen Inventar und einem funktionierenden Identitätskonzept, zwei Themen, die in der Praxis oft getrennt betrachtet werden, aber technisch zusammenhängen.

Die Reifegradmatrix: zwei Achsen, vier Quadranten

Um die Lücke greifbar zu machen, lohnt sich eine einfache Matrix: Governance-Reifegrad auf der einen, technische Umsetzungstiefe auf der anderen Achse. Die meisten Unternehmen verorten sich selbst oben rechts – Richtlinien vorhanden, Technik im Griff. In der Praxis liegen viele im Quadranten oben links: Governance ausgereift, Technik dahinter unvollständig. Ein mittelständisches Unternehmen mit rund 600 Mitarbeitenden, das ein zertifiziertes ISMS betreibt, aber weder ein vollständiges Asset-Inventar noch eine belastbare Angriffserkennung vorweisen kann, ist kein Ausnahmefall, sondern ein wiederkehrendes Muster.

Der Grund dafür ist selten Nachlässigkeit. Governance-Arbeit erzeugt sichtbare Artefakte – Richtlinien, Protokolle, Freigaben – und lässt sich deshalb gut prüfen und gut managen. Technische Umsetzungstiefe erzeugt dagegen erst dann ein sichtbares Ergebnis, wenn sie durchgehend betrieben wird: ein Inventar, das nicht laufend aktualisiert wird, verliert seinen Wert binnen Wochen. Diese Betriebsanforderung wird in Zertifizierungsprojekten oft unterschätzt.

Dokumentation ist nicht Nachweis

Der zweite Unterschied, den NIS-2 schärft, ist die Trennung zwischen Angemessenheit und Wirksamkeit. Eine Richtlinie zur Zugriffskontrolle ist angemessen, wenn sie inhaltlich korrekt ist. Sie ist wirksam, wenn sich zu jedem Zeitpunkt zeigen lässt, dass sie tatsächlich durchgesetzt wird. § 39 BSIG verlangt genau diese zweite Ebene: Nachweise gegenüber dem Bundesamt für Sicherheit in der Informationstechnik, nicht nur die Existenz einer Regelung.

Für die Leitungsebene hat das eine unmittelbare Konsequenz. § 38 BSIG bündelt Umsetzungs- und Überwachungsverantwortung (Abs. 1), Haftung (Abs. 2) und Schulungspflicht (Abs. 3) an einer Stelle. Operative Aufgaben lassen sich delegieren – an die IT-Leitung, an einen CISO, an externe Partner. Die gesetzliche Leitungsverantwortung bleibt davon unberührt. Wer als Geschäftsführung oder Vorstand einen Meldeprozess freigibt, ohne die tatsächliche Erkennungsdauer im eigenen Haus zu kennen, geht ein Risiko ein, das sich nicht wegdelegieren lässt.

Fünf Dimensionen als Ordnungsrahmen

Um aus dieser Lücke eine bearbeitbare Aufgabe zu machen, lässt sich die technische Seite von NIS-2 in fünf Dimensionen gliedern: Asset-Transparenz als Fundament, Angriffserkennung, Incident Response, Identity (IAM und PAM, Zero Trust) und Supply Chain. Governance ist dabei bewusst keine sechste Dimension, sondern der Rahmen, in dem die fünf technischen Ebenen erst wirksam werden. Jede Dimension baut auf der vorherigen auf: Ohne belastbares Inventar lässt sich kein Alarm sinnvoll priorisieren, ohne priorisierbare Alarme keine Meldefrist verlässlich einhalten.

Was das für PRISM-Nutzer bedeutet

Genau an dieser Schnittstelle – Governance-Nachweis und technische Evidenz in einem System – setzt PRISM ISO an. Die Norm NIS 2 ist als eigenständiges Framework hinterlegt, mit Anforderungen und automatisch abgeleiteten Maßnahmen. Über die Multi-Framework-Crosswalk-Engine lassen sich Controls, die bereits für ISO 27001 oder C5 erfüllt sind, direkt auf NIS-2-Anforderungen abbilden, statt sie ein zweites Mal zu bearbeiten. Die revisionssichere Änderungshistorie protokolliert jede Anpassung an Controls, Richtlinien und Maßnahmen unveränderbar – das ist die technische Grundlage für den in § 39 BSIG geforderten Nachweis, nicht nur für dessen Dokumentation. Und das Asset-Management-Modul verknüpft technische Assets direkt mit Controls und Risiken, sodass die in Art. 21 Abs. 2 lit. i NIS-2-RL verlangte Verbindung aus Zugriffskontrolle und Anlagenmanagement kein separates Excel-Projekt bleibt, sondern Teil desselben Systems ist, in dem auch das ISMS geführt wird.

Wenn Sie wissen wollen, wo Ihr Unternehmen in dieser Matrix tatsächlich steht – nicht nur auf dem Papier des ISMS, sondern in der technischen Tiefe darunter –, ist ein strukturiertes Gespräch der schnellste Weg dahin.

Nächster Schritt: Lassen Sie Ihren NIS-2-Status im Erstgespräch einordnen oder verschaffen Sie sich einen Überblick über die Anforderungen unter /nis2.