NIS-2 als Architekturaufgabe (1): Vom Papier zur Wirksamkeit: Prüfstein technischer Reife

Viele kleine und mittlere Unternehmen (KMU) halten sich beim Management der Informationssicherheit für gut aufgestellt. Sie haben ein Informationssicherheitsmanagementsystem (ISMS) eingeführt, Risikoanalysen durchgeführt und dokumentiert, darauf aufbauend Policies und Richtlinien erstellt, verabschiedet und veröffentlicht sowie Verantwortlichkeiten definiert. Governance-Strukturen stehen, Audits laufen risikoorientiert und geplant, aussagekräftige Reports liegen vor, Maßnahmen sind definiert und unterliegen einem regelmäßigen Monitoring beziehungsweise Follow-up-Audits.

Eine tiefergehende technische Prüfung dürfte in vielen dieser Organisationen erhebliche Lücken aufdecken – nicht in der Angemessenheit der geplanten technisch-organisatorischen Maßnahmen, sondern in deren Wirksamkeit. Zwischen dem Beschluss, Sicherheit ernst zu nehmen, und der technischen Fähigkeit, Sicherheitsvorfälle zu erkennen, nachzuweisen und zu steuern, klafft häufig ein struktureller Graben. Er entscheidet im Ernstfall darüber, ob eine Organisation tatsächlich handlungsfähig ist oder an der Realität scheitert. Diesen Graben macht NIS-2 sichtbar.

Die europäische Richtlinie und ihre deutsche Umsetzung, das „Gesetz zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung“ (NIS-2-RLUG), fordern nicht nur dokumentierte Prozesse, sondern wirksame technische Strukturen. Dieser Beitrag markiert den Übergang von der Governance-Logik der ersten Serie (IT-SICHERHEIT, Ausgaben 4/2025 bis 2/2026) zur technischen Umsetzungstiefe der zweiten.

Was Art. 21 wirklich verlangt

NIS-2 gilt vielerorts lediglich als Governance-Thema. Wer Richtlinien und Managementsysteme aufgesetzt hat, sieht sich auf der sicheren Seite. Die entscheidenden Vorgaben aus Art. 21 der NIS-2-Richtlinie sind allerdings technischer Natur. Governance ist der Einstieg, nicht das Ziel; wer die organisatorische Hälfte abarbeitet, erfüllt die technischen Anforderungen damit noch nicht. Papier ist geduldig.

In Art. 21 der NIS-2-Richtlinie (NIS-2-RL, und entsprechend die Anforderungen des NIS-2-RLUG) werden Maßnahmen aufgelistet, die die betroffenen Einrichtungen ergreifen müssen. Wer diese Liste liest, stellt schnell fest: Ein erheblicher Teil der Anforderungen lässt sich nicht allein durch Richtlinien erfüllen.

• Risikoanalyse und Sicherheitskonzepte (Art. 21 Abs. 2 lit. a NIS-2-RL) setzen eine belastbare Asset-Basis voraus – ohne reale Inventarlage bleibt jede Sicherheitsanalyse angreifbar.
• Systeme zur Angriffserkennung (Art. 21 Abs. 2 lit. b NIS-2-RL) benötigen technische Infrastruktur: strukturiertes Logging, Ereigniskorrelation, Detection-Logik.
• Zugriffssteuerung und Multi-Faktor-Authentifizierung (MFA, Art. 21 Abs. 2 lit. i NIS-2-RL) erfordern ein durchgängiges Identity-Management – nicht nur einen MFA-Rollout für das E-Mail-Konto.

Standortbestimmung in vier Quadranten

Wie weit Governance und Technik in einer Organisation tatsächlich zusammenspielen, lässt sich anhand zweier Dimensionen einordnen. Die Matrix in Abbildung 1 zeigt die zwei entscheidenden Dimensionen: Governance-Reifegrad und technische Umsetzungstiefe. Für mittlere Unternehmen ist der untere rechte Quadrant die häufigste Realität: Die Governance ist gut aufgestellt, die Technik ist fragmentiert. Die Matrix ersetzt keine Detailanalyse, hilft aber bei der Entscheidung, wo überhaupt investiert wird.

Dokumentation ist kein Nachweis

Verbreitet ist die Annahme: Wer eine Richtlinie zur Zugriffssteuerung hat, hat Zugriffssteuerung. Wer einen Incident-Response-Prozess dokumentiert hat, kann auf Vorfälle reagieren. Wer eine Risikoanalyse abgezeichnet hat, kennt seine Angriffsfläche. Diese Annahme ist falsch – und NIS-2 macht das strukturell sichtbar.

Dokumentation beantwortet die Frage, was getan werden soll. Nachweis beantwortet die Frage, was tatsächlich passiert ist. Der Unterschied ist nicht semantisch, sondern operativ: Eine Richtlinie beschreibt den Soll-Zustand, ein Nachweis belegt das Ist – welches System zu welchem Zeitpunkt welchen Zugriff hatte, wann ein Sicherheitsereignis erkannt und innerhalb welcher Frist eskaliert wurde. Organisationen scheitern selten an fehlenden Richtlinien. Sie scheitern daran, dass sie ihre eigene Realität technisch nicht belegen können. Nachweisfähigkeit ist damit kein Nebenprodukt der Dokumentation, sondern ein Architekturziel.

Aus Sicht eines KRITIS-Prüfers entspricht dieser Unterschied der Trennung zwischen Angemessenheit und Wirksamkeit. Die Angemessenheitsprüfung beurteilt, ob die vorgesehenen Maßnahmen geeignet sind, die identifizierten Risiken zu adressieren, und ob sie zu einem Stichtag implementiert waren. Die Wirksamkeitsprüfung untersucht im Anschluss, ob diese Maßnahmen über einen definierten Zeitraum  tatsächlich wie vorgesehen funktioniert haben. Kurz: Angemessenheit fragt nach Konzeption und Einrichtung, Wirksamkeit nach gelebtem Betrieb und belastbarem Beleg.

Wie weit beides auseinanderliegen kann, zeigt der Worst Case: Eine Organisation verfügt über ausführlich dokumentierte Prozesse. Tritt ein Vorfall ein, sind die Logdaten fragmentiert, Zugriffe lassen sich nicht rekonstruieren, Zeitpunkte sind unklar, Verantwortlichkeiten verschwimmen. Ein zentrales Security Information and Event Management (SIEM) fehlt, die Reaktion erfolgt ad hoc. Im Audit nach § 39 BSI-Gesetz (BSIG) lässt sich der Nachweis der dokumentierten ISMS-Prozesse gegenüber der zuständigen Aufsichtsbehörde – im Fall des NIS-2-RLUG das Bundesamt für Sicherheit in der Informationstechnik (BSI) – nicht erbringen.

Im Best Case ist dieselbe Organisation technisch umgesetzt: Logging läuft zentral, normalisiert und korreliert, Vorfälle werden automatisiert eskaliert, Reaktionsschritte dokumentiert. Meldepflichten nach Art. 32 Abs. 1 BSIG – 24-Stunden-Erstmeldung, 72-Stunden-Folgemeldung – lassen sich fristgerecht erfüllen. Nachweisfähigkeit entsteht in diesem Modell nicht zufällig, sondern wird architektonisch erzeugt.

Dieser Graben hat eine kulturelle Wurzel, die Jackwerth, Kutsche und Neumann in der Zeitschrift IT-SICHERHEIT 2/2026 präzise beschreiben: ITler optimieren auf Funktionieren, Prüfer richten ihren Fokus auf Belegbarkeit – beide Logiken sind legitim, kollidieren aber strukturell genau dort, wo Governance-Regelwerke wie NIS-2 greifen. Die Konsequenz für die technische Umsetzung ist eindeutig: Eine Architektur, die nur eine der beiden Kulturen bedient, reicht nicht aus. Wer technisch robust aufgestellt ist, aber Wirksamkeit nicht revisionssicher belegen kann, erfüllt die Anforderungen nicht – und umgekehrt.

Tools ohne Architektur

Die typische Reaktion auf NIS-2-Anforderungen folgt einem vertrauten Muster: Eine Anforderung wird identifiziert, ein Tool beschafft, ein Prozess beschrieben. MFA wird eingeführt, ein SIEM lizenziert, ein Vulnerability-Scanner installiert. Jede Einzelmaßnahme ist für sich sinnvoll – die Wirkung bleibt dennoch begrenzt. Ohne Integration erzeugen solche Bausteine vor allem zusätzliche Komplexität.

Der Grund liegt nicht in den Maßnahmen, sondern in ihrer Isolation. Ein SIEM ohne strukturierte Asset-Basis liefert keine vollständigen Ereignisbilder. Eine Zugriffssteuerung ohne durchgängiges Identity-Management schafft blinde Flecken an den Systemgrenzen. Ein Incident-Response-Prozess ohne automatisierte Protokollierung produziert keine verwertbare Evidenz.

Architekturdenken heißt, diese Abhängigkeiten zu erkennen und zu gestalten: Abhängigkeiten zwischen Systemen sichtbar machen, Datenflüsse zwischen Asset-Management, Detection und Response definieren, Steuerungslogiken implementieren, die im Ernstfall automatisch greifen. NIS-2 beschreibt implizit genau diese Architektur – entlang von fünf technischen Dimensionen:

1. Asset-Transparenz: das Fundament; ohne vollständiges Inventar ist keine andere Maßnahme valide
2. Angriffserkennung: Frühwarnsystem durch SIEM, Logging und Detection Engineering
3. Incident Response: strukturierter Reaktionspfad – vom Alert bis zum Abschlussbericht
4. Identity: Zugriffssteuerung als primärer Sicherheitsanker in hybriden Umgebungen
5. Supply Chain: Lieferkettensicherheit als erweiterter Perimeter – technisch, nicht nur vertraglich

Diese fünf Dimensionen sind keine Option, sondern die technische Antwort auf NIS-2.

Pflichten von Vorstand bis Team

Geschäftsführung und Vorstand. § 38 Abs. 2 BSIG begründet eine persönliche Verantwortung der Leitungsebene. Mit der Genehmigung einer Richtlinie ist sie nicht erfüllt. Die Leitungsebene muss entscheiden, ob die vorhandenen technischen und organisatorischen Maßnahmen nach Stand der Technik geeignet, verhältnismäßig und wirksam sind, um im Fall eines erheblichen Sicherheitsvorfalls die gesetzlichen Meldepflichten fristgerecht zu erfüllen – und falls nicht, wann und mit welchem Budget die nötigen Strukturen aufgebaut werden.

Andernfalls haften die Mitglieder der Leitungsebene gegenüber ihrer Einrichtung für einen schuldhaft verursachten Schaden nach den auf die jeweilige Rechtsform anwendbaren Regeln des Gesellschaftsrechts.

In Gesprächen mit Geschäftsleitungen begegnet KRITIS-Prüfern nicht selten die Haltung: „Woher soll ich das wissen, dafür habe ich meine Fachabteilungen.“ Diese Sichtweise ist überholt. Spätestens mit Inkrafttreten des NIS-2-RLUG liegt die Verantwortung für Informationssicherheit nicht mehr nur operativ bei den Fachabteilungen, sondern ausdrücklich auf Ebene der Unternehmensleitung.

§ 38 Abs. 1 BSIG verpflichtet sie, die Cybersicherheits-Risikomanagementmaßnahmen nach § 30 BSIG nicht nur zu genehmigen, sondern deren Umsetzung aktiv zu überwachen. Eine Delegation im Sinne eines vollständigen Rückzugs ist damit rechtlich nicht zulässig.

§ 38 Abs. 3 BSIG konkretisiert diese persönliche Verantwortung weiter: Mitglieder der Geschäftsleitung müssen regelmäßig an Schulungen teilnehmen, um ein angemessenes Verständnis für IT-Sicherheitsrisiken und Schutzmaßnahmen zu entwickeln. Das Bundesamt für Sicherheit in der Informationstechnik hat mit der Handreichung „Schulung für Geschäftsleitungen“[4] einen inhaltlichen Rahmen vorgelegt.

Ziel ist laut BSI, „Geschäftsleitungen [zu befähigen], das erworbene Wissen auf konkrete Situationen zu übertragen und die eigene Entscheidungs- und Beurteilungskompetenz realitätsnah zu erproben. Besonders wirksam sind Beispiele, die typische Bedrohungslagen, Schwachstellen oder Entscheidungssituationen im eigenen Sektor oder der konkreten Einrichtung abbilden.“[4]

Wechselwirkungen zwischen Risiken, Maßnahmen und Auswirkungen sollen nachvollziehbar werden – ebenso die Fähigkeit, Risiken unternehmerisch einzuordnen und auf Basis begrenzter Informationen tragfähige Entscheidungen zu treffen. Cybersicherheit ist damit kein rein operatives Thema mehr, sondern Bestandteil verantwortungsvoller Unternehmensführung.

CISO und IT-Leitung. Der Reifegrad bemisst sich heute an der technischen Umsetzungstiefe, nicht an der Zahl vorhandener Richtlinien. Der CISO muss entscheiden, welche der fünf technischen Dimensionen das größte Defizit aufweist – und ob die Organisation überhaupt in der Lage ist, ihre eigene Sicherheitslage technisch zu bewerten. Asset-Transparenz ist dabei in der Regel der notwendige erste Schritt: Ohne vollständiges Wissen über das eigene Inventar bleibt jede Maßnahme eine Insellösung – wirksame Sicherheit aus einem Guss ist so nicht erreichbar.

Technische Umsetzungsteams. Einzelne Tools zu betreiben, ist nicht dasselbe wie eine funktionierende Sicherheitsarchitektur aufzubauen. Umsetzungsteams müssen prüfen, ob die aktuellen Systemintegrationen zwischen Asset-Management, SIEM, Identity-Systemen und Incident-Response-Tools ausreichen, um eine lückenlose Protokollierung und automatisierte Eskalationspfade zu gewährleisten. Fehlende Integrationen sind keine Konfigurationslücken, sondern Architekturfehler.

Praxis: ISMS Grün, Technik Rot

Ein mittelständisches Unternehmen mit rund 600 Mitarbeitern im produzierenden Gewerbe – nach § 28 BSIG als wichtige Einrichtung eingestuft – verfügte nach Abschluss eines ISMS-Projekts über einen dokumentierten Governance-Reifegrad, der für ein erstes Audit ausreichend erschien. Die technische Realität sah anders aus:

IT- und OT-Netz (Operational Technology, OT) waren nicht inventarisiert, ein zentrales Logging fehlte, Zugriffsrechte wurden manuell verwaltet. Eingesetzt wurde eine kombinierte 2D-Matrix mit tabellarischer Detailschicht: Achsen Governance-Dimension und technische Umsetzungstiefe, ergänzt um sechs Anforderungskategorien
nach Art. 21 NIS-2-RL und eine Ampelbewertung je Dimension.

Datengrundlage waren ein Selbst-Assessment-Fragebogen und ein ergänzender technischer Scan. Auf einer Seite wurde damit für die Geschäftsführung sichtbar, was Auditberichte nicht abbildeten: Governanceseitig grün, technisch rot – systematisch und kategorienübergreifend.

Entscheidend war nicht die Matrix selbst, sondern dass sie Governance und technische Realität erstmals in ein gemeinsames Bild brachte. Die Investitionsentscheidung für Asset-Transparenz und SIEM-Aufbau fiel nicht auf Basis eines technischen Konzepts, sondern auf Basis eines Instruments, das den Abstand zwischen Anspruch und Wirklichkeit quantifizierbar machte.

Fazit und Ausblick

NIS-2 verschiebt den Maßstab. Nicht die Existenz von Richtlinien zählt, sondern die Fähigkeit, Sicherheitslage und Vorfälle technisch zu belegen. Governance liefert dafür den Rahmen, die Wirkung entsteht in der Architektur darunter.

Einzelne Werkzeuge – ein SIEM hier, ein MFA-Rollout dort – reichen nicht aus. Erst wenn Asset-Management, Detection, Identity und Incident Response ineinandergreifen, entsteht aus Aktivität auch Wirksamkeit. Die Reifegradmatrix hilft, den Abstand zwischen Anspruch und Realität sichtbar zu machen und Investitionen dort anzusetzen, wo der Hebel am größten ist.

Der nüchterne erste Schritt heißt Transparenz: ein vollständiges, aktuelles Asset-Inventar. Ohne diese Basis bleibt jede weitere Maßnahme Stückwerk – von der Risikoanalyse über die Angriffserkennung bis zur Zugriffssteuerung.

Der nächste Beitrag widmet sich dem technischen Fundament: Asset-Transparenz. Warum die reale Angriffsfläche größer ist als jede Configuration Management Database (CMDB), wie eine dynamische Systemübersicht für IT, OT und Cloud entsteht – und warum ohne sie keine weitere Sicherheitsmaßnahme trägt.

Referenzen

[1] Europäisches Parlament und Rat der EU (2022): Richtlinie (EU) 2022/2555 über Maßnahmen für ein hohes gemeinsames
Cybersicherheitsniveau in der Union (NIS-2-Richtlinie). Amtsblatt der EU, L 333, 27.12.2022.
[2] Deutscher Bundestag (2025): Gesetz zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung (NIS2-RLUG) – einschließlich Änderung des Zweiten Gesetzes zur Erhöhung der Sicherheit informationstechnischer Systeme (BSI-Gesetz).
[3] Bundesamt für Sicherheit in der Informationstechnik – BSI (2023): BSI-Standard 200-2: IT-Grundschutz-Methodik. Bonn: BSI.
[4] Bundesamt für Sicherheit in der Informationstechnik – BSI (2026): Schulung für Geschäftsleitungen. Handreichung zur Schulungspflicht für Geschäftsleitungen wichtiger und besonders wichtiger Einrichtungen nach dem BSI-Gesetz sowie für freiwillige Schulungen von Geschäftsleitungen nichtregulierter Unternehmen, Version 1.0, 17.04.2026. Bonn: BSI.
[5] International Organization for Standardization (2022): ISO/IEC 27001:2022 – Informationssicherheits-Managementsysteme. Genf: ISO.
[6] ENISA – European Union Agency for Cybersecurity (2023): NIS2 Implementation – Technical Guidance for Operators of Essential and Important Services. Athen: ENISA.