NIS2:

Wenn Cyberresilienz zur Chefsache wird

Antoine Dussault ist Product Manager bei einem Observability-Anbieter mit Fokus auf europäische Datensouveränität. Er beschäftigt sich dort mit den regulatorischen Anforderungen an KI- und Infrastruktur-Compliance, unter anderem im Kontext von NIS2 und dem EU AI Act.

Seit dem 6. Dezember 2025 gilt in Deutschland eine neue Frist, die für viele Geschäftsführungen eine neue Art von Risiko darstellt. Unternehmen, die dem NIS2-Umsetzungsgesetz unterliegen, müssen einen erheblichen Sicherheitsvorfall innerhalb von 24 Stunden als Frühwarnung an das BSI melden. Nach 72 Stunden erfolgt eine detaillierte Bewertung und nach einem Monat wird der Abschlussbericht erstellt. Von Energieversorgern über Maschinenbauer bis zu Anbietern digitaler Infrastruktur sind rund 29.500 Unternehmen in Deutschland betroffen. Bei Verstößen drohen Bußgelder von bis zu zehn Millionen Euro oder zwei Prozent des weltweiten Jahresumsatzes für besonders wichtige Einrichtungen; für wichtige Einrichtungen bis zu sieben Millionen Euro oder 1,4 Prozent. Zudem haften Geschäftsführungen bei grober Pflichtverletzung persönlich.

Diese Regelung markiert einen Bruch mit der bisherigen Praxis, Cybersicherheit als reines Thema der IT-Abteilung zu behandeln. Wenn die gesetzliche Frist bereits 24 Stunden nach Kenntnisnahme eines Vorfalls beginnt und nicht erst, wenn eine Untersuchung abgeschlossen ist, wird die Fähigkeit zur schnellen Aufklärung zur Frage der Unternehmensführung und nicht mehr allein der technischen Abteilung. Wie ernst der Gesetzgeber diese Verpflichtung nimmt, zeigte sich bereits bei einem vorherigen Schritt: Betroffene Einrichtungen mussten sich innerhalb von drei Monaten nach Inkrafttreten der Verordnung, also bis zum 6. März 2026, beim BSI registrieren. Da ein Großteil der rund 29.500 betroffenen Einrichtungen diese Frist verpasste, gewährte das BSI eine Nachfrist bis zum 31. Juli 2026. Schon die verspätete Registrierung kann mit einem Bußgeld von bis zu 500.000 Euro geahndet werden – unabhängig davon, ob je ein Sicherheitsvorfall eintritt.

NIS2 verlangt dabei weit mehr als eine schnelle Reaktion im Ernstfall: Risikobewertungen, Lieferkettensicherheit und dokumentierte Backup-Konzepte gehören zum Pflichtenkatalog. Hinzu kommen technische und organisatorische Grundmaßnahmen wie Multi-Faktor-Authentifizierung, Verschlüsselung und ein kontinuierliches Schwachstellenmanagement. Wer betroffen ist, richtet sich nach zwei Schwellenwerten: Als „wichtige Einrichtung” gilt, wer mindestens 50 Mitarbeitende beschäftigt oder einen Jahresumsatz von mehr als 10 Millionen Euro bei einer Bilanzsumme von ebenfalls über 10 Millionen Euro aufweist (beide Finanzkennzahlen müssen gemeinsam überschritten sein). Als „besonders wichtige Einrichtung“ mit strengeren Prüfrechten des BSI gilt, wer mindestens 250 Mitarbeitende beschäftigt oder einen Jahresumsatz von über 50 Millionen Euro bei einer Bilanzsumme von über 43 Millionen Euro erreicht. Die Zuordnung muss von den Unternehmen selbst anhand von Sektor und Größenklasse geprüft werden. Gerade bei Unternehmen an Sektorgrenzen sorgt dieses Detail für Unsicherheit.

Sichtbarkeit als eine Voraussetzung für Compliance

Neben etablierten Meldeprozessen, geschulten Verantwortlichen und einem funktionierenden Risikomanagement hängt die Einhaltung der NIS2-Fristen maßgeblich davon ab, wie gut ein Unternehmen seine IT-Umgebung im Blick hat. Unternehmen, die Logs, Deployments und Infrastrukturänderungen vernetzt betrachten, bemerken Auffälligkeiten oft bereits während ihrer Entstehung. Unternehmen ohne diese Grundlage benötigen oft mehrere Tage, um denselben Sachverhalt zu rekonstruieren – während die gesetzliche Uhr weiterläuft.

Für die Geschäftsführung bedeutet dies eine strategische Verschiebung der Investitionsprioritäten in Richtung Vorsorge: Systemtransparenz ist nicht länger ein rein technisches Anliegen der IT-Abteilung, das sich bei Bedarf nachrüsten lässt. Sie ist eine notwendige, wenn auch nicht hinreichende Voraussetzung, um gesetzlichen Pflichten nachkommen zu können. Und diese zentrale Voraussetzung muss ebenfalls lange vor einem konkreten Vorfall geschaffen werden.

Der Zusammenhang zur digitalen Souveränität

NIS2 lässt sich nicht isoliert von der umfassenderen Debatte um digitale Souveränität betrachten, die deutsche und europäische Unternehmen derzeit führen. Wer die Kontrolle über die eigene Infrastruktur, die eigenen Daten und die eigene technologische Abhängigkeit stärken will, muss zwangsläufig auch die Frage beantworten, wie schnell und wie zuverlässig er den Zustand der eigenen Systeme kennt. Digitale Souveränität, die sich im Ernstfall nicht innerhalb der gesetzlichen Fristen belegen lässt, ist ein politisches Bekenntnis ohne operative Substanz.

In der öffentlichen Debatte wird diese Verbindung häufig unterschätzt: Digitale Souveränität wird meist nur im Zusammenhang mit Cloud-Standorten, Anbieterwahl oder Datenspeicherung diskutiert. NIS2 macht jedoch deutlich, dass sie ebenso eine Frage der operativen Reaktionsfähigkeit ist, unabhängig davon, wo die Infrastruktur steht oder wer sie betreibt. Wie schnell diese Reaktionsfähigkeit im Ernstfall tatsächlich sein muss, zeigt sich nicht nur an der eigenen Infrastruktur, sondern auch an deren Grenzen.

Warum Sichtbarkeit an der eigenen Systemgrenze nicht endet

Die NIS2-Richtlinie verpflichtet Unternehmen nicht nur zur Absicherung der eigenen Infrastruktur, sondern auch zur Bewertung von Risiken in der Lieferkette. Für Geschäftsführungen bedeutet das: Ein Sicherheitsvorfall bei einem Zulieferer, einem Cloud-Anbieter oder einem IT-Dienstleister kann die gleiche 24-Stunden-Meldepflicht auslösen wie ein Vorfall im eigenen Rechenzentrum – vorausgesetzt, das eigene Unternehmen erkennt rechtzeitig, welche Systeme betroffen sind.

Genau hier liegt die praktische Schwierigkeit. Zwar verfügen viele Unternehmen über vertragliche Zusicherungen ihrer Zulieferer, jedoch kaum über die technische Sichtbarkeit, die Aufschluss darüber gibt, welche eigenen Dienste tatsächlich von einer bestimmten externen Komponente abhängen. Ein Vertrag beantwortet im Ernstfall nicht die entscheidende Frage, welche eigenen Systeme in den ersten Minuten betroffen sind, sondern regelt lediglich, wer im Schadensfall haftet. Fällt ein Zulieferer aus oder wird kompromittiert, beginnt die 24-Stunden-Uhr zu ticken – allerdings ohne den Vorteil, dass das eigene Team von Anfang an weiß, wo genau die Abhängigkeit liegt.

Wer die Abhängigkeiten von Drittanbietern in der eigenen Telemetrie abbildet (etwa welche internen Services welche externen APIs, Bibliotheken oder Cloud-Dienste nutzen), kann im Ernstfall innerhalb von Minuten eingrenzen, ob und wie stark die eigene Umgebung betroffen ist. Ohne diese Sichtbarkeit bleibt zunächst offen, ob ein gemeldeter Vorfall bei einem Zulieferer für das eigene Unternehmen überhaupt relevant ist – eine Unsicherheit, die sich mit der gesetzlichen Frist im Nacken kaum noch leisten lässt.

NIS2 ist kein Einzelfall: ein europäisches Muster

Das Grundprinzip von NIS2 – die Meldefrist beginnt mit der Kenntnisnahme, nicht mit dem Abschluss der Untersuchung – ist keine deutsche Eigenheit, sondern folgt einem breiteren europäischen Muster. Für den Finanzsektor gilt seit Januar 2025 mit DORA (Digital Operational Resilience Act) eine noch schärfere Variante: Eine Erstmeldung muss innerhalb von vier Stunden nach Klassifizierung eines schwerwiegenden IKT-Vorfalls erfolgen, spätestens jedoch 24 Stunden nach Kenntnisnahme. Nach 72 Stunden muss ein Zwischenbericht und nach einem Monat ein Abschlussbericht erstellt werden. Finanzunternehmen sind von der NIS2-Meldepflicht ausgenommen, da hier DORA als spezielleres Regelwerk gilt. Die Fristlogik bleibt jedoch dieselbe.

Auch der EU AI Act folgt diesem Muster mit eigenen Fristen: Anbieter von Hochrisiko-KI-Systemen müssen schwerwiegende Vorfälle der zuständigen Marktüberwachungsbehörde grundsätzlich innerhalb von 15 Tagen melden. Bei weitverbreiteten Verstößen oder Beeinträchtigungen kritischer Infrastrukturen beträgt die Frist zwei Tage und bei Todesfällen zehn Tage. Die Frist beginnt in allen Fällen, sobald ein ursächlicher Zusammenhang zwischen dem KI-System und dem Vorfall feststellbar oder wahrscheinlich ist, unabhängig davon, wann die Untersuchung abgeschlossen ist.

Für Unternehmen, die NIS2, DORA und den EU AI Act parallel im Blick behalten müssen, ergibt sich eine gemeinsame Anforderung: Wer frühzeitig erkennen kann, was in den eigenen Systemen passiert ist, erfüllt damit eine Grundvoraussetzung für alle drei Regelwerke gleichzeitig – unabhängig davon, welche der drei Fristen im Einzelfall greift. Wer diese Fähigkeit dagegen für jedes Regelwerk separat aufbaut, verdreifacht den Aufwand für eine Frage, die technisch immer dieselbe ist: Was hat sich wann in unserer Umgebung geändert?

Erkennen, eingrenzen, wiederherstellen: die Abfolge, die über die Frist entscheidet

Erkennen, Eingrenzen, Umfang bestimmen, Isolieren, Wiederherstellen, Validieren: Dieser Ablauf unterscheidet sich von Unternehmen zu Unternehmen kaum. Was sich jedoch massiv unterscheidet, ist die Geschwindigkeit jedes einzelnen Schritts. Diese hängt fast vollständig davon ab, wie gut ein Unternehmen seine Umgebung im Blick hat.

Am deutlichsten zeigt sich das bei der Erkennung und der Umfangsbestimmung. Teams mit gut korrelierter Telemetrie (Logs, Traces, Metriken, Deployment-Ereignisse und Infrastrukturänderungen) können innerhalb von Minuten feststellen, was, wann und wo sich geändert hat. Teams ohne diese Grundlage rekonstruieren denselben Zeitverlauf manuell, oft über Tage: Welches System war zuerst betroffen? Wann genau begann die laterale Bewegung? Welche Datenbanken wurden abgefragt? Jede dieser Fragen kostet Zeit, während die Uhr für die Frühwarnung unbeirrt weiterläuft.

Für ein Unternehmen ohne etablierte Incident-Response-Struktur bedeutet das im Ernstfall, dass die formale Meldung nach 24 Stunden zur Fiktion wird, wenn selbst die Frage „Was ist eigentlich passiert?” nach 24 Stunden noch nicht beantwortet ist. Die gesetzliche Frist wird unfreiwillig zum Stresstest für die eigene Sichtbarkeit. Und dieser Test lässt sich nicht verschieben.

Warum sich die Kosten eines Vorfalls nicht linear, sondern kumulativ entwickeln

Die finanziellen und regulatorischen Folgen eines Sicherheitsvorfalls potenzieren sich mit der Zeit, anstatt gleichmäßig zu wachsen. Je länger die Ungewissheit über das Ausmaß eines Vorfalls anhält, desto mehr Raum haben Angreifer, sich seitlich zu bewegen, Berechtigungen auszuweiten und den Schaden zu vergrößern. Am Ende müssen mehr Systeme wiederhergestellt und mehr Daten überprüft werden, als zunächst absehbar war.

Diese Verzögerung wirkt sich unmittelbar auf die Handlungsfähigkeit der Unternehmensführung aus. Wer nicht innerhalb der gesetzlichen Fristen belastbar beantworten kann, was genau betroffen war, kann weder eine korrekte Meldung an das BSI abgeben noch einen sauberen Restore-Umfang festlegen. Auch gegenüber Kund:innen, Partner:innen oder dem eigenen Aufsichtsrat lässt sich kaum glaubhaft nachweisen, dass die Lage unter Kontrolle ist. Oft zeigt sich erst im Nachhinein, dass nicht die technische Wiederherstellung der langsame Teil war, sondern die Zeit, die benötigt wurde, um herauszufinden, was überhaupt wiederhergestellt werden musste. Genau an dieser Stelle wird aus einem technischen Vorfall eine Frage der Unternehmenshaftung – und damit unweigerlich Chefsache.

Warum sich die Erwartungen weiter verschärfen werden

Der regulatorische Druck trifft auf eine technische Entwicklung, die schnellere Reaktionen ermöglicht. Automatisierte, KI-gestützte Systeme können sicherheitsrelevante Signale wie ungewöhnliche Zugriffsmuster, Log-Anomalien oder unerwartete Deployment-Änderungen innerhalb von Sekunden korrelieren. Früher nahm diese Aufgabe den Großteil des ersten Tages nach einem Vorfall in Anspruch. Je selbstverständlicher diese Möglichkeiten werden, desto weniger Nachsicht wird es künftig für Unternehmen geben, die sie nicht nutzen. Dadurch verschiebt sich der praktische Maßstab: von „irgendwann in den ersten 24 Stunden eine Meldung abgeben können” hin zu „innerhalb weniger Stunden eine belastbare erste Einschätzung haben”.

Hinzu kommt ein struktureller Faktor: Mit gleich großen Sicherheits- und IT-Teams verwalten Unternehmen zunehmend komplexere und sich schneller ändernde Systemlandschaften. Der einzige realistische Weg, um unter diesen Bedingungen regulatorische Fristen dauerhaft einzuhalten, ist die Automatisierung von Erkennung, Korrelation und Bewertung. Denn zusätzliches Personal lässt sich kurzfristig ohnehin selten in ausreichendem Umfang aufbauen.

Was das für die Unternehmensführung bedeutet

Für Geschäftsführungen ergeben sich daraus vier praktische Konsequenzen:

Erstens gehört Systemtransparenz auf die Vorstandsagenda und nicht nur ins IT-Budget. Sie ist eine Voraussetzung für regulatorische Handlungsfähigkeit und kein technisches Detail. Das bedeutet, dass Entscheidungen über Monitoring- und Observability-Budgets in denselben Gremien getroffen werden, die auch über Risikomanagement und Haftungsfragen entscheiden. Sie dürfen nicht in einer separaten IT-Budgetlinie enden, über die der Vorstand nur bei Bedarf informiert wird.

Zweitens lässt sich die Frage „Sind wir compliant?” nicht mehr allein mit einem Verweis auf Richtlinien und Zertifikate beantworten. Es muss nachgewiesen werden, dass das Unternehmen im Ernstfall tatsächlich innerhalb der gesetzlichen Fristen handlungsfähig ist. Am besten erfolgt dies durch die Überprüfung simulierter Vorfälle und nicht erst durch echte. Eine Tabletop-Übung, die die 24-Stunden-Meldefrist unter realistischen Bedingungen durchspielt, deckt Lücken auf, die sich in einem Compliance-Dokument allein nicht zeigen – vorausgesetzt, das Team kennt die eigene Normalbasis gut genug, um Abweichungen im Ernstfall überhaupt zu erkennen.

Drittens sollte die Verantwortung für diesen Nachweis klar zugeordnet sein, statt diffus zwischen IT-Leitung, Datenschutzbeauftragten und Geschäftsführung verteilt zu werden. Im Ernstfall muss eine benannte Person berichten können. Die dafür nötigen Zuständigkeiten, Vorlagen und Eskalationswege für die BSI-Meldung sollten bereits vor einem Vorfall feststehen und nicht erst danach. Ohne das verliert eine Organisation im Ernstfall Zeit für interne Abstimmungen, die eigentlich für die technische Aufklärung benötigt wird.

Viertens wird die Verbindung zwischen Cyberresilienz und digitaler Souveränität enger, je mehr regulatorischer Druck entsteht. Wer über das eine spricht, kommt am anderen nicht vorbei. Lange wurde Cyberresilienz vorwiegend in IT-Abteilungen diskutiert. Mit NIS2 wird sie auf die Ebene der Unternehmensführung gehoben – mit harten, bußgeldbewehrten Fristen. Damit wird eine Frage unausweichlich, die viele Vorstände bislang delegieren konnten: nicht, ob das eigene Unternehmen angegriffen wird, sondern ob es im Angriffsfall schnell genug herausfindet, was passiert ist.