Vadi Fuoco – shutterstock.com
NIS2 ist symbolisch für das Kernproblem europäischer Richtlinien und Verordnungen: Sie erzeugen unnötigen Papierkrieg und entfalten ihre Wirkung zu selten. Sei es das Lieferkettengesetz, die DSGVO‑Folgenabschätzungen oder das IT‑Sicherheitsgesetz – sie haben gemeinsam, dass Unternehmen gigantische Dokumentationsberge produzieren müssen. Diese erhöhen weder die tatsächliche Sicherheit, noch sind sie realistisch prüfbar.
Compliant ist in der Regel derjenige, der eine umfangreiche Dokumentation aller Prozesse und regelmäßigen Prüfungen vorlegen kann. Diese sind zumeist so ausführlich, dass ihre Erstellung bereits nahezu unzumutbare Aufwände verursacht und ihre manuelle Prüfung praktisch unmöglich wird. Selbst wenn man sie prüfen würde, wären die Informationen nicht präzise genug, um echte Sicherheit zu belegen.
Sicherheit gehört in die Planung
In vielen Unternehmen entsteht dadurch eine absurde Praxis: Das technische Team baut funktionierende Infrastruktur und losgelöst davon schreibt ein Compliance‑Beauftragter im Nachhinein eine seitenlange Rechtfertigung, warum die Lösung angeblich sicher sei.
Das ist ungefähr so, als würde Volkswagen ein Auto bauen und erst danach verfasst jemand 40 Seiten darüber, warum dieses Auto den Sicherheitsstandards entsprechen sollte. In der realen Industrie läuft es natürlich anders: Sicherheitsanforderungen fließen bereits in die Planung ein, technologische Mindeststandards sind definiert, und Qualitätsprozesse überwachen die Umsetzung automatisch. Compliance ergibt sich aus Technik – nicht aus Leitz‑Ordnern.
In anderen Bereichen, wie der Steuerprüfung, hat man dieses Problem längst erkannt und die Automatisierung relevanter Prozesse gesetzlich vorgeschrieben (Stichwort: elektronische Registrierkasse, revisionssichere Buchhaltungssoftware). Das erspart ehrlichen Unternehmern nicht nur enorme manuelle Arbeit, sondern reduziert vor allem das Missbrauchsrisiko.
Leider werden in Deutschland nur wenige Dinge so konsequent umgesetzt wie das Eintreiben unserer Steuern.
Anders als beim Thema Steuerlast sollten Unternehmen jedoch ein intrinsisches Interesse daran haben, ihre IT‑Sicherheit korrekt zu implementieren. Das Bußgeld für einen NIS2‑Verstoß kann bis zu zehn Millionen Euro oder zwei Prozent des weltweiten Jahresumsatzes betragen. Die wirtschaftlichen Schäden erfolgreicher Cyberangriffe sind oft existenzbedrohend und summieren sich bereits heute auf dreistellige Milliardenbeträge pro Jahr.
Auch wenn es nicht ausdrücklich gesetzlich vorgeschrieben ist, gibt es mittlerweile – nicht zuletzt durch AI‑gestützte Werkzeuge – die Möglichkeit, Sicherheitsprozesse und ihre vollständige Dokumentation so weit zu automatisieren, dass sich Security, Compliance und Auditierbarkeit in einem einzigen technischen Prozess vereinen lassen. Das spart nicht nur Ressourcen, sondern erhöht auch die tatsächliche Sicherheit.
Wie dies im Detail aussehen kann, zeigt ein Beispiel einer SaaS‑Applikation in der Cloud.
IT im Wandel: von Textdokumenten zu deklarativer Technik
NIS2 verlangt im Kern drei Dinge: konkrete Sicherheitsmaßnahmen, Prozesse und Richtlinien zur Steuerung dieser Maßnahmen sowie belastbare Nachweise, dass sie im Alltag funktionieren. Die Prozessdokumentation – also Policies, Zuständigkeiten und Abläufe – ist für die meisten größeren Unternehmen nichts grundsätzlich Neues. ISO‑27001‑basierte Informationssicherheits-Managementsysteme (ISMS), HR‑Prozesse und Management‑Handbücher existieren oft seit Jahren. Entscheidend für NIS2 sind deshalb vor allem zwei Ebenen: die technischen Maßnahmen und die Evidenz, dass sie wirksam sind.
Genau hier zeigt sich der Umbruch der letzten Jahre. Früher wurden Konzepte, Maßnahmen und Spezifikationen von Software‑ und IT‑Infrastrukturen überwiegend in Textform dokumentiert. Programmcode war zu komplex, Konfigurationen lagen verstreut in Dateien, Ticketsystemen oder im Kopf einzelner Administratoren. Im Nachgang hat man Dokumente geschrieben – häufig durch fachfremde Kollegen. Dieses Vorgehen war vor allem aus zwei Gründen problematisch: Es skaliert nicht in wachsenden, verteilten Umgebungen, und es passt nicht zu dem Ziel, technische Prozesse konsequent zu automatisieren.
In modernen Systemen setzt man deshalb auf Verfahren wie Test‑ oder Behaviour‑driven Development und Infrastructure as Code (IaC), die – konsequent angewendet – textuelle Dokumentation weitgehend ersetzen. Die von NIS2 geforderten technischen Spezifikationen können direkt auf diese Artefakte referenzieren: IaC‑Definitionen legen Verschlüsselung, Netzsegmente oder Backup‑Szenarien fest, und CI/CD‑Pipelines spielen sie revisionssicher in die Produktion aus.
Änderungen sind damit nicht nur technisch exakt beschrieben, sondern über Commits und Deployments auch zeitlich nachvollziehbar. Die Evidenz für Aspekte, die sich nicht vollständig deklarativ fassen lassen – etwa die Sicherheit der Software‑Supply‑Chain oder des Anwendungscodes – kann über Security‑Checks in der CI/CD‑Pipeline und eine laufende Bewertung durch SIEM‑ und CNAPP‑Systeme abgebildet werden.
Wie das konkret aussehen kann, zeigt sich besonders deutlich in folgenden Bereichen:
Identity & Access Management,
Schwachstellenmanagement in der Software‑Supply‑Chain sowie im Monitoring,
Incident Handling
und Meldepflichten.
Identity & Access Management: Policies as Code statt Rollen‑Excel
Identity & Access Management ist eine der zentralen Säulen von NIS2. Gefordert sind nicht nur „irgendwelche“ Rollen, sondern ein Zugriffskonzept nach Need‑to‑know, Least Privilege und Separation of Duties. In der Praxis lässt sich das gut in drei Ebenen denken: bewusste Vergabe von Rechten, ein realistischer Lebenszyklus dieser Rechte – und eine Architektur, die Lateral Movement so weit wie möglich verhindert.
Statt Berechtigungen in Excel, Admin‑UIs und verstreuten Wikis zu pflegen, werden Rollen und Zugriffsrechte als Policies as Code, beziehungsweise Infrastructure as Code definiert – etwa als Terraform‑Module oder JSON/YAML‑Policies in einem Git‑Repository. Alle Änderungen laufen ausschließlich über Merge Requests und werden über eine CI/CD‑Pipeline ausgerollt.
Damit ist klar nachvollziehbar, wer welche Rechte geändert hat, wer das freigegeben hat und wann die Änderung produktiv gegangen ist. Die Dokumentations‑ und Nachweispflichten von NIS2 ergeben sich so direkt aus Git‑History und Pipeline‑Logs, ohne dass jemand zusätzliche Word‑Konzepte schreiben muss.
Ein Rollenmodell allein ist noch kein Least Privilege. NIS2 verlangt, dass Rechte regelmäßig überprüft und überflüssige Berechtigungen entfernt werden. In Cloud‑Umgebungen mit hunderten Accounts, Services, Pods und Functions ist das manuell kaum noch handhabbar.
Hier setzen Cloud‑Identity‑Entitlement‑Management‑Systeme (CIEM) an. Sie lesen alle effektiven Berechtigungen aus der Umgebung aus, korrelieren sie mit Audit‑Logs und zeigen, welche Rechte tatsächlich genutzt werden und wo Überprivilegierung besteht. Besonders bei Non‑Human Identities (Service‑Accounts, Workloads) ist das entscheidend, weil genau hier oft sehr breite Rechte vergeben werden, die Angreifern später als Sprungbrett dienen.
Einige Start-Ups bieten mittlerweile sogar CIEM-Systeme, welche mit Hilfe von AI automatisch IAM-Policies für die entsprechenden Rollen generieren können.
Schwachstellenmanagement & Software‑Supply‑Chain: SBOM statt Scanner‑PDF
Der zweite Block, den NIS2 und die neue Durchführungsverordnung 2024/2690 für digitale Dienste scharf stellen, ist das Schwachstellenmanagement im eigenen Code und in der Lieferkette. Gefordert sind regelmäßige Vulnerability‑Scans, Verfahren zur Bewertung und Priorisierung, fristgerechte Behandlung kritischer Schwachstellen sowie ein geregeltes Vulnerability‑Handling und – wo nötig – Coordinated Vulnerability Disclosure. Für Cloud‑ und SaaS‑Provider kommen Supply‑Chain‑Pflichten hinzu, etwa gegenüber Cloud‑, CI/CD‑ und Registry‑Dienstleistern.
Im klassischen Schwachstellenmanagement werden SCA‑, SAST‑ und DAST‑Scanner einfach „über alles drüber geworfen“. Das Ergebnis sind endlose Listen an Findings, von denen ein Großteil Fehlalarme oder für das konkrete System nicht relevant ist. Diese Daten landen dann in Excel‑Tabellen oder einer Schwachstellendatenbank, in der Teams versuchen, Prioritäten zu vergeben. Gerade bei Zero‑Day‑Lücken führt das zu hektischen Ad‑hoc‑Analysen: Welche unserer Komponenten sind betroffen? Ist die Schwachstelle in unserer Architektur überhaupt ausnutzbar? Was tun wir, solange es noch keinen Patch gibt?
Der moderne Ansatz ist, alle DevSecOps‑Findings in einem zentralen System zu konsolidieren. Dort fließen Ergebnisse aus SCA, SAST und DAST zusammen, werden mit Kontext aus Software Bill of Materials (SBOMs), Architektur und Exponiertheit angereichert und mit Hilfe von AI vorgefiltert. False Positives lassen sich so drastisch reduzieren, und übrig bleibt eine deutlich kleinere Menge an tatsächlich relevanten Schwachstellen, inklusive einer Einschätzung, wie kritisch sie im konkreten Setup sind.
Diese verdichteten Findings können direkt in Ticketsysteme und ins SOC weitergegeben werden, wo sie wie Incidents behandelt, nachverfolgt und für NIS2‑Reports ausgewertet werden. Aus einem wuchernden Scanner‑Output wird so ein steuerbarer Prozess, der sowohl die gesetzlichen Anforderungen als auch die Realität im Betrieb abbildet.
Monitoring, Incident‑Handling und Meldestelle
Der dritte Bereich, in dem NIS2 schnell zum Papiertiger wird, ist die Kombination aus Monitoring, Incident Response und den neuen Meldepflichten. Die Richtlinie gibt klare Deadlines vor: Frühwarnung innerhalb von 24 Stunden, eine strukturierte Meldung nach 72 Stunden, ein Abschlussbericht nach spätestens einem Monat. Viele Organisationen reagieren darauf, indem sie neue Templates, Excel‑Listen und Meldehandbücher bauen – oft weitgehend losgelöst vom bestehenden SOC.
Im Ernstfall bedeutet das: Das SOC bekämpft den Vorfall, während parallel eine „NIS2‑Taskforce“ versucht, Informationen aus Tickets, Mails und Ad‑hoc‑Chats so aufzubereiten, dass sie in ein Formular passen. Die Folge sind doppelte Arbeit, Informationsverluste und Berichte, die zwar Seiten füllen, aber wenig darüber sagen, wie gut Detection und Response tatsächlich funktionieren.
In einer Cloud‑SaaS‑Umgebung bietet sich ein anderer Weg an: Statt NIS2‑Reporting als eigenes Dokumentenprojekt zu verstehen, wird ein modernes DevSecOps‑basiertes SOC aufgebaut, so dass alle sicherheitsrelevanten Signale von vornherein an einem Ort zusammenlaufen: Cloud‑Infrastruktur, CI/CD‑Pipelines, Anwendungen, IdP und IAM.
Die Regeln, nach denen diese Daten korreliert, angereichert und in Incidents überführt werden, sind als Code definiert und versioniert. T Detection‑Logik (Threat Detection and Response), Schwellenwerte und Playbooks liegen im Repository und werden wie Anwendungscode über Pipelines ausgerollt. Große Teile der klassischen SOC‑Arbeit lassen sich damit automatisieren: Aus Roh‑Logs werden konsistente Incidents mit Kontext, ohne dass jemand manuell Textbausteine zusammenkopieren muss. CNAPP (Cloud-Native Application Protection Platform ) und ähnliche Plattformen übernehmen gleichzeitig Speicherung und Archivierung der Daten, sodass der Nachweis der Überwachungstätigkeit im System mitläuft, statt in gesonderten Doku‑Schleifen erzeugt zu werden. Machine‑Learning‑ und AI‑Komponenten helfen zusätzlich, False Positives zu reduzieren, ähnliche Ereignisse zu clustern und auffällige Muster hervorzuheben – das SOC konzentriert sich auf die wenigen Vorfälle, die wirklich Aufmerksamkeit brauchen.
Auf Prozessebene bleiben Playbooks und Meldewege wichtig – aber schlank. Ein IR‑Playbook definiert Incident‑Klassen, Eskalationspfade und Kommunikationsregeln, inklusive der Kriterien, ab wann ein Vorfall als „NIS2‑signifikant“ gilt. Ein Meldeprozess regelt, wer die Informationen aus SOC und Fachbereichen konsolidiert und über die BSI‑Meldestelle einreicht.
Die eigentliche Dokumentation entsteht auch hier im Wesentlichen automatisch: Incident‑Tickets enthalten Timeline, betroffene Services, Impact, Ursache und Maßnahmen; ein Kennzeichen „NIS2‑relevant“ und ein Meldestatus verknüpfen sie mit den externen Berichten. Aus SIEM‑ und IR‑Daten lassen sich Kennzahlen wie MTTD, MTTR oder die Zeit zwischen Detection und Erstmeldung direkt berechnen – genau die Größen, an denen sich ablesen lässt, ob NIS2 gelebter Prozess ist oder nur eine neue Schublade im Dokumentenschrank.
NIS2 als Architektur‑Test, nicht nur als Doku‑Übung
NIS2 zwingt Unternehmen, ihre Sicherheitsmaßnahmen, Prozesse und Nachweise explizit zu machen. Das ist unbequem – gerade für Organisationen, die bisher stark ad hoc gearbeitet haben. Ob daraus ein Papiertiger oder ein echter Sicherheitsgewinn wird, entscheidet sich aber nicht im Gesetzestext, sondern in der Architektur.
Wer versucht, die Richtlinie vor allem mit Word, PowerPoint und Excel „wegzudokumentieren“, wird viel Aufwand und wenig Resilienz produzieren. Werden hingegen IdP und IAM, CI/CD‑Pipelines, SBOM‑ und Vulnerability‑Tools, SIEM und IR‑Plattform so aufgesetzt, dass sie die geforderten Controls und Nachweise quasi nebenbei liefern, bekommt man NIS2‑Compliance als Nebeneffekt einer modernen Security‑Landschaft. (jm)
No Responses