DORA einfach erklärt – Was das neue EU-Gesetz wirklich bedeutet

DORA einfach erklärt – Was das neue EU-Gesetz wirklich bedeutet

Seit Jahren diskutieren Politik, Wirtschaft und IT-Sicherheits-Expert:innen über die Frage, wie man die digitale Widerstandsfähigkeit (Resilienz) von Finanzunternehmen in Europa einheitlich, verbindlich und zukunftsfähig gestalten kann. Cyberangriffe, Systemausfälle und Abhängigkeiten von kritischen Dienstleistern sind längst nicht mehr theoretische Risiken, sondern harte Realität. Mit dem Digital Operational Resilience Act – kurz DORA – hat die Europäische Union nun ein Regelwerk geschaffen, das genau hier ansetzt: einheitliche, verbindliche und umfassende Anforderungen an den Umgang mit IKT-Risiken in der Finanzbranche. Das Ziel ist klar: Finanzunternehmen sollen in der Lage sein, auch unter extremen digitalen Störungen weiter handlungsfähig zu bleiben. Doch was heißt das konkret? Und warum betrifft es so viele Unternehmen viel direkter, als manche denken?

Dieser Beitrag erklärt DORA verständlich und praxisnah: von Geltungsbereich und Kernanforderungen über Governance und Testkonzepte bis hin zu konkreten Umsetzungsschritten, KPIs und typischen Fallstricken. Er richtet sich an Praktiker:innen, die in kurzer Zeit einen klaren Umsetzungsplan brauchen – und an Führungskräfte, die wissen wollen, wofür sie Verantwortung tragen.

Was steckt hinter DORA?

Rechtsnatur und Zielsetzung. DORA ist keine lose Sammlung von Empfehlungen, sondern eine EU-Verordnung. Sie gilt ab dem 17. Januar 2025 unmittelbar in allen Mitgliedstaaten, ohne dass es einer nationalen Umsetzung bedarf. Damit verfolgt die EU den Ansatz, unterschiedliche nationale Anforderungen zu ersetzen und einen einheitlichen, sektorspezifischen Rahmen für digitale operative Resilienz zu schaffen. Parallel wurden über eine begleitende Richtlinie sektorale Rechtsakte (u. a. CRD, Solvency II, MiFID II) angepasst, um die DORA-Vorgaben sauber in die Aufsichtspraxis zu integrieren.

Integrierter Ansatz statt Silos. Während bisher zahlreiche Regelwerke einzelne Facetten adressierten – Informationssicherheit (z. B. ISO/IEC 27001), IKT-Risikomanagement (z. B. EBA-Leitlinien), Business Continuity/Notfallmanagement (z. B. BSI-Standard 200-4), Vorfallmeldung (z. B. PSD2) – führt DORA diese Themen in einem konsistenten, durchgängigen Rahmen zusammen. Im Zentrum steht Operational Resilience: die Fähigkeit, kritische Geschäftsprozesse selbst bei massiven IT-Störungen, Cyberangriffen oder dem Ausfall von Dienstleistern fortzuführen – nicht nur „sicher“, sondern funktionsfähig.

Lex specialis gegenüber NIS2. Für Finanzunternehmen ist DORA der spezifische Rechtsrahmen für Cyber- und IKT-Resilienz. Viele NIS2-Pflichten werden dadurch im Finanzsektor überlagert. Gleichwohl bleibt die Koordination mit nationalen Meldewegen und sektorübergreifenden Krisenmechanismen wichtig, um Mehrfachmeldungen zu vermeiden und Schnittstellen sauber zu regeln.

Wen betrifft DORA?

Die Reichweite von DORA ist groß – größer, als viele zunächst vermuten. Erfasst sind mehr als 20 Kategorien von Finanzmarktteilnehmern, u. a.:

• Kreditinstitute
• Versicherungs- und Rückversicherungsunternehmen
• Wertpapierfirmen, Handelsplätze, zentrale Gegenparteien
• Zahlungs- und E-Geld-Institute
• Verwaltungsgesellschaften, AIFMs, Vermögensverwalter, Fonds
• Datenbereitstellungsdienste, Ratingagenturen
• Krypto-Dienstleister (sofern im Anwendungsbereich)
• Zentralverwahrer, Abwicklungs- und Clearing-Infrastrukturen

Hinzu kommt eine Besonderheit: kritische IKT-Drittanbieter (Critical ICT Third-Party Service Providers, z. B. große Cloud-Plattformen, Kernbankensoftware- oder Zahlungsdienstleister) unterliegen einer direkten europäischen Aufsicht (Joint Oversight). Das ist ein Novum und adressiert systemische Risiken durch Konzentration auf wenige Technologieanbieter.

Wichtig für die Praxis: Auch Unternehmen, die „nur“ Dienstleistungen für Finanzinstitute erbringen – vom Rechenzentrum über Managed Security Services bis zur Kernbankensoftware – sind mittelbar betroffen. Finanzinstitute müssen sicherstellen, dass ihre Lieferkette DORA-fähig ist. Wer in der Lieferkette steht, wird Vertragsklauseln, Auditrechte, Exit-Szenarien und Nachweisanforderungen künftig deutlich stärker spüren.

Die fünf Kernpfeiler von DORA – und was sie praktisch bedeuten

1) IKT-Risikomanagement

Unternehmen müssen ein robustes, dokumentiertes, getestetes IKT-Risikomanagement etablieren. Kernelemente:

• Governance & Verantwortlichkeiten: Das Management Body (Vorstand/Geschäftsführung) trägt die Gesamtverantwortung. Dazu gehören Risikobereitschaft, Strategie, Ressourcen, Überwachung und regelmäßige Wirksamkeitsbewertungen.
• Asset- und Service-Orientierung: Inventarisierung von Informationswerten, Anwendungen, Infrastrukturen und Geschäftsservices (Business-Service-Mapping) inklusive Abhängigkeiten und kritischer Toleranzgrenzen (z. B. maximale Ausfallzeiten).
• Schutz & Prävention: Richtlinien, Zugriffskontrollen, Härtung, Patch- und Schwachstellenmanagement, Netzwerksegmente, Protokollierung/Monitoring, Kryptographie, sichere Entwicklung (SDLC/DevSecOps).
• Erkennung & Reaktion: Security-Monitoring, SIEM/SOAR, Playbooks, Incident-Handling, Krisenstab, Kommunikationspläne.
• Wiederherstellung & Kontinuität: Backup-/Restore-Konzepte, Failover-Design, Notbetriebsverfahren, regelmäßige Wiederherstellungsübungen und Lessons Learned.
• Proportionalität: Umfang und Tiefe richten sich nach Größe, Risikoprofil und Kritikalität des Instituts – aber Substanz ist immer erforderlich.

2) Meldung IKT-bezogener Vorfälle (Incident Reporting)

DORA führt gemeinsame Kriterien, Prozesse und Formate für schwerwiegende IKT-Vorfälle ein. Erwartet wird:

• Klare Klassifizierung (z. B. nach Auswirkungen, Dauer, betroffenen Kunden/Services, geografischer Ausbreitung).
• Frühzeitige Erstmeldung an die zuständigen Behörden, gefolgt von Zwischen- und Abschlussberichten in standardisierten RTS/ITS-Formaten.
• Schnittstellenmanagement zu anderen Meldepflichten (z. B. Zahlungsdienste, Datenschutz, NIS2), um Doppelmeldungen und Inkonsistenzen zu vermeiden.
• Interne Reife: Wer meldet, muss seine Lage kennen: Log- und Telemetriedaten, forensische Sicherung, dokumentierte Entscheidungen, Kommunikationsleitfäden (auch für Kunden/Medien).

3) Digital Operational Resilience Testing

Regelmäßige, risikoorientierte Tests – vom Vulnerability-Scan bis zum Threat-Led Penetration Test (TLPT) – sind Pflicht. Eckpunkte:

• Risikobasiertes Testprogramm: Mischung aus technischen und organisatorischen Tests, Übungen und Table-Top-Szenarien.
• Kronjuwelen-Fokus: Scope auf kritische Geschäftsservices inkl. Up-/Downstream-Systeme; realistische Angreiferpfade (Kill Chain).
• TLPT für bestimmte, als bedeutend eingestufte Institute in mehrjährigen Zyklen; Durchführung durch qualifizierte, unabhängige Teams, die reale TTPs nachstellen.
• Remediation & Verifikation: Findings fließen in priorisierte Maßnahmenpläne; Wirksamkeit wird nachgetestet und an das Management berichtet.

4) IKT-Drittparteienrisiko (Outsourcing & Lieferkette)

DORA stärkt das Third-Party Risk Management (TPRM) deutlich:

• Lebenszyklus-Steuerung: Von Sourcing-Strategie, Due Diligence, Risikoanalyse, Vertragsgestaltung (inkl. Audit- und Zugriffrechte, Leistungsindikatoren, Exit-/Substitutionsszenarien) bis zum laufenden Monitoring.
• Register & Transparenz: Vollständiges Register aller IKT-bezogenen Drittparteienbeziehungen, inkl. Sub-Outsourcing-Ketten, Orte der Leistungserbringung und Datenverarbeitung.
• Konzentrationsrisiken: Identifikation systemischer Abhängigkeiten (z. B. hyperscalende Cloud), Alternativen und technische/vertragliche Portabilität (Daten/Workloads).
• Joint Oversight für kritische IKT-Drittanbieter: zusätzliche Anforderungen und Prüfungen auf europäischer Ebene.

5) Informationsaustausch

DORA fördert den freiwilligen, strukturierten Austausch von Cyber-Bedrohungsinformationen (TTPs, IOCs, Schwachstellen, Best Practices) zwischen Finanzmarktteilnehmern, etwa in vertrauenswürdigen Foren/ISACs. Ziel ist eine gemeinsame Erhöhung der Abwehrfähigkeit – rechtlich gerahmt, um Wettbewerbs- und Datenschutzfragen zu adressieren.

Warum DORA eingeführt wurde

Die Angriffsfläche wächst: Cloudifizierung, hochintegrierte Lieferketten, Remote-Arbeit, API-Ökosysteme und vernetzte Zahlungs-/Handelsinfrastrukturen erzeugen komplexe Abhängigkeiten. Einzelereignisse können schnell systemische Effekte auslösen – vom Ausfall eines Identity-Providers über fehlerhafte Software-Updates bis hin zu gezielten Ransomware-Kampagnen gegen Dienstleister. DORA ist die regulatorische Antwort auf diese Realität: Sektorkohärenz, Verbindlichkeit und Testbarkeit statt Flickenteppich.

Was bedeutet DORA in der Praxis? – Auswirkungen auf Organisation und Prozesse

Struktur und Rollen. Institute benötigen klare Rollen und Gremien: z. B. eine DORA-Programmleitung, ein bereichsübergreifendes Resilienz-Board (IT, Risk, Compliance, Fachbereiche, Einkauf, Recht, BCM), definierte Service-Owner, TPRM-Funktion, Incident Manager, Crisis Manager und unabhängige Test-/Auditfunktionen.

Prozesse. Bestehende Abläufe werden integriert und an einheitliche Kriterien angeglichen: ein zentraler Servicekatalog mit Toleranzgrenzen; ein harmonisierter Incident-Lifecycle; ein konsolidiertes Testprogramm mit Jahresplan; ein End-to-End-Lieferkettenprozess von der Bedarfsanmeldung bis zum Exit.

Systeme & Daten. Ohne saubere Datenbasis geht nichts: CMDB/Asset-Inventar, Logging-/SIEM-Plattform, Ticketing/IR-Workflow, GRC-Tool für Risiken/Kontrollen, TPRM-Register, Metriken-Repository – und Schnittstellen, die Redundanzen vermeiden.

Kultur. Resilienz ist kein IT-Projekt, sondern eine Organisationseigenschaft. Schulungen, Awareness, klare Verantwortlichkeiten und eine offene Fehler-/Lernkultur sind erfolgskritisch.

Governance und Verantwortlichkeit des Managements

• Verantwortung: Das Management Body ist verantwortlich für Strategie, Ressourcen, Risikobereitschaft, Genehmigung wesentlicher Outsourcings, Überwachung von KPIs/KRIs und regelmäßige Wirksamkeitsreviews.
• Kompetenz: DORA erwartet ausreichende IKT-Kompetenz im Top-Management. Das kann durch gezielte Trainings, Besetzungen oder externe Expertise sichergestellt werden.
• Berichterstattung: Quartals-/Halbjahresberichte zu Resilienz-Lage, Top-Risiken, Großvorfällen, Testbefunden, Drittparteienlage (inkl. Konzentrationsrisiken), offenem Maßnahmen-Backlog und Reifeentwicklung.

Artefakte und Nachweise: Was Aufsichten (und Auditoren) sehen wollen

• IKT-Risikorahmen & Policies: Strategie, Risikobereitschaft, Prozesse, Rollen, Kontrollkatalog, Proportionalitätsbegründung.
• Service-Kritikalität & Toleranzgrenzen: Mapping Geschäftsservices ↔ Anwendungen/Infra ↔ Drittparteien, RTO/RPO, Impact-Szenarien.
• Incident-Management-Dokumente: Klassifizierungskriterien, Meldeworkflow, Kommunikationspläne, Lessons-Learned-Register.
• Testprogramm & Evidenzen: Jahresplan, Scopes, Methoden, TLPT-Nachweise, Findings, Remediation, Retests.
• TPRM-Register & Verträge: Due Diligence, Risikoanalysen, wesentliche Verträge mit DORA-Klauseln (Audit, Sub-Outsourcing, Exit, Datenlokation, Notfall-Support), laufende Leistungs-/Risikoberichte.
• BCM/DR-Nachweise: Übungspläne, Ergebnisprotokolle, Wiederherstellungszeiten, Notbetriebsverfahren, Abhängigkeitstests.
• KPIs/KRIs & Managementberichte: definierte Kennzahlen, Schwellwerte, Trends, Maßnahmenverfolgung.

Konkrete Umsetzung: Ein pragmatischer 12-Monats-Fahrplan

Phase 1 – Mobilisieren (0–4 Wochen)

• Sponsoring und klare Verantwortung im Top-Management sichern.
• DORA-Programm aufsetzen (Scope, Meilensteine, Budget, Ressourcen).
• Readiness-Check: Wo stehen wir bei Incident, TPRM, Tests, BCM, Governance?
• Stakeholder-Landkarte, Kommunikationsplan, erste Quick Wins identifizieren.

Phase 2 – Scoping & Inventar (5–10 Wochen)

• Service-Katalog erstellen/aktualisieren: kritische Geschäftsservices, Toleranzgrenzen, Abhängigkeiten.
• Vollständiges TPRM-Register (inkl. Sub-Outsourcing, Datenflüsse, Orte).
• Meldepflichten-Matrix (DORA, PSD2, DSGVO, NIS2 etc.) und Prozess-Schnittstellen.

Phase 3 – Gap-Analyse & Zielbild (8–14 Wochen)

• Soll/Ist je Pfeiler (Governance, Incident, Testing, TPRM, BCM).
• Kontrollkatalog mit Verantwortlichkeiten (RACI) und Reifegradzielen.
• Maßnahmen-Backlog, priorisiert nach Risiko, Regulatorik, Aufwand/Nutzen.

Phase 4 – Umsetzen & Verankern (laufend bis Monat 12)

• Policies/Prozesse aktualisieren und in Tools verankern (GRC, SIEM, Ticketing).
• Vertragsklauseln nachziehen (Audit, Exit, Datenlokation, Support im Krisenfall).
• Pilot-Tests: Table-Top-Krisenübung, Wiederherstellungsübung, Red-Team-Light.
• Training & Awareness: Management-Briefings, Fachtrainings, Übungen.
• Berichtswesen etablieren: monatliche KPIs/KRIs, Quartalsberichte ans Management.
• Nachweisführung: Audit-feste Evidenzen, Änderungs-/Entscheidungsprotokolle.

TLPT, Szenarien & Übungen: So wird Testen wirksam

• Threat-Led Penetration Testing (TLPT): Realitätsnahe Angriffe mit klaren Rules of Engagement auf kritische Services, abgestimmt mit Aufsichtsvorgaben; Ergebnis sind behebungsfähige Findings, nicht nur „Show-Hacks“.
• Szenario-Übungen: Ransomware mit Lieferketten-Einstieg, Cloud-Region-Ausfall, Zero-Day in weit verbreiteter Bibliothek, Identity-Provider-Störung, Datenkorruption durch Insider.
• Erfolgskriterium: Messbare Wiederherstellungszeiten, Entscheidungsqualität im Krisenstab, Kommunikationsgeschwindigkeit und Datenqualität – und umgesetzte Lessons Learned.

TPRM in der Tiefe: Von der Vertragsklausel zur tatsächlichen Resilienz

Due Diligence vor Vertragsschluss

• Sicherheits-/Resilienzreife (Zertifikate, Reports, Pen-Test-Summary), Notfall-/Wiederherstellungskonzepte, Datenlokation, Sub-Dienstleister, Versicherungen.
• Portabilität: Datenformate, Exit-Tools, Migrationsunterstützung, Runbook für Not-Exit.
• Konzentrationsrisiko: Abhängigkeit von Markt-Oligopolen bewerten; Alternativen, Multi-Cloud-Designs, Entkopplung (z. B. IAM, Observability, Backups).

Vertragliche Mindestklauseln

• Audit-/Inspektionsrechte inkl. Remote-/On-Site, Zugriff auf relevante Logs/Reports.
• Meldung schwerwiegender IKT-Vorfälle und Sicherheits-/Service-Degradationen in definierten Fristen.
• Sub-Outsourcing nur mit Zustimmung/Transparenz; gleiche Pflichten in der Kette.
• Exit-/Termination-Support, Daten-/Workload-Rückführung, Unterstützung bei Not-Exit.
• Leistungskennzahlen (SLAs/SLOs) inkl. Resilienzmetriken (RTO/RPO-nahe KPIs).

Betriebliche Steuerung

• Regelmäßige Service-/Risikogespräche, Review von KPIs/KRIs, abgestimmte Übungen.
• Contract Change Control: technische/organisatorische Änderungen frühzeitig bewerten.
• Frühwarn-Indikatoren (z. B. Personalfluktuation beim Anbieter, Sicherheitsvorfälle, Rechtsänderungen, geopolitische Lagen).

Incident-Reporting ohne Chaos: Der Dreischritt in der Praxis

1. Detektion & Klassifizierung: SOC/IRT erkennt Ereignis, bewertet Impact (Kunden, Services, Dauer, Daten), ordnet DORA-Relevanz ein.
2. Meldeworkflow: definierte Erstmeldung an zuständige Behörde(n), interne Eskalation an Krisenstab/Management, Zwischenberichte mit Lageupdates, Abschlussbericht mit Ursachenanalyse und Maßnahmen.
3. Lessons Learned & Hardening: Befunde in Kontrollen/Architektur verankern; ggf. Verträge/Drittparteien anpassen; Metriken aktualisieren.

Schnittstellen beachten: Datenschutz, Zahlungsverkehr, NIS2, nationale Aufsichten – eine Melde-Orchestrierung vermeidet Widersprüche und Doppelaufwand.

KPIs & KRIs: Messen, was Resilienz wirklich treibt

Governance & Reife

• Anteil kritischer Geschäftsservices mit definierten Toleranzgrenzen (100 % Ziel).
• Reifegrad je Kontrollfamilie (Schutz, Erkennung, Reaktion, Wiederherstellung).
• Zeit bis zur Management-Entscheidung bei Schwerstvorfällen (Median/95. Perzentil).

Incident-Management

• MTTD/MTTR für kritische Services; Anteil „First Fix within Tolerance“.
• Quote fristgerechter Vorfallmeldungen in geforderter Qualität.
• Anzahl/Trend von Wiederholungsbefunden (gleiche Ursache).

Testing

• Testabdeckung kritischer Services pro Jahr (%).
• Sanierungsquote innerhalb Frist (z. B. 30/90 Tage) nach Schweregrad.
• Anzahl „High/Medium“-Befunde je TLPT-Zyklus und Trend.

TPRM

• Drittparteien mit vollständigen DORA-Klauseln (%).
• Zeit bis Vertrags-Remediation; Anteil Sub-Outsourcing transparent dokumentiert.
• KRIs: SLA-Verfehlungen, Security-Breach-Meldungen, Personalfluktuation beim Anbieter.

BCM/DR

• Erfolgsquote von Wiederherstellungsübungen innerhalb RTO/RPO.
• Datenwiederherstellungs-Validität (Integritätschecks bestanden).
• Zeit bis Notbetriebsaufnahme (definiert je Service).

Training & Awareness

• Abdeckungsquote Pflichtschulungen (Mitarbeitende, IT-Staff, Management) und Post-Test-Scores.
• Teilnahme an Krisenübungen; Qualität der Entscheidungen (Qualitätskriterien/Scoring).

Integration mit bestehenden Frameworks

• ISO/IEC 27001/27002: liefert einen starken Kontrollbaukasten, deckt aber nicht allein die Resilienz- und Testpflichten DORAs ab (z. B. TLPT, Meldeformate, TPRM-Register).
• NIST CSF 2.0: gute Struktur für Identify-Protect-Detect-Respond-Recover; DORA verlangt ergänzend Aufsichtskonformität und formale Nachweise.
• COBIT/ITIL: stärken Governance und Service-Orientierung; wichtig für RACI, Change, Incident/Problem/Request.
• BSI-Standard 200-4 (BCM): exzellent für Notfallmanagement – DORA fordert zusätzlich IKT-spezifische Testtiefen und Meldeprozesse.
• TIBER-EU/Pentest-Standards: können TLPT-Anforderungen abdecken, wenn Scope/Methode DORA-konform sind.

Typische Fallstricke – und wie man sie vermeidet

1. „Compliance statt Resilienz“: Policies ohne gelebte Praxis. Gegenmittel: Üben, testen, messen, nicht nur schreiben.
2. Unvollständige Service-/Abhängigkeitskarten: Ohne sauberes Mapping keine Ziel-Toleranzen. Gegenmittel: Service-Owner benennen, Architekturen dokumentieren.
3. TPRM unterschätzt: Vertragsnachverhandlungen dauern. Gegenmittel: Früh starten, Standardklauseln, Eskalationspfade.
4. Meldechaos: Uneinheitliche Klassifizierung, Mehrfachmeldungen. Gegenmittel: zentrale Orchestrierung, klare Kriterien, Probeläufe.
5. Fehlende Evidenzen: Gute Praxis, aber nicht nachweisbar. Gegenmittel: Audit-feste Dokumentation, Ticket-Referenzen, Sign-offs, Artefakt-Ablage.
6. Einmalige TLPT-„Show“: Kein nachhaltiger Effekt. Gegenmittel: Remediation-Tracking, Management-Attention, Retests.
7. Ressourcen & Skills: Zu wenig Personal/Kompetenz. Gegenmittel: realistische Roadmap, Upskilling, gezielte Partner, klare Prioritäten.

Beispielhafte Quick Wins

• Einheitliche Incident-Schweregrade und Melde-Playbooks definieren; Table-Top-Trockenübung.
• Service-Katalog mit Toleranzgrenzen für Top-5-Kritische Services fertigstellen.
• TPRM-Register konsolidieren; Standard-DORA-Klauselwerk vorbereiten.
• Backup-/Restore-Dry-Runs für ein kritisches System mit Integritätscheck.
• SOC-Use-Cases für Kronjuwelen nachschärfen (z. B. Privilege-Misuse, Datenausleitung, Backup-Verschlüsselung).
• Management-Briefing zu DORA-Pflichten und Entscheidungswegen im Krisenfall.

Häufige Fragen (FAQ)

Gilt DORA auch für kleine Institute?
Ja – proportional. Umfang und Tiefe richten sich nach Größe und Risiko, aber Kernanforderungen (Governance, Incident, Tests, TPRM, BCM) gelten für alle.

Wie oft müssen TLPTs durchgeführt werden?
Für bestimmte, als bedeutend eingestufte Institute in mehrjährigen Zyklen. Details ergeben sich aus den technischen Standards/Aufsichtsvorgaben. Andere Institute betreiben ein risikoorientiertes Testprogramm mit angemessener Tiefe.

Ersetzt DORA ISO 27001?
Nein. ISO 27001 bleibt wertvoll als Managementsystem-Standard. DORA verlangt jedoch zusätzliche, sektor- und aufsichtsrechtliche Elemente (z. B. Meldeformate, TPRM-Register, TLPT-Anforderungen).

Wie verhält sich DORA zu NIS2?
Für Finanzinstitute ist DORA lex specialis. Dennoch müssen Schnittstellen zu NIS2-Meldewegen national sinnvoll koordiniert werden.

Was droht bei Nicht-Einhaltung?
Aufsichtsmaßnahmen bis hin zu Sanktionen, Auflagen, Einschränkungen wesentlicher Auslagerungen – und vor allem operative Risiken mit Reputationsschäden.

DORA ist mehr als Compliance – es ist ein Wettbewerbsfaktor

Es wäre ein Fehler, DORA nur als regulatorische Pflicht zu sehen. Richtig umgesetzt, schafft DORA robuste, belastbare Abläufe, die Kundenvertrauen stärken, Ausfallkosten senken und die Zeit-zur-Erholung nach Störungen verkürzen. Institute, die Resilienz messen, üben und verbessern, sind verlässliche Partner für Kund:innen, Aufsicht und Markt – und können Innovationen (Cloud, APIs, KI) sicherer und schneller skalieren.

Fazit: Jetzt handeln – strukturiert, messbar, pragmatisch

DORA ist nicht nur ein weiteres Gesetz – es ist der Versuch, die digitale Resilienz der europäischen Finanzbranche auf ein neues, einheitliches Niveau zu heben. Wer jetzt proaktiv startet, hat genug Zeit, Prozesse anzupassen, Systeme zu prüfen, Verträge zu härten und Teams zu schulen. Der klügste Weg ist fokussiert: kritische Services identifizieren, Toleranzgrenzen festlegen, Incident-/Meldeprozesse vereinheitlichen, TPRM-Register schließen, Testprogramm aufsetzen, Evidenzen sammeln.

Der Countdown läuft: Ab Januar 2025 wird DORA Realität – und wer dann vorbereitet ist, wird nicht nur den Stresstest bestehen, sondern gestärkt daraus hervorgehen.