Was ist DORA (Digital Operational Resilience Act)?

DORA, der Digital Operational Resilience Act, ist die Verordnung der Europäischen Union, die verbindliche Anforderungen an IKT-Risikomanagement, die Meldung von Vorfällen, Tests der operationalen Resilienz und die Aufsicht über Drittparteien im gesamten EU-Finanzsektor festlegt. Förmlich ist sie die Verordnung (EU) 2022/2554; sie trat am 16. Januar 2023 in Kraft und ist seit dem 17. Januar 2025 voll anwendbar (Art. 64 DORA). Ihr Ziel ist es, das EU-Finanzsystem strukturell widerstandsfähig gegen IKT-Störungen zu machen, von Cyberangriffen und Cloud-Ausfällen bis zu Softwarefehlern und Vorfällen bei Drittdienstleistern.

Zum ersten Mal gibt DORA den Aufsichtsbehörden der EU einen einheitlichen, harmonisierten Rahmen, um die operationale Resilienz von Banken, Versicherern, Wertpapierfirmen, Zahlungsdienstleistern, Anbietern von Krypto-Dienstleistungen und den kritischen Technologie-Anbietern zu beaufsichtigen, von denen diese abhängen. Wo frühere nationale Regime zersplittert und überwiegend leitlinienbasiert waren, macht DORA operationale Resilienz zu einer unmittelbar durchsetzbaren Rechtspflicht, gestützt auf verwaltungsrechtliche Sanktionen, die jeder Mitgliedstaat festlegt, und für kritische IKT-Drittdienstleister auf Zwangsgelder, die auf EU-Ebene verhängt werden.

DORA im Überblick

DORA ruht auf einer einfachen Prämisse: Finanzstabilität hängt heute ebenso von digitaler Infrastruktur ab wie von der Eigenkapitalausstattung. Eine ausgefallene Cloud-Region, ein Ransomware-Angriff auf ein Abwicklungssystem oder eine kompromittierte Schnittstelle eines Lieferanten kann kritische Finanzfunktionen binnen Stunden stören, und klassische kapitalbasierte Regulierung kann solche Ereignisse weder verhindern noch eindämmen. DORA kodifiziert die Kontrollen und Meldungen, die die Aufsicht in der EU für nötig hält, damit digitale Störung eine handhabbare, beaufsichtigte Risikokategorie wird.

DORA ist keine Leitlinie. Sie ist eine Verordnung und gilt damit unmittelbar in jedem Mitgliedstaat der EU, ohne umsetzende Gesetzgebung. Ihre technischen Anforderungen im Detail stehen in technischen Regulierungsstandards (RTS) und technischen Durchführungsstandards (ITS), die von den Europäischen Aufsichtsbehörden (EBA, ESMA, EIOPA) entwickelt und von der Europäischen Kommission angenommen werden. Die nationalen zuständigen Behörden setzen DORA in ihrem Zuständigkeitsbereich durch, und die Europäischen Aufsichtsbehörden überwachen kritische IKT-Drittdienstleister auf EU-Ebene über eine federführende Überwachungsbehörde, unterstützt vom Überwachungsforum.

Für wen DORA gilt

Der Anwendungsbereich von DORA ist breit. Art. 2 DORA nennt zwanzig Kategorien von Finanzunternehmen, darunter:

• Kreditinstitute (Banken)
• Zahlungsinstitute und E-Geld-Institute
• Wertpapierfirmen, Handelsplätze und Transaktionsregister
• Zentralverwahrer und zentrale Gegenparteien
• Versicherungs- und Rückversicherungsunternehmen, Vermittler und Einrichtungen der betrieblichen Altersversorgung (EbAV)
• Anbieter von Krypto-Dienstleistungen nach MiCA
• Schwarmfinanzierungsdienstleister, Datenbereitstellungsdienste und Ratingagenturen

DORA reicht außerdem über den Finanzsektor hinaus zu den IKT-Drittdienstleistern, von denen Finanzunternehmen abhängen. Wer als kritischer IKT-Drittdienstleister (CTPP) eingestuft wird, also große Cloud-Plattformen, Softwareanbieter und Managed-Service-Provider, unterliegt der unmittelbaren Überwachung auf EU-Ebene durch eine federführende Überwachungsbehörde (eine der drei Europäischen Aufsichtsbehörden), unterstützt von einem gemeinsamen Prüfungsteam. Das ist ein struktureller Bruch: Zum ersten Mal haben Finanzaufsichtsbehörden der EU unmittelbare Aufsichtsbefugnisse über Technologieanbieter, die selbst keine Finanzunternehmen sind.

Es gilt der Grundsatz der Verhältnismäßigkeit. Kleine und nicht verflochtene Wertpapierfirmen, nach der PSD2 ausgenommene Zahlungsinstitute und ähnliche Unternehmen profitieren von einem leichteren Regime. Die Kernanforderungen aber, also ein Rahmen für das IKT-Risikomanagement, die Meldung von Vorfällen und die Aufsicht über Drittparteien, gelten breit über die regulierte Grundgesamtheit.

Die fünf Säulen von DORA

DORA ist um fünf betriebliche Anforderungen herum geordnet. Zusammen decken sie den Lebenszyklus des digitalen Risikos in einem Finanzinstitut ab.

1. IKT-Risikomanagement

Finanzunternehmen müssen einen umfassenden Rahmen für das IKT-Risikomanagement einrichten, der vom Leitungsorgan genehmigt und überwacht wird. Der Rahmen muss die Identifizierung der IKT-gestützten Geschäftsfunktionen abdecken, die Einordnung der tragenden Systeme und Abhängigkeiten, Schutz- und Präventionskontrollen, Erkennung, Reaktions- und Wiederherstellungsverfahren, Lernen und Weiterentwicklung aus Vorfällen sowie Kommunikation. Er muss dokumentiert, regelmäßig überprüft und bei wesentlichen Änderungen angepasst werden.

Der Rahmen ist keine Checkliste. DORA erwartet von Instituten ein fortlaufend aktualisiertes Verzeichnis der IKT-Bestände, Abhängigkeiten und Informationsflüsse, einschließlich der Abhängigkeiten von Dritten, und die Zuordnung dieser Bestände zu den kritischen oder wichtigen Funktionen, die sie tragen. Ohne dieses Verzeichnis können die übrigen vier Säulen nicht funktionieren.

2. Management, Klassifizierung und Meldung IKT-bezogener Vorfälle

DORA verlangt Verfahren, um IKT-bezogene Vorfälle zu erkennen, zu handhaben, einzuordnen und zu melden. Schwerwiegende Vorfälle sind der zuständigen Behörde innerhalb enger regulatorischer Fristen nach der Delegierten Verordnung (EU) 2025/301 zu melden: eine Erstmeldung binnen 4 Stunden, nachdem der Vorfall als schwerwiegend eingestuft wurde, und spätestens 24 Stunden nach Kenntnis, ein Zwischenbericht binnen 72 Stunden nach der Erstmeldung und ein Abschlussbericht binnen eines Monats nach dem letzten Zwischenbericht. Erhebliche Cyberbedrohungen können freiwillig gemeldet werden.

Diese Fristen zu halten setzt voraus, Fragen schnell beantworten zu können wie: welche Systeme und Daten betroffen sind, welche kritischen Funktionen von ihnen abhängen, wie viele Kunden betroffen sind und ob personenbezogene Daten gefährdet waren. Das ist ein Thema der Data Governance im Gewand eines Themas der Vorfallbearbeitung: Die Antwort hängt daran, wie gut die Organisation ihre Datenflüsse kennt, bevor ein Vorfall eintritt.

3. Tests der digitalen operationalen Resilienz

DORA schreibt ein strukturiertes Programm für Resilienztests vor, angemessen zur Größe und zum Risikoprofil des Instituts. Alle Finanzunternehmen müssen Basistests ihrer IKT-Werkzeuge und -Systeme durchführen. Unternehmen, die ihre zuständige Behörde dafür bestimmt, müssen zusätzlich mindestens alle drei Jahre bedrohungsgeleitete Penetrationstests (TLPT) durchführen, nach den TLPT-RTS, die an TIBER-EU ausgerichtet sind. Die Tests sind von unabhängigen Testern durchzuführen und decken produktive Systeme mit angemessenen Schutzvorkehrungen ab.

Tests nützen nur, wenn Befunde behoben und die Behebung bestätigt werden kann. Das setzt voraus zu wissen, welche Systeme es gibt, welche kritisch sind und welche Daten sie verarbeiten, und macht aus dem Testprogramm einen von Governance getragenen Kreislauf statt einer für sich stehenden IT-Übung.

4. Management des IKT-Drittparteienrisikos

DORA stellt detaillierte Anforderungen an Vertragsbeziehungen mit IKT-Drittdienstleistern, einschließlich verpflichtender Klauseln zu Datenzugang, Prüfrechten, Service Levels, Weitervergabe, Ausstiegsstrategien und Zusammenarbeit bei Vorfällen. Kritische Funktionen brauchen tragfähige Ausstiegsstrategien; die Bindung an einen einzigen Anbieter für einen kritischen Dienst ist ein aufsichtlicher Befund im Wartestand.

Jedes Finanzunternehmen muss ein Informationsregister führen, das alle Vertragsbeziehungen mit IKT-Drittdienstleistern abdeckt, auf Ebene des Unternehmens sowie auf teilkonsolidierter und konsolidierter Ebene. Die Unternehmen berichten darüber mindestens jährlich an ihre zuständige Behörde und legen das vollständige Register auf Anfrage vor; die Behörden geben es an die Europäischen Aufsichtsbehörden weiter, wo es die Einstufung kritischer IKT-Drittdienstleister auf EU-Ebene speist. Datenfelder, Granularität und Struktur schreibt die Durchführungsverordnung (EU) 2024/2956 vor.

5. Informations- und Erkenntnisaustausch

DORA ermutigt zum freiwilligen Austausch von Informationen und Erkenntnissen über Cyberbedrohungen zwischen Finanzunternehmen und erleichtert ihn in manchen Zusammenhängen. Vereinbarungen dazu müssen Vertraulichkeit, den Schutz personenbezogener Daten nach der DSGVO und das Wettbewerbsrecht wahren. Gut gemacht baut der Austausch von Erkenntnissen kollektive Widerstandsfähigkeit schneller auf als isolierte Verteidigung; schlecht gemacht schafft er neue Angriffsfläche beim Datenschutz und bei der Compliance.

Die Voraussetzung aus Sicht der Governance ist die Datenklassifizierung. Ohne klare Kennzeichnung, was teilbare Bedrohungsinformation ist und was vertrauliche Geschäfts- oder personenbezogene Daten sind, fallen Austauschprogramme in einen von zwei Fehlermodi: zu viel teilen (und DSGVO-Risiko erzeugen) oder zu wenig teilen (und den Wert des Netzwerks verschenken).

Fristen und Bußgelder

Der regulatorische Zeitplan von DORA ist geradlinig, aber folgenreich:

• 16. Januar 2023 - DORA tritt in Kraft.
• 17. Januar 2025 - DORA wird voll anwendbar. Die Einhaltung wird ab jetzt aktiv beaufsichtigt.
• 30. April 2025 - Frist für die nationalen Behörden, die ersten Informationsregister an die Europäischen Aufsichtsbehörden zu übermitteln (die Unternehmen reichten früher ein, nach nationalen Zeitplänen).
• 18. November 2025 - die Europäischen Aufsichtsbehörden benennen die ersten kritischen IKT-Drittdienstleister; Überwachungsprüfungen folgen ab 2026.

Die Bußgelder für Verstöße gegen die Compliance sind nach deren Schwere bemessen. Finanzunternehmen drohen verwaltungsrechtliche Sanktionen, die jeder Mitgliedstaat nach Art. 50 DORA festlegt und die wirksam, verhältnismäßig und abschreckend sein müssen. Gegen kritische IKT-Drittdienstleister kann die federführende Überwachungsbehörde tägliche Zwangsgelder verhängen (Art. 35 DORA), von bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes des Anbieters im vorangegangenen Geschäftsjahr, für höchstens sechs Monate, eine Konstruktion, die Nichtkooperation für große Cloud- und Softwareanbieter wirtschaftlich untragbar machen soll.

DORA und Data Governance

Liest man die fünf Säulen von DORA für sich, wirkt sie wie eine Regulierung für Cybersicherheit und IT-Betrieb. Liest man sie zusammen, entsteht ein anderes Bild: DORA ist eine Verordnung darüber, was Finanzinstitute über ihre eigenen Daten und ihre Technik wissen müssen und wie schnell sie es wissen müssen. Alle fünf Säulen hängen an derselben zugrunde liegenden Fähigkeit, nämlich einem gesteuerten, maschinenlesbaren Verständnis von Systemen, Daten, Abhängigkeiten und Verantwortung.

Die Fähigkeiten der Data Governance, die DORA voraussetzt:

• Verzeichnis der Bestände und Abhängigkeiten - Ein Datenkatalog, der IKT-Systeme, Datensätze, Datenflüsse und deren Verbindung zu Geschäftsfunktionen abdeckt. Ohne dieses Verzeichnis bleibt IKT-Risikomanagement eine Dokumentationsübung.
• Lineage auf System- und Spaltenebene - Data Lineage und Lineage auf Spaltenebene machen aus der Meldung binnen 4 Stunden statt einer Heldentat eine Routineabfrage. Wird ein Vorfall entdeckt, beantwortet Lineage die ersten Fragen der Aufsicht: welche Systeme betroffen sind, welche Funktionen von ihnen abhängen, welche Kundendaten im Spiel sind.
• Metadaten zur Klassifizierung - Eine Kennzeichnung, die kritische oder wichtige Funktionen von tragenden unterscheidet, personenbezogene Daten von nicht personenbezogenen und teilbare Bedrohungsinformation von vertraulicher. Datenklassifizierung ist das, was sowohl die Triage von Vorfällen als auch den Informationsaustausch im Maßstab sicher macht.
• Verantwortung und Stewardship - Dokumentierte Verantwortung für Daten für Systeme und Datensätze, damit die Vorfallbearbeitung ab der ersten Minute benannte zuständige Stellen hat, statt auf einen Blick ins Organigramm zu warten.
• Drittparteienregister - Strukturierte Metadaten zu jeder Vertragsbeziehung mit IKT-Dritten, einschließlich der geteilten Datenkategorien, der Verarbeitungsorte, der Unterauftragnehmer und der vertraglichen Schutzvorkehrungen. Das ist der Inhalt des Informationsregisters, über das die Unternehmen ihren zuständigen Behörden berichten.
• Prüfprotokoll - Eine unveränderliche Historie von Katalogänderungen, Aktualisierungen der Klassifizierung und Zugriffsentscheidungen, damit aufsichtliche Prüfungen rekonstruieren können, was das Institut wann wusste.

Institute, die in dieses Governance-Rückgrat investiert haben, finden DORA-Compliance machbar und weitgehend additiv: Derselbe Katalog und dieselbe Lineage, die sie für Analytics, KI-Reife und die DSGVO gebaut haben, tragen auch DORA. Institute, die das nicht getan haben, stehen vor einem parallelen und teuren Aufbau, oft unter Fristendruck.

DORA, BCBS 239 und DSGVO

DORA steht neben weiteren Regimen für Daten und Risiko, die Finanzinstitute gleichzeitig erfüllen müssen: BCBS 239, einem internationalen Standard des Basler Ausschusses, den die Aufsicht auf Banken anwendet, und EU-Recht wie der DSGVO und NIS2. Zu verstehen, wo sie sich überlappen und wo sie sich unterscheiden, hilft, doppelte Compliance-Programme zu vermeiden.

• BCBS 239 (Grundsätze für die effektive Aggregation von Risikodaten und die Risikoberichterstattung) - Leitlinien des Basler Ausschusses mit Blick auf Zeitnähe, Richtigkeit, Vollständigkeit und Anpassungsfähigkeit von Risikodaten bei bedeutenden Banken. BCBS 239 und DORA überlappen stark bei Data Lineage, Governance und meldefähiger Berichterstattung, aber BCBS 239 ist prinzipienbasierte aufsichtliche Leitlinie, während DORA eine unmittelbar durchsetzbare Verordnung ist. Der ausführliche Vergleich steht in BCBS 239, DSGVO und das Lineage-Problem.
• DSGVO (Datenschutz-Grundverordnung) - Das Regime zum Schutz personenbezogener Daten, anwendbar über alle Branchen. Die DSGVO verlangt ein Verzeichnis von Verarbeitungstätigkeiten (Art. 30), die Meldung einer Verletzung binnen 72 Stunden (Art. 33) und belegbare Rechenschaft (Art. 5 Abs. 2), also Anforderungen, die sich mit der Meldung von Vorfällen und dem Bestandsverzeichnis nach DORA für den personenbezogenen Teil des Katalogs überschneiden.
• NIS2-Richtlinie - Die Cybersicherheits-Grundrichtlinie für wesentliche und wichtige Einrichtungen über viele Branchen. DORA wirkt für Finanzunternehmen als lex specialis: Wo DORA und NIS2 auf dasselbe Unternehmen anwendbar wären, gehen die spezifischeren Anforderungen von DORA vor.

Praktisch heißt das, dass Finanzinstitute ihre Infrastruktur für Data Governance und Risiko einmal bauen sollten, mit einem Modell für mehrere Regime im Kopf. Drei getrennte Compliance-Programme für dieselben zugrunde liegenden Datenflüsse sind ein Rezept für Widersprüche und Kosten. Ein gesteuerter Katalog, eine Lineage, ein Verantwortungsmodell und drei aufsichtsfertige Sichten sind das Ziel.

Fazit

DORA ist keine IT-Regulierung. Sie ist eine Regulierung der Data Governance, geschrieben für den EU-Finanzsektor, und eine, der das übrige regulatorische Umfeld der EU im kommenden Jahrzehnt zunehmend ähneln wird. Institute, die sie als strategische Aufwertung ihrer Dateninfrastruktur behandeln statt als Dokumentationsübung, geben weniger aus, halten sie verlässlicher ein und erleben ihre Widerstandsfähigkeit als echten Nebeneffekt. Institute, die DORA als einmaliges Compliance-Projekt behandeln, machen es in drei Jahren noch einmal, teurer, unter engerer Aufsicht und mit der Glaubwürdigkeit des Leitungsorgans auf dem Spiel.

Quellen

• EUR-Lex, Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) (Anwendungsbereich in Art. 2, Register in Art. 28, Zwangsgelder der federführenden Überwachungsbehörde in Art. 35, Sanktionen der Mitgliedstaaten in Art. 50, Geltungstermine in Art. 64).
• EUR-Lex, Commission Delegated Regulation (EU) 2025/301 (Fristen für Erstmeldung, Zwischen- und Abschlussbericht bei schwerwiegenden Vorfällen).
• EUR-Lex, Commission Implementing Regulation (EU) 2024/2956 (Vorlagen für das Informationsregister).
• EUR-Lex, Commission Delegated Regulation (EU) 2025/1190 (RTS zu bedrohungsgeleiteten Penetrationstests).
• ESMA, European Supervisory Authorities designate critical ICT third-party providers (erste CTPP-Benennungen, 18. November 2025).
• ESMA, ESAs announce timeline to collect information for the designation of critical ICT third-party service providers (Übermittlung der Register durch die zuständigen Behörden bis 30. April 2025; veröffentlicht am 15. November 2024).
• EUR-Lex, Directive (EU) 2022/2555 (NIS2) (Verhältnis zu sektorspezifischen Rechtsakten wie DORA).
• Bank for International Settlements, BCBS 239: Principles for effective risk data aggregation and risk reporting (Vergleich mit BCBS 239).