NIS2 Compliance für DevOps-Teams: Was jetzt zu tun ist

NIS2 ist keine abstrakte Regulierung, die irgendwo in Brüssel entsteht und dann vielleicht irgendwann relevant wird. Sie ist geltendes Recht mit konkreten technischen Anforderungen, harten Fristen und persönlicher Haftung für Geschäftsführer. Wer heute noch auf Legacy-Infrastruktur setzt, wird feststellen, dass der Nachrüstaufwand oft größer ist als eine Migration in eine compliant aufgebaute Cloud-Umgebung – und wer den Zeitpunkt verpasst, zahlt dafür in mehr als einer Hinsicht.

Was ist NIS2 und wer ist betroffen?

NIS2 steht für die zweite Fassung der EU-Richtlinie zur Netzwerk- und Informationssicherheit (Network and Information Security Directive). Sie löst die erste NIS-Richtlinie von 2016 ab und verschärft die Anforderungen an Cybersicherheit in Unternehmen und Behörden erheblich. In Deutschland wurde sie durch das NIS2-Umsetzungsgesetz (NIS2UmsuCG) in nationales Recht übertragen. Für den Finanzsektor gelten mit DORA zusätzliche Resilienz-Anforderungen, die über NIS2 hinausgehen.

Die wichtigste Änderung gegenüber NIS1: Der Kreis der betroffenen Unternehmen ist deutlich größer geworden. Während sich die erste Fassung hauptsächlich auf Betreiber kritischer Infrastrukturen beschränkte, erfasst NIS2 nun auch viele mittelgroße Unternehmen in einer Vielzahl von Sektoren Darunter digitale Infrastrukturen, IT-Dienstleister, Hosting-Anbieter, Gesundheitswesen, Energie, Transport und Finanzdienstleistungen.

Die Richtlinie unterscheidet zwischen zwei Kategorien:

• Wesentliche Einrichtungen (essential entities): Unternehmen in besonders kritischen Sektoren mit mehr als 250 Mitarbeitern oder mehr als 50 Mio. € Jahresumsatz.
• Wichtige Einrichtungen (important entities): Unternehmen in weiteren relevanten Sektoren mit mehr als 50 Mitarbeitern oder mehr als 10 Mio. € Jahresumsatz.

Für wesentliche Einrichtungen gelten strengere Aufsichtspflichten und höhere Bußgelder. Aber auch wichtige Einrichtungen unterliegen konkreten Sicherheitsanforderungen, die technisch und organisatorisch umgesetzt werden müssen.

Wichtige vs. wesentliche Einrichtungen

Der Unterschied liegt vor allem in der Intensität der Aufsicht und den möglichen Sanktionen. Bei wesentlichen Einrichtungen können Behörden proaktiv prüfen, ohne dass ein Vorfall gemeldet wurde. Bei wichtigen Einrichtungen erfolgen Kontrollen primär reaktiv, aber die Anforderungen an die technische Umsetzung sind in beiden Fällen vergleichbar.

Für DevOps-Teams ist die Kategorisierung damit weniger entscheidend als die Frage: Was muss technisch tatsächlich umgesetzt werden?

Was NIS2 Compliance DevOps-Teams technisch abverlangt

Die Richtlinie benennt konkrete Maßnahmenbereiche, die umgesetzt werden müssen. In der Praxis bedeutet das für DevOps-Teams:

Patch-Management und Schwachstellenbehandlung: Systeme müssen zeitnah gepatcht werden. Das klingt trivial, ist aber in vielen Umgebungen ein reales Problem. Insbesondere, wenn Produktionssysteme nicht automatisiert aktualisiert werden können und Patch-Zyklen manuell koordiniert werden müssen.

Logging und Monitoring: NIS2 verlangt, dass sicherheitsrelevante Ereignisse protokolliert und überwachbar sind. Das bedeutet: zentrales Log-Management, nachvollziehbare Audit-Trails, und die Fähigkeit, im Fall eines Vorfalls vollständige Protokolldaten vorlegen zu können. In vielen bestehenden Umgebungen fehlt ein zentrales SIEM oder die Logs sind nicht ausreichend strukturiert.

Incident Response: Es muss einen definierten Prozess für den Umgang mit Sicherheitsvorfällen geben inklusive Meldepflichten. Erhebliche Vorfälle müssen innerhalb von 24 Stunden an die zuständige Behörde (in Deutschland das BSI) gemeldet werden, ein vollständiger Bericht folgt innerhalb von 72 Stunden.

Zugangskontrollen und Netzwerksegmentierung: Prinzip der minimalen Rechte (least privilege), Trennung von Netzwerksegmenten, Multi-Faktor-Authentifizierung für privilegierte Zugänge. Wer noch mit geteilten Admin-Passwörtern oder flachen Netzwerken arbeitet, hat hier strukturellen Nachholbedarf.

Verschlüsselung und Datenschutz: Daten müssen in Übertragung und Ruhe verschlüsselt sein. Auch das klingt selbstverständlich, ist es aber in gewachsenen Infrastrukturen häufig nicht konsequent umgesetzt.

Business Continuity: Backup-Konzepte, Disaster-Recovery-Pläne und deren regelmäßige Überprüfung sind verpflichtend. Kein Konzept auf dem Papier, das nie getestet wurde, sondern nachweislich funktionierende Wiederherstellungsprozesse.

Dokumentations- und Nachweispflichten

Was viele unterschätzen: NIS2 verlangt nicht nur, dass diese Maßnahmen existieren, sondern dass sie nachweisbar sind. Behörden können Dokumentation anfordern, und im Fall eines Vorfalls wird geprüft, ob die Organisation ihrer Sorgfaltspflicht nachgekommen ist.

Das bedeutet: Konfigurationsmanagement, Change-Logs, Patch-Protokolle und Zugriffsauswertungen müssen nicht nur vorhanden, sondern abrufbar und strukturiert sein. In Kubernetes-basierten souveränen Umgebungen lässt sich das deutlich einfacher automatisieren als in heterogenen On-Prem-Landschaften.

Das Problem mit bestehenden Rechenzentren

On-Prem-Infrastrukturen sind nicht per se NIS2-inkompatibel. Aber viele bestehende Rechenzentren wurden zu einer Zeit aufgebaut, als Compliance-Anforderungen dieser Art nicht im Vordergrund standen und die Architekturentscheidungen von damals machen die Nachrüstung heute aufwendig.

Konkrete Schwachstellen, die DevOps-Teams in Legacy-Umgebungen regelmäßig begegnen:

• Kein zentrales Identity- und Access-Management. Benutzerkonten verteilen sich über verschiedene Systeme ohne einheitliche Policy-Durchsetzung.
• Manuelles Patch-Management. Viele Systeme können nicht automatisiert aktualisiert werden, weil Abhängigkeiten unklar sind oder Änderungen produktionskritische Auswirkungen haben könnten.
• Unvollständige oder unstrukturierte Logs. Logs existieren, aber nicht zentral, nicht einheitlich formatiert, und nicht mit ausreichender Aufbewahrungszeit.
• Flache Netzwerke. Interne Systeme kommunizieren ohne Segmentierung, was die Ausbreitung von Angreifern im Netzwerk erleichtert.
• Keine systematische Schwachstellenerfassung. Wer nicht kontinuierlich scannt, weiß nicht, welche CVEs in seiner Umgebung aktiv sind.

Das Nachrüsten dieser Punkte ist möglich, aber der Aufwand ist erheblich. Jedes Werkzeug muss evaluiert, integriert, betrieben und dokumentiert werden. Und anders als bei Cloud-Plattformen, die viele dieser Funktionen bereits mitbringen, muss die Integration hier manuell hergestellt werden.

Warum Cloud-Infrastrukturen NIS2-Compliance erleichtern

Moderne Cloud-Plattformen, vor allem solche auf Kubernetes-Basis, adressieren viele NIS2-Anforderungen strukturell. Das heißt nicht, dass eine Cloud-Migration automatisch Compliance erzeugt, aber der Ausgangspunkt ist erheblich besser.

Was Kubernetes-Plattformen typischerweise bereits mitbringen:

• RBAC (Role-Based Access Control) als natives Konzept, mit der Möglichkeit, Berechtigungen granular und nachvollziehbar zu steuern.
• Audit Logs für API-Aufrufe und Konfigurationsänderungen – maschinenlesbar, zentral, mit Zeitstempel.
• Automatisiertes Patch-Management durch rollierende Updates von Node-Images und Container-Basisimages, ohne manuelle Koordination.
• Netzwerkpolicies für Segmentierung auf Pod-Ebene, womit das Prinzip der minimalen Kommunikation durchgesetzt werden kann.
• Secrets-Management mit Integrationsmöglichkeiten für externe Vault-Systeme.
• Verschlüsselung in der Kommunikation zwischen Services über mTLS (z. B. via Service Mesh).

Souveränität als technische Anforderung

Ein Punkt, den gerade deutsche Unternehmen unter NIS2 im Blick haben sollten: Die Frage, wo Logs, Daten und Konfigurationen gespeichert werden, ist nicht nur eine DSGVO-Frage, sondern auch eine NIS2-relevante.

US-amerikanische Hyperscaler unterliegen dem CLOUD Act, der US-Behörden unter bestimmten Umständen Zugriff auf Daten erlaubt unabhängig davon, wo die Daten physisch gespeichert sind. Für Unternehmen, die NIS2-pflichtige Daten verarbeiten, kann das ein echtes rechtliches Risiko darstellen.

Europäische Cloud-Infrastrukturen mit Betrieb ausschließlich in Deutschland oder der EU, kombiniert mit Zertifizierungen wie BSI C5 oder ISO 27001, sind hier strukturell im Vorteil. Das EU Cloud Sovereignty Framework definiert erstmals prüfbare Kriterien für diese Anforderungen.

NIS2 Compliance DevOps: Erste konkrete Schritte

Wer jetzt nicht sicher ist, ob und in welchem Umfang NIS2 für das eigene Unternehmen gilt, sollte mit einer strukturierten Betroffenheitsprüfung beginnen. Das BSI stellt dafür Orientierungshilfen bereit. Viele Verbände und Anwaltskanzleien bieten auch kompakte Checklisten an.

Nach der Betroffenheitsprüfung folgt die Gap-Analyse: Welche der geforderten Maßnahmen sind bereits umgesetzt? Wo fehlt Dokumentation? Wo gibt es technische Lücken?

Aus dieser Analyse ergibt sich eine priorisierte Roadmap. Sinnvoll ist es, mit den Punkten zu beginnen, die das höchste Risiko tragen und den geringsten Umsetzungsaufwand bedeuten. Zum Beispiel das Einführen von MFA für privilegierte Zugänge oder das Zentralisieren von Logs.

Für Teams, die bereits eine Migration zu einer Cloud-Plattform erwägen, kann NIS2 der Auslöser sein, diesen Schritt konkret zu planen. Eine Plattform, die Compliance-Anforderungen strukturell mitbringt, reduziert den laufenden Aufwand erheblich, weil weniger manuell konfiguriert, gepflegt und nachgewiesen werden muss.

lowcloud betreibt eine Kubernetes-DaaS-Plattform, die in Deutschland gehostet wird und auf DSGVO-konforme, souveräne Cloud-Infrastruktur ausgelegt ist.

NIS2 ist kein Thema, das sich durch Abwarten löst. Die Anforderungen sind definiert, die Fristen laufen, und die Frage ist nicht ob, sondern wie schnell und mit welcher Infrastruktur die Umsetzung gelingt. Warum Cloud-Souveränität zur Chefsache werden muss, haben wir separat aufgearbeitet. Bestehende Rechenzentren können nachgerüstet werden, aber wer jetzt eine Plattformentscheidung trifft, sollte Compliance als Architekturanforderung behandeln, nicht als nachträgliches Projekt.