Warum DORA mehr als nur ein weiteres Regelwerk ist
Mit dem Inkrafttreten des Digital Operational Resilience Act (DORA) für Institute und Finanzdienstleister hat die Europäische Union einen entscheidenden Schritt zur Harmonisierung und Stärkung der IT-Sicherheits- und Resilienzanforderungen gesetzt. DORA formuliert einen einheitlichen regulatorischen Rahmen, der die „operational resilience“ – also die Fähigkeit, IT-bezogene Störungen und Angriffe zu bewältigen – sicherstellen soll.
Für Institute bedeutet dies nicht nur Compliance, sondern eine signifikante Änderung im Umgang mit IT-Risiken, der Dienstleistersteuerung und der internen Kontrollsysteme. Aufgrund der Komplexität und des regulativen Drucks war und ist die Umsetzung für viele Institute eine Herausforderung. Es zeigt sich, welche Hürden Institute überwinden müssen, welche Lösungsansätze sich etabliert haben – und wo weiterhin Herausforderungen bestehen.
Typische Herausforderungen bei der Umsetzung
Die Umsetzung von DORA entpuppte sich in der Praxis als vielschichtiger Prozess mit zahlreichen Reibungspunkten:
1. Organisation und Governance
Eine der ersten Hürden lag in der klaren Zuordnung von Verantwortlichkeiten. Vielfach eröffnete sich in den Instituten die zentrale Frage, wie die neuen Anforderungen organisatorisch sinnvoll zu verankern sind. Die Notwendigkeit, eine klare Verantwortlichkeit für das Informations- und-Kommunikationstechnologie(IKT)-Risikomanagement zu etablieren, führte zu Konflikten zwischen Risikomanagement, IT und Compliance. Denn oft sind IT-Sicherheit, Compliance und Risikomanagement getrennte Bereiche, die nun erstmals eng zusammenarbeiten müssen.
Die größte Schwierigkeit bestand darin, Rollen und Prozesse so zu gestalten, dass sie sowohl den regulatorischen Vorgaben entsprechen als auch praxistauglich und effizient bleiben. Das Etablieren eines übergreifenden Governance- Frameworks erwies sich als erfolgskritisch.
Hinzu kam die Identifikation von kritischen/wichtigen Funktionen: Kriterien waren häufig uneinheitlich, Verantwortungen unklar, Schnittstellen zu BCM/Outsourcing nicht wiederspruchslos abgestimmt.

Praxisempfehlungen
- RACI und Mandate: Formale Mandate und RACI-Matrix für DORA-Rollen (inklusive 3LoD-Verzahnung, IKT-Risiko-Owner, Service-Owner) verbindlich beschließen.
- Entscheidungsgremium: „Resilience Board“ mit klaren Eskalationswegen (Incident-, Change-, Test- und TPRM-Themen) etablieren.
- Kriterienkatalog „kritisch/wichtig“: Einheitliche, prüfbare Kriterien (zum Beispiel Impact auf Geschäftsprozesse, Kunden, Markt, Regulatorik) definieren; Schwellenwerte dokumentieren und jährlich reviewen.
- Governance-Verzahnung: Schnittstelle zu BCM, Notfallmanagement, Outsourcing und Informationssicherheit schriftlich fixieren (Policy-Landkarte).
2. IT-Landschaft und Schnittstellen
IT-seitig brachte DORA die Herausforderung mit sich, neue Anforderungen zur Überwachung und Absicherung der IT-Systeme in heterogene Architekturwelten einzubinden. DORA verlangt Transparenz über kritische Systeme und Prozesse. Doch in heterogenen IT-Landschaften mit gewachsenen Alt- Systemen war es herausfordernd, eine konsistente Sicht zu schaffen. Besonders die Forderungen zur Erkennung und Meldung von Vorfällen (ICT Incident Reporting) und der Ausbau von Testverfahren wurden durch Legacy-Systeme erschwert. Die Erstellung von End-to-end-Übersichten über kritische Services wurde häufig unterschätzt und machte aufwendige Abstimmungen zwischen Fachbereichen und IT erforderlich. Zusätzliche Komplexität entstand beim IKT-Asset-Register (vollständiger Scope inklusive SaaS-/APIs-/ Identitäten-/Cloud-Ressourcen) und dessen Verknüpfung mit der Prozesssicht.

Praxisempfehlungen
- Golden-Source-Ansatz: CMDB als führende Quelle definieren und IKT-Asset-Register daraus ableiten; eindeutige, versionierte IDs nutzen.
- E2E-Sicht: Rückverfolgbarkeit von Funktion → Prozess → Anwendung → Infrastruktur → Datenobjekte herstellen; Abhängigkeiten automatisiert inventarisieren.
- API-/SaaS-Scope: APIs, Integrationsflüsse, privilegierte Identitäten, Cloud-Ressourcen/Regionen ausdrücklich in das Register aufnehmen.
- Incident-Datenpfad: Technische Telemetrie (SIEM, Monitoring) mit Fach-Incident-Prozessen verbinden, um Berichtspflichten automatisiert zu bedienen.
3. Dienstleistersteuerung und Third-Party-Risk-Management
Ein Kernpunkt von DORA ist die Kontrolle über ausgelagerte IT-Dienstleistungen. DORA verlangt ein engmaschiges Überwachungs- und Eskalationssystem, das vielfach erst entwickelt werden musste. Besonderes Augenmerk lag auf der Einhaltung von Service Level Agreements (SLAs) und der Durchführung von regelmäßigen Audits bei diesen Dienstleistern.
Darüber hinaus mussten Institute feststellen, dass bestehende Verträge nicht die geforderte Detailtiefe in Bezug auf Resilienz, Reporting oder Prüfungsrechte aufwiesen. Insbesondere die Nachverhandlung mit großen IT- und Cloud-Anbietern gestaltete sich herausfordernd. Zusätzlich forderte DORA ein aktuelles Informationsregister über IKT-Dienstleistungen und -Verträge (inklusive Unterbeauftragungen), das in vielen Häusern erst konsolidiert werden musste.

Praxisempfehlungen
- Informationsregister professionalisieren: Objektklassen (Dienstleister, Service, Vertrag, Subdienstleister) trennen, Pflichtfelder und Validierungsregeln definieren.
- Vertrags-Playbook: Standard-Klauselbibliothek (Auditrechte, Resilienz-KPIs, Datenlokation, Exit/Portabilität, Weiterverlagerung) für Neu- und Änderungsverträge.
- Risikobasierte Steuerung: Kritikalität nach „kritisch/ wichtig“ auf Dienstleistungsebene abbilden; Intensität von Due Diligence, Monitoring und Tests daran koppeln.
- Evidenzführung: Meeting-Logs, KPI-Trends, Findings-Tracking revisionssicher dokumentieren, um Aufsichtsnachweise zu vereinfachen.
4. Reporting und Metriken
Die regulatorisch geforderte regelmäßige Berichterstattung über ICT-Risiken stellte viele Institute vor Probleme. Die Implementierung der umfangreichen Berichtspflichten inklusive automatisierter Datenlieferung an Aufsichtsbehörden erfordert tiefgreifende Anpassungen in den internen Prozessen.
Viele Institute unterschätzten den Aufwand, Datenqualität und Schnittstellen für das Incident Reporting zu gewährleisten. Oft mangelte es an konsistenten Kennzahlen und einer belastbaren Datenbasis, sodass Resilienz kaum objektiv messbar war. Häufige Lücken: schwache Datenqualität im Informationsregister sowie fehlende Konsistenz zwischen IKT-Asset-Register, CMDB und Reporting-Schichten.

Praxisempfehlungen
- KPI/KRI-Set: Wenige, aussagekräftige Resilienzkennzahlen definieren (z. B. MTTD/MTTR, Test-Coverage kritischer Services, Lieferanten-Conformance-Rate).
- Data-Controls: Technische und prozessuale DQ-Kontrollen (Pflichtfelder, Referenzwerte, Dubletten-Checks) für Asset- und Informationsregister verankern.
- Automatisierung: ETL-Strecken vom Monitoring/ CMDB in das Reporting industrialisieren; manuelle Exporte vermeiden.
- Incident-Taxonomie: Einheitliche Schweregrade/ Schwellen über alle Einheiten anwenden, um Berichte vergleichbar zu machen.
5. Testverfahren und Krisenübungen
Für die regelmäßigen ICT-Stresstests, Krisen-/Notfallübungen und Penetrationstests nach DORA mussten geeignete Szenarien definiert und abgestimmt werden. Dabei zeigte sich, dass der Transfer von theoretischen Anforderungen in praxisnahe und aussagekräftige Tests ein häufig unterschätztes Komplexitätselement ist. Während viele Institute im Bereich Cybersecurity bereits Erfahrungen hatten, war die Planung integrierter Resilienztests, die auch Geschäftsprozesse und Dienstleister einbeziehen, für viele Neuland.

Praxisempfehlungen
- Testkanon: Standard-Szenarienbibliothek (z. B. Provider-Ausfall, Major-Incident, Datenkorruption, Ransomware, Cloud-Region-Failover) je Kritikalitätsklasse.
- Integriert testen: Fachbereiche, IT-Betrieb, Dienstleister, BCM und Krisenstab gemeinsam testen; Lessons Learned verbindlich in Maßnahmen überführen.
- Coverage-Steuerung: Testabdeckung und Tiefe nach Kritikalität und Abhängigkeiten aus dem IKT-Asset-Register priorisieren.
- Realitätsnahe Metriken: Erfolgsmaß, z. B. Wiederanlaufzeit, Kommunikationslatenz, Entscheidungsgeschwindigkeit und Datengenauigkeit.
Lessons Learned und Erfolgsfaktoren: Was sich in der Praxis bewährt hat
In der Praxis haben sich mehrere Muster herauskristallisiert, die für den Erfolg entscheidend waren:
1. Frühzeitige und ganzheitliche Einbindung aller Stakeholder
Eine integrative Steuerung, zum Beispiel mittels einer dedizierten DORA-Taskforce, die IT, Compliance, Risikomanagement, Auslagerungsmanagement, Revision und Fachbereiche von Anfang an zusammenbringt und klare Kommunikationsstrukturen etabliert, erleichtert Koordination und Fortschrittskontrolle.

Praxisempfehlungen
- Stakeholder-Map und Kommunikationsplan mit festen Entscheidungs- und Eskalationspunkten.
- No-surprises-Rituale: zweiwöchentliche Cross- Function-Syncs mit 30-Minuten-Entscheidungsfenster.
- Revisions-Einbindung als Sparringspartner in Planung, Testing und Abnahme.
2. Frühzeitige Governance-Entscheidungen
Ein wesentliches Erfolgsrezept war es, frühzeitig klare Verantwortlichkeiten zu schaffen. Institute, die ein zentrales Steuerungsgremium für DORA eingerichtet haben, konnten Doppelarbeit und Reibungsverluste vermeiden. In der Praxis funktionierte dies am besten über eine „Taskforce Resilienz“, die Vertreter aus IT, Risiko, Compliance, Auslagerungsmanagement und Fachbereichen zusammenführte.

Praxisempfehlungen
- DORA-Policy-Set (Governance, TPRM, Tests, Incident, Reporting) mit eindeutiger Normenhierarchie.
- Jährliche Bestätigung: Managementbestätigung zur Wirksamkeit zentraler DORA-Kontrollen.
3. Prozesse in den Mittelpunkt stellen
Die Fokussierung auf Prozesse – statt auf isolierte Systeme – erwies sich als entscheidender Schritt zum Erfolg. Wer ausgehend von kritischen Prozessen alle technischen und organisatorischen Abhängigkeiten erfasste, erhielt ein belastbares Bild von Resilienzrisiken. Dadurch wurden auch Altlasten in der IT-Landschaft sichtbar, die bislang keine Priorität hatten.

Praxisempfehlungen
- Service-Blueprints für kritische/wichtige Funktionen: E2E-Flüsse inklusive Auslagerungen und Datenobjekten.
- Kill-a-Legacy-Backlog: gezielte Stilllegung hochrisikobehafteter Altkomponenten.
4. Modularer Umsetzungsansatz mit priorisierten Quick Wins
Viele Institute sind mit einer sehr umfangreichen Gap-Analyse gestartet, die sich im Verlauf als kaum handhabbar erwies. Erfolgreicher waren Institute, die zunächst eine pragmatische Bestandsaufnahme vornahmen. Die Umsetzung erfolgte dann in kleinen, klar priorisierten Schritten. Die Konzentration auf schnell realisierbare Verbesserungen (zum Beispiel bei Incident Management oder Dienstleistersteuerung) steigerten die Akzeptanz und erleichterten den späteren Ausbau. Zudem konnte der Projektdruck reduziert werden.

Praxisempfehlungen
- 90-Tage-Wellen: je Welle klare Ziele (z. B. Informationsregister-DQ > 98 %, Incident-SLA-Trefferquote > 95 %).
- Show, don’t tell: frühe Dashboards/Heatmaps für Managementsichtbarkeit.
5. Strukturiertes Third-Party- Risikomanagement etablieren
Ein zentrales Hindernis war die Anpassung der Auslagerungsverträge. Da Vertragsnachverhandlungen mit großen Providern oft nur begrenzt möglich waren, setzten Institute verstärkt auf Kompensationsmaßnahmen: etwa zusätzliche Monitoring- Prozesse, interne Notfallpläne oder abgestufte Testverfahren. Die Implementierung eines standardisierten Katalogs an Compliance-Kriterien und Eskalationsprozessen stärkte die Steuerungsfähigkeit deutlich. Entscheidend war dabei die sorgfältige Dokumentation, um gegenüber der Aufsicht die Nachvollziehbarkeit zu sichern.

Praxisempfehlungen
- Tiering-Modell für Provider (kritisch/wichtig/Sonstige) mit abgestuften Kontrollen.
- Weiterverlagerung transparent machen: Sub- Chain im Informationsregister pflegen; Exit-Drills durchführen.
6. Tests als Lerninstrument nutzen
DORA schreibt neben Prüfungen auch Krisensimulationen vor. Institute, die diese Übungen nicht als Pflicht, sondern als Lernchance verstanden, konnten ihre Abläufe realitätsnah erproben. Die Definition realistischer Testfälle, die tatsächliche Betriebsrisiken abbilden, wurde als Schlüsselfaktor identifiziert.
Das Einbinden von Penetrationstest-Teams und operativen Leitungen führte zu wertvollen Erkenntnissen über Systemschwächen. Besonders wertvoll war die gemeinsame Durchführung mit Dienstleistern in solche Tests – auch wenn dies organisatorisch aufwendig war.

Praxisempfehlungen
- Red-Team-/Blue-Team-Formate kombinieren; Post-mortems mit „Blameless“-Kultur.
- Test-Findings in zentrales Maßnahmen-Tracking mit Owner und Fälligkeit.
7. Resilienz in die Unternehmenskultur tragen
DORA erfordert nicht nur Prozesse und Dokumente, sondern ein neues Mindset. Technische Maßnahmen reichen allein nicht aus. In den erfolgreicheren Projekten wurde das Thema Resilienz aktiv kommuniziert, in Trainings verankert und von der Führungsebene sichtbar unterstützt. Dadurch wurde Resilienz vom Compliance-Thema zu einem Bestandteil der Unternehmenskultur.

Praxisempfehlungen
- Micro-Learning-Reihe (Fünf-Minuten-Snacks) zu DORA-Grundlagen, Incident-Erstmeldung, Lieferantenpfad.
- Führungskräfte-Scorecard mit Resilienz-KPIs (z. B. Testteilnahme, Time-to-Decision).
Auswirkungen auf Banken und Finanzdienstleister
Strategische Perspektive
Resilienz wird zum Wettbewerbsfaktor. Institute, die ihre kritischen Services klar verstehen und robuste Strukturen aufbauen, können schneller auf Störungen reagieren und das Vertrauen von Kunden und Aufsicht stärken. DORA zwingt dazu, Abhängigkeiten von großen IKT-Dienstleistern kritisch zu bewerten.

Praxisempfehlungen
- Sourcing-Strategie mit aktivem Multi-Vendor-beziehungsweise Multi-Region-Design für kritische Services.
- Portfolio-Priorisierung: Investitionen an Kritikalität und Schwachstellen-Heatmap ausrichten.
Operative Perspektive
Die Prozesse zur Risiko- und IT-Steuerung wurden neu geordnet. Besonders das Zusammenspiel zwischen Risiko-, IT- und Fachbereichen wird künftig enger. Die stärkere Einbindung von Auslagerungsmanagement und die systematische Durchführung von Tests führen zu einem höheren Ressourceneinsatz – der sich aber langfristig in einer stabileren Betriebsfähigkeit niederschlägt.

Praxisempfehlungen
- Run-Book-Standardisierung pro kritischem Service (inklusive Kommunikationsmatrix, manueller Workarounds).
- Control-Ownership: Jeder Schlüsselkontrolle einen klaren Owner mit Vertretung zuordnen.
Technologische Perspektive
DORA beschleunigt die Modernisierung der IT-Landschaften. Um Abhängigkeiten klar zu dokumentieren und Resilienz messbar zu machen, investieren Institute verstärkt in CMDB-Systeme, Monitoring-Lösungen und Automatisierung. Mittel- bis langfristig wirkt die Verordnung daher als Treiber für IT-Standardisierung und Konsolidierung.

Praxisempfehlungen
- CMDB-first“: Architektur- und Change-Prozesse an die Datenqualität des IKT-Asset-Registers koppeln.
- Observability-Roadmap: Metriken, Logs, Traces als Pflicht für kritische Services; Self-Service-Dashboards für Fachbereiche.
Kulturelle Perspektive
Ein oft unterschätzter Effekt ist der kulturelle Wandel. Resilienz ist kein reines Spezialistenthema mehr, sondern Teil des unternehmensweiten Selbstverständnisses. Beschäftigte aus Fachbereichen erkennen zunehmend, dass ihre Handlungen direkte Auswirkungen auf die Widerstandsfähigkeit des Instituts haben. Dies führt zu einer stärkeren Sensibilisierung für Risiken im täglichen Geschäft.

Praxisempfehlungen
- Resilience-Days pro Quartal: komprimierte Übungen, Kurztrainings, Erfahrungsaustausch.
- Anerkennungssysteme: Sichtbare Würdigung für vorbildliches Incident-Verhalten und Testengagement.
Fazit und Ausblick: DORA – von der Pflicht zur Chance
Die Umsetzung von DORA war und ist für Institute ein erheblicher Kraftakt. Sie zwingt Institute dazu, ihre Prozesse, Strukturen und Abhängigkeiten grundlegend zu hinterfragen. Die zentrale Erkenntnis aus den Projekten lautet: Wer DORA nicht nur als regulatorische Pflicht behandelt, wird langfristig profitieren. Erfolgreiche Institute nutzen die Gelegenheit, Resilienz als strategischen Vorteil auszubauen.
Für die kommenden Jahre ist absehbar, dass die Aufsichtsbehörden nicht nur auf formale Dokumentationen achten, sondern die tatsächliche Belastbarkeit der Strukturen prüfen werden. Institute sollten daher den Weg der kontinuierlichen Verbesserung einschlagen: regelmäßige Tests, enge Verzahnung der Governance und eine Kultur, in der Resilienz selbstverständlich gelebt wird.
Am Ende zeigt sich: DORA ist weniger ein zusätzlicher Regulierungsaufwand als vielmehr ein Katalysator für die Modernisierung der Finanzbranche. Wer die Lehren aus den bisherigen Projekten ernst nimmt, stärkt nicht nur seine Compliance, sondern auch die eigene Zukunftsfähigkeit.
