Neue Pflichten, alte Strukturen: Wo DORA Unternehmen überfordert

Neue Pflichten, alte Strukturen: Wo DORA Unternehmen überfordert

A uf dem Papier klingt alles logisch: Ein europäischer Rahmen, der digitale Resilienz messbar macht, Meldewege harmonisiert, Drittparteien in die Pflicht nimmt und das Silo-Denken zwischen IT, Betrieb, Einkauf und Compliance aufbricht. In der Praxis prallen diese neuen Pflichten auf alte Strukturen – gewachsene Organisationen, komplexe Lieferketten, Legacy-Systeme, projektgetriebene Budgets, fragmentierte Verantwortungen. Das Ergebnis ist vielerorts dasselbe Bild: ernsthafte Bereitschaft, viel Aktivität, lange To-do-Listen – und trotzdem das Gefühl, dass DORA wie ein Wellenbrecher immer neue Lücken in den Damm schlägt. Dieser Beitrag seziert, wo DORA Unternehmen überfordert, warum das so ist und wie sich der Knoten lösen lässt, ohne Dutzende Parallelprojekte zu starten, die am Ende nur mehr Papier produzieren.

1) Der Kern des Problems: DORA verlangt Fähigkeiten, nicht Formulare

Die erste Überforderung beginnt im Kopf: Viele Organisationen behandeln DORA wie eine weitere Compliance-Checkliste. Das ist bequem, aber falsch. DORA verlangt Fähigkeiten – erkennen, entscheiden, melden, wiederanlaufen, nachweisen – in klaren Zeitfenstern und über Bereichsgrenzen hinweg. Genau hier reibt sich die Verordnung an alten Mustern:

• Projektlogik statt Betrieb: Governance, Risikomanagement, Resilienztests und Incident Reporting werden als Vorhaben mit Start/Ende geplant. DORA verlangt jedoch Rhythmus: kontinuierliche Risiko-Reviews, laufende Kontrollüberwachung, geübte Meldeketten, regelmäßige Tests mit Lessons Learned.
• Dokument statt Evidenz: Richtlinien und Prozessbeschreibungen wachsen, aber Telemetrie, Metriken und protokollierte Entscheidungen fehlen. Auditoren sehen schöne PDFs – und stellen trotzdem Feststellungen, weil Wirksamkeit nicht belegt ist.
• Abteilungsdenken: IT härtet Systeme, Compliance sammelt Nachweise, Einkauf verhandelt Verträge, Fachbereiche optimieren Abläufe – jeweils korrekt in der eigenen Logik, aber inkonsistent im Gesamtbild.

DORA kippt die Frage: Nicht „Haben wir ein Verfahren?“, sondern „Funktioniert es unter Zeitdruck – und können wir das zeigen?“

2) Die zehn Reibflächen, an denen DORA mit Wucht auf alte Strukturen trifft

2.1 Register of Information (RoI): Inventar oder Inventurhölle?

Das RoI klingt einfach: alle IKT-Drittparteien, Services, Abhängigkeiten, Kritikalitäten, Standorte, Verträge, Melde- und Ausstiegsrechte – vollständig, aktuell, prüffähig. In der Praxis kollidiert das mit verstreuten Vertragsarchiven, Excel-Listen, Schattenservices in Fachbereichen, gewachsenen Multi-Provider-Setups und Eigenentwicklungen mit Open-Source-Komponenten.

Überforderung entsteht, wenn man das RoI als einmalige Mammut-Inventur angeht. Drei Monate später ist es veraltet. DORA will einen lebenden Katalog, der aus den Betriebsprozessen heraus gepflegt wird (Einkauf, Onboarding, Change, Offboarding). Alte Strukturen liefern stattdessen Stichtagslisten.

2.2 Kritische Funktionen: Semantik-Streit statt Steuerung

„Kritisch“ ist kein Etikett, sondern eine verbindliche Kategorie mit Folgen (Meldepflicht, Testtiefe, Governance-Fokus). Viele Häuser diskutieren zu lange über Begriffe, statt klare Entscheidungsregeln festzulegen (z. B. Toleranzzeit, regulatorischer Impact, Kundenwirkung, Substitutierbarkeit).

Die Überforderung zeigt sich in Wunschlisten („Lieber alles kritisch!“, um auf der sicheren Seite zu sein) oder im Gegenteil – Schönrechnen, weil man die Folgekosten (Tests, Slicing, Redundanz) scheut. DORA verlangt Begründungen – und die halten nur, wenn Metriken existieren (z. B. maximal tolerierbare Ausfallzeit, Transaktionsvolumen, Abhängigkeiten).

2.3 Incident Reporting: Tempo frisst Hierarchie

DORA kennt Fristen. Das kollidiert mit Freigabekaskaden, Schweigekultur und unscharfen Zuständigkeiten. Alt: „Wir klären intern, dann melden wir mit fertigem Bild.“ Neu: Frühwarnung, Zwischenberichte, Abschluss – faktenbasiert, auch unter Unsicherheit.

Überforderung entsteht, wenn das Meldewesen als Rechts- oder PR-Thema behandelt wird. Es ist ein Operations-Thema mit juristischer Flankierung. Ohne geübte Entscheidungsschritte („triage → impact → threshold → notify“) und ohne formalisierte Inhalte (Standardformate, klare Auslösekriterien) reißt die Zeitkette.

2.4 Resilienztests: Übungen statt Zertifikate

Viele Unternehmen sind Penetrationstests gewohnt. DORA will mehr: funktionale Tests (Backups, Failover, Umschaltprozesse), szenariobasierte Übungen (Tabletops) und – für Risikoprofile – Threat-Led Penetration Tests (TLPT). Das fordert Organisation: Testplan, Auswahl nach Risiko, Einbindung von Drittparteien, Nachbereitung mit Maßnahmen.

Überforderung entsteht, wenn Tests als „Show für den Auditor“ gedacht werden. DORA erwartet Lerneffekte: Wiederholte Schwächen ohne Maßnahmen sind ein Alarmsignal. Alte Strukturen produzieren Berichte; neue Resilienz baut Fähigkeiten.

2.5 Drittparteien-Steuerung: Vertrag ≠ Kontrolle

„Wir haben einen Vertrag“ reicht nicht. DORA verlangt laufendes Monitoring, Melde- und Forensikrechte, Exit-Strategien und Evidenz (Sicherheitsmetriken, PSIRT-Feeds, Audit-Pfade). Alte Strukturen verlassen sich auf Zertifikate („ISO liegt vor“) und Jahresgespräche.

Überforderung entsteht, wenn Einkauf, Fachbereich, IT und Security nicht gemeinsam führen. Ein Provider kann SLAs erfüllen – und trotzdem resilienzschwach sein (zögerliches Patchen, späte Kommunikation, keine Portabilität). DORA fragt: „Wie schnell können Sie wechseln? Welche Daten erhalten Sie während des Vorfalls?“

2.6 Governance & Rollen: Schattenverantwortung

Viele Richtlinien nennen „die IT“ oder „die Fachbereiche“. DORA verlangt namentliche Verantwortliche, Gremien, Eskalationspfade – und Entscheidungen innerhalb von Fristen. Überforderung entsteht, wenn RACI-Matrizen entweder zu grob (alles „gemeinsam“) oder zu fein (Lähmung) sind. Wichtig ist, dass eine Person die Rolle „Incident Decision Lead“ hat, eine den „Regulator Liaison“, eine den „Third-Party Command“. Alte Strukturen scheuen Namen – DORA fordert sie.

2.7 Evidenzlücke: Schöne Worte, keine Daten

DORA prüft Wirksamkeit. Ohne Continuous Controls Monitoring (CCM), ohne laufende Metriken (z. B. Mean Time to Detect/Decide/Recover, Patch-Lag, Slice-Latenz P99, Drift-Rate bei KI) bleibt man im Behauptungsmodus. Alte Strukturen liefern „haben wir“, neue Pflichten fordern „zeigen Sie“.

Überforderung entsteht, wenn Observability als „Nice to have“ behandelt wird. Tatsächlich ist sie das Rückgrat: Dieselben Daten, die Betrieb steuern, füttern die Prüfung. Wer das trennt, verdoppelt den Aufwand – und verliert Zeit.

2.8 Daten-Governance: Zweckbindung vs. Analytik-Hunger

DORA berührt Datenschutz nicht nur indirekt. Wer Edge/Cloud mischt, KI in Incident-Analytik nutzt oder Resilienzbewertungen mit Kundendaten koppelt, muss Zweck, Rechtmäßigkeit, Minimierung und Retention sauber steuern. Alte Strukturen: Datenlandkarten als Projektartefakte. Neue Pflicht: lebendige Lineage, automatische Lösch- und Pseudonymisierungspfade.

Überforderung entsteht, wenn Datenschutz als „interne Hürde“ statt als Architekturfrage behandelt wird. Ohne Privacy-by-Design wird Resilienz verzögert – und Meldeketten blockieren.

2.9 Finanzierung & Proportionalität: Alles wichtig – kein Budget

DORA betont den Proportionalitätsgrundsatz – aber er wird oft missverstanden. Proportional heißt nicht „so viel wie möglich sparen“, sondern „risikogerecht investieren“. Alte Budgetlogik: CapEx-Projekte, kaum OpEx für Betrieb von Governance-Fähigkeiten. DORA braucht laufende Mittel: Monitoring, Übungen, Pflege des RoI, Vertragsführung.

Überforderung entsteht, wenn CFOs Checklisten finanzieren wollen, nicht Rhythmen. Wer das Ziel falsch setzt, zahlt doppelt: erst in hektischen Nachbesserungen, dann in Sanktionen/Schäden.

2.10 Kultur: Schweigen, Schönerklären, Schuldverschieben

Der unangenehmste Punkt: DORA erwartet frühe, unvollkommene, aber ehrliche Kommunikation – intern, gegenüber Behörden, gegenüber Kunden, gegenüber Partnern. Alte Muster belohnen Perfektion und Kontrolle; neue Pflichten belohnen Tempo und Transparenz. Überforderung entsteht, wenn Menschen Angst haben, unbequeme Wahrheiten zu melden. Ohne psychologische Sicherheit wird DORA zur Drohkulisse – und erzeugt genau das Verhalten, das Vorfälle eskalieren lässt.

3) Anti-Patterns: So scheitern Programme zuverlässig

• „Großprojekt RoI“: Drei Monate Vollgas, tausend Zeilen Excel, ein „finaler Stand“ – und niemand baut die Pflege in Einkauf, Onboarding, Change ein. Ergebnis: Nach sechs Wochen veraltet, nach drei Monaten unbrauchbar.
• „Alles kritisch“: Sicherheitsreflex gegen jede Diskussion – und danach kollabieren Testpläne, weil Kapazität fehlt.
• „Incident = PR-Fall“: Kommunikationsabteilung dominiert, Fakten dünn, Freigabe stammt aus fünf Vorstandsebenen. Fristen reißen, Vertrauen sinkt.
• „TLPT als Gütesiegel“: Einmal angreifen lassen, Bericht abheften, keine Lessons Learned umsetzen. Nächstes Jahr dieselben Findings.
• „ISO löst alles“: Zertifikat in die Ausschreibung, Augen zu. Kein PSIRT-Feed, keine Forensikrechte, kein Exit.
• „Observability später“: Erst Prozesse, dann Daten – nur kommen die Prüfungen und Vorfälle vorher.
• „Proportional = Sparen“: Minimalvarianten bei kritischen Pfaden, keine Übungen, keine Slicing-Isolation – bis der erste echte Test kommt.

4) Gegenmuster: Was funktioniert – ohne den Laden stillzulegen

4.1 Vom Stichtag zum System: RoI als Nebenprodukt von Betrieb

• Single Source: Ein zentrales, versioniertes RoI-Repository (Ticket/CMDB/Contract-DB verknüpft), keine Schattenlisten.
• Ereignisgetrieben: Jeder neue Vertrag, jede Änderung, jedes Offboarding triggert RoI-Updates mit Prüfschritt.
• Kritikalität in den Prozess: Einstufung ist kein Workshop, sondern Formular mit Regeln (z. B. Toleranzzeit, Kundenimpact, regulatorischer Bezug).

4.2 Kritische Funktionen: Entscheidungsbaum statt Debatte

• Kriterienkatalog: Tolerable Ausfallzeit, Prozessdurchsatz, Ersatzfähigkeit, regulatorische Abhängigkeit – punktbewertet.
• Grenzwerte: Automatische Vorschläge, finale Entscheidung im Governance-Gremium mit Begründung.
• Review-Rhythmus: Halbjährlich – und ereignisgetrieben bei Prozess-/Technologieänderungen.

4.3 Melden üben: „Time to Decide“ als KRI

• Dreistufiges Reporting: Frühwarnung (Fakten + Unsicherheiten), Zwischenbericht (Hypothesen + Maßnahmen), Abschluss (Ursachen + Lessons Learned).
• Formate & Schwellen: Vorlagen mit Pflichtfeldern; Schwellen als Policy-as-Code (z. B. betroffene Kunden > X → Meldung).
• Tabletops: Quartalsweise mit Rechts-/PR-/Ops-Teams, echte Zeitfenster, echte Adressatenlisten.

4.4 Resilienztests: 70/20/10-Mix

• 70 % technische Standardtests (Scans, Patches, Backups, Failover) – automatisiert, mit Kennzahlen.
• 20 % Tabletop-Übungen – entscheidungslastig, cross-funktional.
• 10 % anspruchsvoll (TLPT/szenariobasiert) – dort, wo Risiko es verlangt.
• Pflicht: Maßnahmenliste mit Verantwortlichen und Terminen; Wiederholungsprüfung von „Dauerschwächen“.

4.5 Drittparteien führen: Vier harte Klauseln

• PSIRT & SBOM/VEX: Pflicht-Feeds, Reaktionsfristen, Zustellgarantie (nicht „Newsletter“).
• Forensik & Auditfeeds: definierte Log- und Metriklieferungen im Vorfall; technische Schnittstellen, kein PDF-only.
• Interconnect-Tests: halbjährlich; Beweis, dass man bei Störung gemeinsam handeln kann (Kontaktwege, Notabschaltung, Datenpfade).
• Exit-Probe: jährlich light; Zeit/Schritte/Portabilität messen (Daten + Konfiguration).

4.6 Evidenz industrialisieren: „Time to Proof“ als Steuergröße

• CCM für Top-Kontrollen (Zugriff, Change, Backup, Segmentierung, Slicing/Netz, Patch).
• Kennzahlen: MTTD, MTTDecide, MTTR, Patch-Lag, Anteil rote Ampeln ohne Reaktion > X min, PSIRT-Signal-Lag, Kritikalitäts-Drift.
• „Time to Proof“: Ziel, relevante Nachweise binnen 48 Stunden qualitätsgesichert zu liefern.

4.7 Kultur konkret: Drei Sätze, die wirken

• „Frühe Wahrheit schlägt späte Perfektion.“ Melden schützt – Vertuschen schadet.
• „Jeder Fehler hat genau einen Besitzer: die Organisation.“ Keine Schuldspiele, sondern Verbesserungen.
• „Üben ist Pflicht.“ Kein Meeting-Schmuck: Termine im Kalender, Teilnahme im Zielbild der Führung.

5) Praxisbilder: Wie sich die Überforderung auflöst

Bank mit gewachsener Providerlandschaft
Ausgangslage: 120+ aktive Verträge, RoI als Excel, Incident-Freigaben auf drei Vorstandsebenen.
Dreh: RoI in CMDB/Ticket integriert; PSIRT/SBOM-Klauseln nachverhandelt; Incident-Playbook mit „Time to Decide ≤ 2h“; Tabletop-Serie; TLPT auf Zahlungsverkehr.
Effekt: Erstmeldungen innerhalb von 3 h zuverlässig, PSIRT-Signal-Lag von 9 Tagen auf 48 h, Exit-Probe für Kernanbieter in 5 Tagen machbar, Feststellungen im Audit halbiert.

Versicherer mit heterogener Legacy
Ausgangslage: Viel Schriftkultur, wenig Telemetrie; Tests projektgetrieben.
Dreh: 70/20/10-Testmix; CCM für Zugriff/Backup/Change; „Time to Proof“ 72 h; RACI gestrafft (drei benannte Leads); Datenflüsse für Meldungen harmonisiert.
Effekt: Weniger Überraschungen, schnellere Wiederanläufe, weniger „rote Ampeln ohne Reaktion“, Auditoren loben Konsistenz statt Dichte.

Asset Manager mit Cloud-Fokus
Ausgangslage: Starkes Outsourcing, Verträge „ISO-sauber“, Forensikrechte schwach.
Dreh: Nachverhandelte Auditfeeds, forensische Pfade, Interconnect-Tests mit Provider; KI-Drift-Monitoring in Risikoprozessen; Incident-Dossiers standardisiert.
Effekt: Bessere Verhandlungsposition, glaubhafte Governance, kürzere Klärungszeiten im Vorfall, realistische Proportionalität.

6) Messgrößen, die den Unterschied machen

• Resilienz:
  • Mean Time to Detect (MTTD), Mean Time to Decide (MTTDecide), Mean Time to Contain (MTTC), Mean Time to Recover (MTTR) je Kritikalitätsklasse.
  • Drill-Quote: Anteil geübter Meldeketten p. Quartal.
• Kontrollwirksamkeit:
  • Anteil Top-Kontrollen mit Echtzeit-Überwachung.
  • Anteil „rote Ampeln“ mit Reaktion binnen Schwelle.
• Drittparteien:
  • PSIRT-Signal-Lag, Forensik-Bereitstellzeit, Exit-Probe-Dauer (Daten + Konfiguration), Shadow-Run-Fähigkeit.
• Daten/KI:
  • Lineage-Abdeckung kritischer Daten, Retention-Treue, Drift-Rate in Modellen, Time-to-Oversight bei KI-Alerts.
• Auditfähigkeit:
  • Time to Proof, Feststellungs-Wiederholquote, Konsistenzscore (Deckung zwischen Risiko, Test, Vorfällen, Verträgen).

Diese Kennzahlen sind kein Schmuck, sondern Schalthebel: Wer sie auf C-Level-Dashboards setzt, zwingt Governance in den Betrieb.

7) Proportionalität ohne Selbstbetrug: Vier Fragen, die genügen

1. Wie hoch ist der Impact eines Ausfalls – fachlich, regulatorisch, reputativ?
2. Wie oft passiert es realistisch – und wie früh sehen wir es?
3. Wie schnell müssen wir wieder handlungsfähig sein – und haben wir es geübt?
4. Wie abhängig sind wir von Dritten – und wie gut führen wir sie?

Wer diese Fragen zahlenbasiert beantwortet, ist proportional – und auditfest. Wer sie erzählt, tappt früher oder später in die Überforderung.

8) Der 120-Tage-Plan gegen die DORA-Erschöpfung

Tag 1–30: Klarheit schaffen

• RoI-Minimalviable: nur kritische Anbieter/Services, aber richtig verknüpft (Vertrag, System, Prozess, Kritikalität).
• RACI in drei Rollen benennen: Incident Decision Lead, Regulator Liaison, Third-Party Command.
• Drei KRIs definieren: Time-to-Decide, PSIRT-Signal-Lag, Exit-Probe-Dauer.

Tag 31–60: Melden & Messen operationalisieren

• Frühwarn-/Zwischen-/Abschluss-Vorlagen; Schwellen als Policy-as-Code.
• CCM für Zugriff/Change/Backup starten; „Time to Proof“ Ziel 72 h.
• Erste Tabletop-Runde: Lieferkettenvorfall + Datenpanne kombiniert.

Tag 61–90: Drittparteien führen

• Nachverhandeln: PSIRT-Feeds, Forensikrechte, Interconnect-Testpflicht, Exit-Probe light.
• Schnittstellen technisch aufsetzen (Logfeeds, Metriken, sichere Kanäle).

Tag 91–120: Resilienz testen & schließen

• 70/20/10-Testmix fahren; Maßnahmenliste mit Terminen.
• Zweite Tabletop-Runde: Meldeketten unter Gegenwind (Wochenende, Teil-Ausfall).
• Review auf Vorstandsebene: KRIs, Lückenplan, Budget-Shift von Projekten zu Betrieb.

Ergebnis: weniger Papier, mehr Funktion – und ein Team, das unter DORA nicht mehr improvisiert, sondern führt.

9) Fazit: DORA überfordert dort, wo Organisationen sich selbst überfordern

DORA ist nicht „zu viel“, es ist radikal ehrlich: Zeig mir, dass du kannst, was du behauptest. Alte Strukturen fühlen sich davon bedroht, weil sie auf Erzählungen gebaut sind – Projektpläne, Richtlinien, Zertifikate. Neue Pflichten wollen Evidenz – Metriken, Entscheidungen, Übungen, Nachweise.

Die gute Nachricht: Sobald Unternehmen Governance als Betriebsfunktion und nicht als Dokumentenfabrik verstehen, kippt das Gefühl der Überforderung. Der gleiche Aufwand erzeugt plötzlich Klarheit, der gleiche Testlauf erzeugt Fähigkeit, der gleiche Vertrag erzeugt Führung.

„Neue Pflichten, alte Strukturen“ ist dann keine Klage mehr, sondern der Startschuss für den Umbau, den viele ohnehin brauchen: vom Projekt zur Praxis, von der Pflicht zur Profession, von der Kontrolle zur Kompetenz. Genau dort – im gelebten Alltag – erfüllt DORA seinen Zweck. Und genau dort ist die Überforderung vorbei.