Zwischen DORA und NIS2: Warum Governance jetzt auf dem Prüfstand steht

Zwischen DORA und NIS2: Warum Governance jetzt auf dem Prüfstand steht

Es gibt Momente, in denen Regulierung nicht nur Regeln setzt, sondern eine ganze Organisation in den Spiegel schauen lässt. DORA und NIS2 sind genau solche Momente. Die eine Verordnung richtet sich mitten ins Herz der Finanzwelt und macht digitale Resilienz zur Chefsache. Die andere spannt den Bogen über große Teile der europäischen Wirtschaft und hebt Cybersicherheit auf ein neues, sektorübergreifendes Niveau. Zusammen erzeugen sie einen Druck, der weit über Checklisten hinausreicht: Governance wird zur Bewährungsprobe. Nicht mehr die Frage, ob Richtlinien existieren, sondern ob Steuerung messbar wirkt, entscheidet darüber, wie belastbar ein Unternehmen wirklich ist.

Der Doppeldruck: Zwei Wellen, ein Kernproblem

Viele Häuser erleben gerade zwei Wellen gleichzeitig. Von DORA her rollt die Erwartung, digitale Betriebsfähigkeit selbst unter Störung nachweislich zu sichern – mit Risikomanagement, Meldung, Tests und streng geführter Lieferkette. Von NIS2 her wächst der Anspruch, Cyberrisiken querschnittlich zu beherrschen – vom Vorstand über Technik bis hin zu Partnern und Dienstleistern. Auf den ersten Blick zwei Welten; in Wahrheit ein Kernproblem: Führung unter Unsicherheit. Wer beide Rahmen ernst nimmt, erkennt schnell: Governance ist nicht die Summe von Einzelanforderungen, sondern ein lebendes System, das Ziele, Risiken, Kontrollen, Daten und Entscheidungen miteinander verzahnt – und zwar so, dass man es jederzeit belegen kann.

Was DORA einfordert – und warum das mehr ist als IT-Sicherheit

DORA adressiert Informations- und Kommunikationstechnologie als Betriebsrisiko des Finanzsektors. Nicht nur Firewalls, nicht nur Policies, sondern die Fähigkeit, kritische Geschäftsprozesse trotz Angriff, Ausfall oder Lieferkettenstörung fortzuführen. Der Blick richtet sich auf fünf Säulen, die zusammen eine Story ergeben:

• IKT-Risikomanagement als integrierter Prozess, der Schutzbedarf, Kritikalität und Toleranzen sichtbar macht.
• Incident Reporting als gestufter, strukturierter Meldeweg mit klaren Verantwortungen, Eskalationslinien und verlässlichen Fakten.
• Resilienztests, die nicht auf der Infrastruktur stehen bleiben, sondern Wiederherstellung auf Anwendungsebene und Geschäftsfortführung beweisen.
• Third-Party-Risk als Daueraufgabe: Auswahl, Verträge, Monitoring, Exit – geführt, nicht verwaltet.
• Informationsaustausch, damit Erkenntnisse nicht im eigenen Haus versickern, während andere dieselben Fehler wiederholen.

Damit verschiebt DORA die Messlatte: Nicht, was auf dem Papier versprochen wird, zählt – sondern was unter Druck funktioniert.

Was NIS2 verlangt – und warum die Messlatte breiter wird

NIS2 weitet den Blick über den Finanzsektor hinaus. Es verpflichtet essentielle und wichtige Einrichtungen in vielen Branchen, Cybersicherheit grundsätzlich zu verankern: in Strategie, Organisation, Technik, Lieferkette und Berichtspflichten. Der definierte Anspruch ist weniger sektorspezifisch, dafür konsequent generalistisch: Risikomanagement, Sicherheitsmaßnahmen, Vorfallmanagement, Business Continuity, Supply-Chain-Steuerung, Audits und Aufsicht. Besonders prägend sind zwei Elemente:

• Verantwortlichkeit des Managements: Cybersicherheit wird nicht delegiert, sie bleibt im Mandat der Leitung.
• Melde- und Reaktionsfähigkeit: Vorfälle werden früh erkannt, zeitnah eingeordnet und gestuft gemeldet; Lessons Learned wandern zurück in Prozesse, Kontrollen und Architektur.

NIS2 macht klar: Cybersicherheit ist kein Spezialthema der Technik. Sie ist Gouvernanz – und damit ein Thema von Zielkonflikten, Prioritäten, Budgets, Kultur.

Gemeinsame Nenner: Das unsichtbare Bindeglied

Wer DORA und NIS2 nebeneinander legt, sieht schnell die Überschneidungen: Risikobasierung, Managementverantwortung, Meldeketten, Tests, Lieferkette, Dokumentation. Der Unterschied liegt im Zuschnitt, nicht im Prinzip. Die Chance liegt genau hier: Ein Haus muss nicht zwei parallele Welten bauen. Es kann eine Governance-Erzählung konstruieren und beide Rahmen darin beheimaten. Die Leitfrage lautet dann nie „DORA oder NIS2?“, sondern „Welche Führung braucht unser Unternehmen, damit beides automatisch mitläuft?“.

Unterschiede, die zählen – und wie man sie klug nutzt

Trotz der Schnittmenge gibt es wesentliche Unterschiede, die die Praxis prägen:

• Sektorlogik: DORA mit aufsichtsrechtlicher Tiefe im Finanzsektor; NIS2 breit angelegt für viele Branchen. Antwort: Einen Kern schaffen, der universell trägt – und Spezifika additiv schärfen.
• Third-Party-Regime: DORA betont die direkte Steuerbarkeit kritischer IKT-Dienstleister (bis hin zu Aufsichtsmitteln), NIS2 verankert Supply-Chain-Risiken als Pflicht des Unternehmens. Antwort: Eine Lieferkettensteuerung, die beides kann: vertraglich greifbar sein und operativ messen.
• Testing: DORA benennt die Pflicht zu risikoorientierten Tests einschließlich angriffsnaher Szenarien; NIS2 fordert wirksame Maßnahmen und Überprüfung ihrer Effektivität. Antwort: Ein Testprogramm, das IT, Prozesse und Menschen umfasst – mit Akzeptanzkriterien, Integritätsbelegen und Re-Tests.
• Aufsichtsarchitektur: DORA über Fachaufsichten und europäische Abstimmung, NIS2 über nationale Stellen und CSIRTs. Antwort: Ein Incident-Backbone, der mehrere Meldeziele bedienen kann – ohne doppelte Arbeit und ohne widersprüchliche Fakten.

Diese Unterschiede sind keine Last, sondern ein Gestaltungsraum. Sie zwingen dazu, Governance nicht als Abhak-Übung, sondern als Betriebsmodell zu denken.

Governance als Betriebssystem: Von der Policy zur Evidenz

Zwischen DORA und NIS2 entscheidet sich die Reife einer Organisation an einem Punkt: Evidenz. Nicht das Versprechen zählt, sondern die Spur, die Arbeit hinterlässt. Wer Governance als Betriebssystem umsetzt, etabliert fünf Routinen:

1. Zielkaskade: Unternehmensziele → IKT-/Sicherheitsziele → messbare Metriken.
2. Schwellen & Toleranzen: Was löst Eskalation aus – fachlich, technisch, regulatorisch?
3. Entscheidungsrechte: Wer entscheidet im Normal- und im Krisenmodus? Mit welchem Mandat?
4. Evidenzpfade: Welche systemischen Nachweise fallen an (Logs, Exporte, Ticketverläufe, Pipeline-Gates, Restore-Protokolle), welche müssen nachgeschärft werden?
5. Kohärenz: Sehen Risiko, Incident, Test, Lieferkette, Finanzen dieselbe Realität – oder kursieren fünf Wahrheiten?

Diese Routinen brauchen keine heroischen Projekte, sondern Takt. Governance ist das, was regelmäßig passiert – oder es ist Dekor.

Risikomanagement neu vermessen: Von der Liste zur Regelspur

„Risiken identifizieren, bewerten, behandeln“ kann jedes Lehrbuch. Zwischen DORA und NIS2 reicht das nicht. Entscheidend ist, ob Risiko als Regelspur sichtbar wird: Schutzbedarfe und Kritikalitäten sind aktuell; KRI (Key Risk Indicators) haben Schwellen; Überschreitungen erzeugen Tickets; Entscheidungen sind datiert, adressiert, belegt; Präventiv- und Korrekturmaßnahmen (CAPA) werden geschlossen; Re-Checks bestätigen die Wirkung. So wird aus einem Register Steuerung.

Incident-Management: Eine Geschichte, viele Adressaten

Der erste echte Härtetest ist der Vorfall. Hier prallen Tempo, Unsicherheit, Kommunikation und Dokumentationspflichten aufeinander. Die Lösung ist ein Incident-Backbone:

• Erkennen über Use Cases, nicht über Logvolumen (z. B. anomale Identitätsnutzung, Datenabflussmuster, privilegierte Eskalation, auffällige Cloud-APIs).
• Einordnen entlang definierter Kriterien (Ausmaß, Kundenrelevanz, geographische Reichweite, zeitliche Ausdehnung, Systembezug).
• Melden gestuft und konsistent – intern, an Kunden, ggf. an mehrere Behörden.
• Bearbeiten mit klaren Rollen (Technik, Recht, Kommunikation, Aufsicht).
• Belegen durch eine Ereignisspur (Zeitstempel, Fakten vs. Annahmen, Entscheidungen, Maßnahmen, Wirksamkeitskontrolle).
  Eine gute Organisation produziert so eine Geschichte, die verschiedene Adressaten bedienen kann – ohne Widerspruch, ohne Doppelarbeit.

Resilienztests: Üben, wo es weh tut

Nichts ersetzt die Probe. Resilienz ist kein Formular, sondern eine Fähigkeit. Die Testlandschaft, die DORA und NIS2 im Ergebnis erwarten, folgt einem Muster:

• Technische Tests (Schwachstellen, Härtung, Konfiguration) in kurzen Zyklen.
• Funktionale Umschalt- und Wiederherstellungsübungen mit Integritätsbeleg auf Anwendungsebene.
• Szenariobasierte Übungen (Tabletop) für Entscheidungswege, Kommunikation, Priorisierungen.
• Angriffsnahe Tests dort, wo das Risikoprofil es verlangt – mit klaren Schutzgeländern.
  Wichtig sind Akzeptanzkriterien (RTO/RPO, Datenintegrität, Kommunikationszeiten) und Re-Tests. Testen ohne Nachschärfen ist Beschäftigungstherapie.

Lieferkette: Von Vertragstreue zu Steuerbarkeit

Sowohl DORA als auch NIS2 zwingen, eine unbequeme Wahrheit anzuerkennen: Auslagerung entbindet nicht von Verantwortung. Die Antwort ist Steuerbarkeit:

• Due Diligence vor Vertragsschluss (fachlich, technisch, finanziell, Resilienz).
• Informations- und Prüfungsrechte, die praktikabel sind (Attestierungen, geteilte Audits, technische Telemetrie).
• Meldepflichten bei Vorfällen und Transparenz über Sub-Dienstleister und Datenlokationen.
• Exit- und Portabilitätsregeln, die den Betrieb wirklich sichern (Datenformate, Unterstützungspflichten, Zeitfenster, Umschaltpfade).
• Monitoring, das auf Zahlen baut (SLA, Security-KPIs, Meldezeiten, Abweichungen) – und Eskalation, die wirkt.
  So wird aus einem Vertrag eine Führungsspur.

Identitäten und Rechte: „Identity first“ als Leitplanke

Kaum ein Bereich verbindet DORA- und NIS2-Welt so direkt wie IAM/PAM. Rechte sind der Schlüssel – zum Erfolg wie zum Desaster. Governance, die hält, baut auf:

• Rollenmodelle mit sauberer Funktionstrennung und begründeten, befristeten Ausnahmen.
• Lifecycle-Kopplung (Eintritt, Wechsel, Austritt) ohne Schattenlisten.
• Privilegienkontrolle mit Just-in-Time-Vergabe, Sitzungsaufzeichnung und Review.
• Rezertifizierung im Takt und mit Konsequenzen (Entzug veralteter Rechte).
• Nachweise aus Systemen statt Excel (Populationen, Freigabejournale, Logs verlinkt).
  Die Messgröße ist simpel: Wie schnell verschwinden Rechte nach Rollenwechsel? Wie oft nutzen wir Adminrechte? Wie viele Ausnahmen leben über die Frist hinaus? Diese Antworten entscheiden, ob eine Prüfung Vertrauen fasst – oder Zweifel.

Daten-Governance: Lineage statt Legenden

Zahlen sind die Sprache der Führung. Doch ohne Lineage sind sie Dialekte, die niemand versteht. DORA und NIS2 implizieren, was moderne Häuser ohnehin tun: Golden Sources festlegen, Transformationsregeln freigeben, Qualitätsschwellen definieren, Tickets für Verstöße erzeugen, Ursachen abstellen, Re-Checks durchführen. Wer so arbeitet, kann jede Kennzahl erklären – und überprüfen. Das ist mehr als Compliance; es ist Entscheidungsfähigkeit.

Metriken mit Führungskraft: Weniger Beruhigung, mehr Steuerung

Kennzahlen sind die Brücke vom Sachverhalt zur Entscheidung. Gute Governance nutzt wenige, harte Metriken – mit Schwellen, Ownern, Eskalationswegen, Fristen und Re-Checks:

• Erkennung/Behebung: MTTD/MTTR, Klassifizierungs- und Meldezeiten.
• Schwachstellen/Patches: Alterskurven, Remediation-Quoten, Ausnahmefristen und Kompensation.
• Wiederherstellung: Restore-Erfolgsquote, RTO/RPO-Einhaltung, Integritätsbelege.
• Identitäten: Rezertifizierungsquote, De-Provisioning-Dauer, Nutzung und Review privilegierter Sitzungen.
• Lieferkette: SLA-Compliance, Incident-Meldezeiten, Audit-/Assessment-Ergebnisse, Exit-Readiness.
• Kosten/FinOps: Kosten je Service/Transaktion, Budgetdrifts mit Alerting, Ursachenanalyse.
  Diese Zahlen sind kein Schmuck – sie lösen Entscheidungen aus.

Kohärenz als Königsdisziplin

Nichts zerstört Glaubwürdigkeit schneller als Widersprüche zwischen Quellen. Ein reifes Haus hat deshalb Kohärenz-Reviews im Takt: Risiko, Incidents, Tests, Lieferkette, Finanzen, Management-Report – alles auf den Tisch, Abweichungen als Tickets, Fristen, Verantwortliche, Re-Checks. Diese Routine ist unspektakulär – und gerade deshalb die stabilste Versicherung gegen Überraschungen.

Drei Archetypen – drei Routen, ein Ziel

Institut im Finanzsektor: DORA-Dichte hoch, NIS2-Reife als Horizont. Route: Resilienztests „von Infrastruktur zu Anwendung“, Incident-Backbone mit Multi-Adressierung, Lieferkette mit Telemetrie, IAM-PAM-Disziplin, FinOps als Risikohebel.

Versorger/Industrie unter NIS2: Breite, heterogene Landschaft. Route: Segmentierung, Use-Case-Überwachung, Restore auf Prozess-/OT-Ebene, Data-Lineage in Kernreports, Lieferkettensteuerung für SaaS/OT-Partner.

Digitaler Dienstleister mit Cross-Schnittstellen: Hohe Cloud-Anteile, viel API-Verflechtung. Route: Guardrails in der Landing Zone, Pipelines mit Policy-as-Code, API-Sicherheits-Use-Cases, Identity-first, Exit-Pfade pro Mandant.

Drei Routen – ein Ziel: steuerbare Resilienz, die man zeigen kann.

Roadmap 180 Tage: Vom Nebeneinander zum Betriebssystem

Monat 1–2
Design-Faktoren erheben (Geschäftsmodell, Sourcing, Regulierung, Bedrohung), kritische Services/Assets inventarisieren, Schutzbedarfe/Kritikalitäten festlegen, Mandate und Gremien mit Entscheidungsrechten verankern, Führungskennzahlen definieren.

Monat 3–4
Evidence-Baukasten aufbauen (systemische Exporte aus IAM, Incidents/Changes, Schwachstellen, Backups/Restores, Lieferkette), versionierte, unveränderliche Ablage, Populationsdefinitionen; Pipeline-Gates für die wichtigsten Risiken (IaC-Checks, Security-Tests, Rollback-Fähigkeit).

Monat 5
Restore-Übungen auf Anwendungsebene mit Integritätsbeleg, Tabletop-Übungen für Krisenwege und Meldungen, Scorecards mit Top-Dienstleistern, erstes Kohärenz-Review, CAPA-Backlog mit Fristen und Re-Checks, Multi-Adressierung im Incident-Backbone erproben.

Monat 6
Probe-Audit „Operating Effectiveness“ mit echten Stichproben; Lücken schließen; Re-Tests terminieren; Evidence-Tage und quartalsweise Kohärenz-Reviews institutionalisieren; Management-Reporting vollständig auf Metriken und Entscheidungen umstellen.

Danach ist Governance kein Projekt mehr, sondern Betriebsmodus. DORA- und NIS2-Themen laufen automatisch mit – weil der Kompass stimmt.

Anti-Patterns – und wie man sie vermeidet

• Policy ohne Pipeline: Hübsche Richtlinien, riskante Deployments. Gegenmittel: Guardrails, Gates, Ausnahmeprozess mit Fristen.
• Backups ohne Beweis: „Wir sichern“, aber niemand kann wiederherstellen. Gegenmittel: Restore-Test mit Integrität, Lessons Learned, Re-Test.
• IAM in Excel: Schattenlisten, schleppender Entzug. Gegenmittel: Systemkopplung, Rezertifizierung, JIT-PAM.
• Outsourcing als Vertrauensvotum: PDFs statt Telemetrie. Gegenmittel: Scorecards, Meldezeiten, Sub-Transparenz, Exit-Proben.
• Kennzahlen ohne Wirkung: Metriken als Tapete. Gegenmittel: Schwellen, Owner, Eskalation, Fristen, Re-Checks.
• Zwei Welten bauen: DORA und NIS2 separat. Gegenmittel: eine Governance-Erzählung, zwei Zuschnitte.

Kultur schlägt Katalog: Verhalten sichtbar machen

Am Ende entscheidet Kultur. Gute Häuser messen sie nicht in Stimmungsbildern, sondern in Verhaltensspuren: Quote rechtzeitig gemeldeter Near Misses; Zeit bis zur Eskalation eines Schwellenbruchs; Anteil fristgerecht geschlossener CAPA-Maßnahmen; Halbwertszeit von Ausnahmen; Häufigkeit und Qualität von Lessons Learned. Diese Zahlen sind härter als jede Selbsteinschätzung – und sie machen Kultur gestaltbar.

Ausblick: Governance als Motor statt Bremse

Zwischen DORA und NIS2 zeigt sich ein roter Faden: Resilienz vor Ritual, Evidenz vor Behauptung, Steuerung vor Symbolik. Wer diesen Faden aufnimmt, wird feststellen, dass Regulierung nicht nur Last ist, sondern Hebel. Sie zwingt zur Klarheit, zur Priorisierung, zur Automatisierung – und sie belohnt Häuser, die Entscheidungen auf Zahlen bauen und Verantwortung nicht delegieren, sondern wahrnehmen. Governance steht auf dem Prüfstand. Das ist gut so. Denn dort, wo sie standhält, entsteht mehr als Compliance: Vertrauen – intern, am Markt, bei der Aufsicht. Und Vertrauen ist die härteste Währung in einer Welt, in der alles andere schneller wird.