Wenn NIS2 und DORA kein Compliance-Programm mehr sind, sondern eine Verwaltungsgestaltung der digitalen Widerstandsfähigkeit.

In vielen Organisationen wird die administrative Verantwortung historisch gesehen durch die Ernennung eines CISO und die Festlegung eines politischen Rahmens wahrgenommen. Die aufsichtsrechtliche Verantwortung erfordert jedoch etwas anderes: administrative Rückverfolgbarkeit.

Eine Organisation muss nachweisen können:

1. Welche Risiken sie auf Führungsebene anerkennt: vom Bedrohungsbild zur Unternehmens-Exposition;

2. Welche Kontrollmaßnahmen gewählt wurden und warum;

3. Welches Restrisiko akzeptiert wird und auf welcher Ebene;

4. Wie überprüft wird, dass Kontrollmaßnahmen wirksam sind;

5. Wie bei Abweichungen innerhalb des Governance-Zyklus nachgesteuert wird.

Diese Nachvollziehbarkeit ist kein Dokumentationsprojekt. Sie erfordert ein Steuerungsmodell, in dem Cyberrisiken mit derselben Disziplin behandelt werden wie finanzielle, rechtliche oder Kreditrisiken – mit klaren Verantwortlichen, Risikobereitschaft, Key Risk Indicators (KRIs) und Key Performance Indicators (KPIs), Eskalationspfaden und formalen Entscheidungszeitpunkten.

Die implizite Anforderung: Kontrollierbarkeit im großen Maßstab

NIS2 und DORA implizieren, dass Cyber-Kontrollen über Business Units, Produktlinien, Cloud- und Applikationslandschaften, Lieferketten und transnationale Geschäftsmodelle hinweg skalierbar sein müssen. Regulierung geht nicht davon aus, dass einzelne Kontrollmaßnahmen nur in einem isolierten Bereich nachgewiesen werden können, sondern dass Konsistenz über die gesamte organisatorische und technologische Breite des Unternehmens belegt werden kann.

Daher verschiebt sich der Fokus von einzelnen Initiativen hin zu systemischer Gestaltung. Eine isolierte Implementierung etwa von SIEM-Tooling reicht nicht aus, wenn Architekturprinzipien, Lieferkontrollen, Identity Governance, Logging- und Monitoring-Baselines sowie Lieferanten-Governance nicht kohärent zusammenspielen.

Kontrollierbarkeit im großen Maßstab bedeutet, dass Sicherheitsmaßnahmen reproduzierbar, messbar und administrativ nachvollziehbar sind – unabhängig davon, wo in der Organisation sie angewendet werden.

NIS2 in der Praxis: Compliance ist ein Nebenprodukt reifer Steuerung

NIS2 positioniert Cybersecurity-Risikomanagement als eine Reihe von Maßnahmen, die Organisationen implementieren und betreiben müssen. In der Praxis wird Compliance jedoch häufig als Endziel betrachtet, obwohl sie in Wirklichkeit das Ergebnis reifer Governance ist.

Wenn Governance, Architektur und operative Kontrolle kohärent gestaltet sind, folgt Compliance als logische Konsequenz.

Die typische Falle: Richtlinien ohne Nachweis

In einer reifen Organisation ist Policy nicht das Endziel, sondern der Beginn der Nachweisführung. Regulatorischer Druck macht den Unterschied sichtbar zwischen papierbasierter Compliance und nachweisbarer Kontrolle.

Das erste besteht aus Richtliniendokumenten, Verfahren und Awareness-Programmen. Das zweite erfordert messbare Kontrollen, Logging, Reporting, Testergebnisse und kontinuierliche Verbesserungszyklen.

Die Governance-Artikel innerhalb von NIS2 steuern implizit auf dieses zweite Niveau hin. Führungskräfte müssen Aufsicht ausüben können – und dafür ist steuerbare Managementinformation notwendig. Ohne konsistente, nachvollziehbare und belegbare Informationen entsteht eine Lücke zwischen formaler Verantwortung und tatsächlicher Kontrolle.

Die strategische Frage für Sie als CISO

Die zentrale Frage lautet nicht, ob Sie compliant sind.
Die zentrale Frage lautet, ob Sie konsistent nachweisen können, dass Ihre Cyberrisiken administrativ unter Kontrolle stehen.

Das erfordert eine andere Disziplin als klassisches Security-Programmmanagement. Sie benötigen eine Management-Informationsschicht, die technische Realität in geschäftliche Auswirkungen, Abdeckung von Kontrollen, Wirksamkeit und Wiederherstellungsfähigkeit übersetzt.

Erst wenn Exposition, Wirksamkeit von Kontrollen und Resilienz in einem zusammenhängenden Rahmen dargestellt werden, kann die Unternehmensführung fundierte Entscheidungen über Risikoakzeptanz treffen.

DORA: Incident Reporting und Aufsichtslogik beschleunigen Reife oder Schmerz

DORA formalisiert Erwartungen, die Aufsichtsbehörden seit Jahren implizit hatten. Durch strukturierte Anforderungen an Incident Reporting, Testing und Third-Party-Oversight wird operative digitale Resilienz zu einem überprüfbaren System.

Dies beschleunigt organisatorische Reife, wenn Governance und Umsetzung aufeinander abgestimmt sind – legt aber auch schonungslos offen, wo Strukturen nicht robust genug sind.

Incident Reporting als Stresstest Ihres Operating Models

Incident Reporting ist keine administrative Pflicht, sondern ein Stresstest Ihres Operating Models. Wenn ein schwerwiegender Vorfall eintritt, zeigt sich, wie Klassifikation, Erkennung, Triage, Krisen-Governance, forensische Analyse, Kommunikation und Wiederherstellungsentscheidungen tatsächlich funktionieren.

Wenn während eines Vorfalls keine konsistente Timeline, keine fundierte Impact-Analyse und keine klare Entscheidungsdokumentation erstellt werden kann, weist dies nicht nur auf ein operatives Defizit hin, sondern auf ein Governance-Defizit. Reporting zwingt Organisationen, ihre interne „Wahrheitsmaschine“ strukturell in Ordnung zu bringen.

Resilience Testing als Steuerungsdisziplin

DORA betont Resilience Testing und Third-Party-Risiken. Testing ist jedoch nur dann wertvoll, wenn es direkt mit Architekturentscheidungen, Wiederherstellungsstrategien und konkreten Verbesserungsmaßnahmen verbunden ist.

Wenn Testing lediglich als periodische Übung ohne Einfluss auf Design und Entscheidungen durchgeführt wird, entsteht ritualisiertes Verhalten. Wenn Ergebnisse systematisch in Anpassungen von Kontrollen, Architektur und Governance übersetzt werden, wird Testing zu einer Management-Feedbackschleife, die Resilienz strukturell stärkt.

Third-Party-Risk: vom Vertragsmanagement zur Kettenverantwortung

Sowohl NIS2 als auch DORA verstärken den Fokus auf Abhängigkeiten wie Cloud-Provider, Managed Services, Softwareanbieter, Integratoren und andere kritische IT-Dienstleister.

Historisch wurde Third-Party-Risk häufig über Vertragsklauseln, periodische Assessments und ein generisches Risikoregister organisiert. Regulatorischer Druck verlangt jedoch eine Lieferkettenperspektive, in der klar ist:

• welche Anbieter für welche Services kritisch sind,

• welche Kontrollmaßnahmen auferlegt werden,

• wie Compliance überprüft wird,

• welche Exit-Strategien existieren,

• und wie sich Vorfälle entlang der Kette ausbreiten können.

Es geht nicht länger um Lieferantenmanagement im administrativen Sinne, sondern um Kettenverantwortung im Governance-Sinne.