DORA Verordnung — Digitale Resilienz für Finanzunternehmen

Die DORA-Verordnung (EU 2022/2554) regelt seit Januar 2025 die digitale operationelle Resilienz für Finanzunternehmen in der EU. Für Institute, Versicherer, Zahlungsdienstleister, Wertpapierhäuser und weitere Finanzakteure bedeutet das: IKT-Risiken, Vorfallmeldungen, Resilienztests und Drittparteiensteuerung sind nicht mehr nur IT-Themen, sondern verbindliche Aufsichtspflichten.

Wenn Sie einzelne Detailthemen vertiefen wollen, springen Sie direkt in unsere Beiträge zu DORA-Anforderungen, DORA-Schulung, DORA vs. NIS2, DORA-Incident-Reporting, DORA für IT-Dienstleister und zur Branche Versicherungen. Dieser Beitrag ist die zentrale Pillar-Seite für alle DORA-Themen im Wissensbereich.

Was ist DORA (Digital Operational Resilience Act)?

DORA ist die Abkürzung für den Digital Operational Resilience Act, also die Verordnung (EU) 2022/2554 über die digitale operationelle Resilienz des Finanzsektors. Die Verordnung wurde am 14. Dezember 2022 verabschiedet, im Amtsblatt der EU veröffentlicht und gilt seit dem 17. Januar 2025 unmittelbar in allen Mitgliedstaaten.

Der Kern von DORA ist einfach: Finanzunternehmen sollen ihre kritischen und wichtigen digitalen Funktionen auch unter Störungen, Cyberangriffen, Systemausfällen oder Problemen bei IKT-Dienstleistern sicher aufrechterhalten können. DORA ist deshalb keine reine Cybersecurity-Regel, sondern ein umfassender Governance-Rahmen für Widerstandsfähigkeit, Wiederherstellung und Aufsicht im Finanzsektor.

Anders als lose Best Practices oder rein nationale Rundschreiben arbeitet DORA mit klaren Kapiteln, Artikeln und Aufsichtserwartungen. Für die Praxis sind vor allem fünf Themenblöcke entscheidend: IKT-Risikomanagement, Management und Meldung IKT-bezogener Vorfälle, Tests der digitalen Betriebsstabilität, Steuerung von IKT-Drittparteirisiken und geregelter Informationsaustausch. Genau diese fünf Säulen bilden die operative Struktur fast jedes DORA-Programms.

Wichtig ist außerdem die Reichweite. DORA richtet sich nicht nur an Banken. Auch Zahlungsdienstleister, E-Geld-Institute, Wertpapierfirmen, Versicherungen, Pensionskassen, Fondsmanager, Handelsplätze, Krypto-Dienstleister und weitere regulierte Marktakteure fallen in den Anwendungsbereich. Wer im Finanzsektor tätig ist, sollte deshalb nicht fragen, ob DORA relevant ist, sondern ob und in welcher Rolle das eigene Unternehmen erfasst wird.

Wen betrifft DORA — 21 Kategorien von Finanzunternehmen

DORA betrifft nicht „die Finanzbranche“ im vagen Sinn, sondern einen konkret definierten Katalog von Finanzunternehmen. Art. 2 der Verordnung (EU) 2022/2554 zählt die betroffenen Kategorien auf; technische EU-Durchführungsakte arbeiten diesen Katalog inzwischen in standardisierten Melde- und Registerformaten mit 21 Hauptkategorien aus.

Für die Praxis lässt sich dieser Katalog in vier Gruppen ordnen:

Die 21 Kategorien, wie sie in den aktuellen EU-Templates für DORA-Meldungen und Register sichtbar werden, sind im Überblick:

1. Kreditinstitute
2. Zahlungsinstitute einschließlich befreiter Zahlungsinstitute
3. Kontoinformationsdienstleister
4. E-Geld-Institute einschließlich befreiter E-Geld-Institute
5. Wertpapierfirmen
6. Kryptowerte-Dienstleister
7. Emittenten vermögenswertereferenzierter Token
8. Zentralverwahrer
9. Zentrale Gegenparteien
10. Handelsplätze
11. Transaktionsregister
12. Verwalter alternativer Investmentfonds
13. Verwaltungsgesellschaften
14. Datenbereitstellungsdienste
15. Versicherungs- und Rückversicherungsunternehmen
16. Versicherungsvermittler, Rückversicherungsvermittler und gebundene Versicherungsvermittler
17. Einrichtungen der betrieblichen Altersversorgung
18. Ratingagenturen
19. Administratoren kritischer Benchmarks
20. Crowdfunding-Dienstleister
21. Verbriefungsregister

Die entscheidende Botschaft lautet: DORA ist weit breiter als klassische Bankenaufsicht. Gerade Fintechs, Insurtechs, Marktinfrastrukturbetreiber und Krypto-Unternehmen unterschätzen häufig, dass DORA für sie ebenso relevant sein kann wie für etablierte Institute.

Die 5 Säulen von DORA

DORA ist operativ am leichtesten über seine fünf Säulen zu verstehen. Genau diese Struktur sollten Finanzunternehmen auch für Gap-Analysen, Maßnahmenpläne, Schulungen und Management-Reports nutzen.

IKT-Risikomanagement (Kap. II, Art. 5-16)

Die erste Säule ist das IKT-Risikomanagement, und sie ist das Fundament von DORA. Finanzunternehmen müssen gemäß Kapitel II ein internes Rahmenwerk aufsetzen, mit dem sie IKT-Risiken identifizieren, bewerten, steuern, überwachen und dokumentieren.

Praktisch verlangt diese Säule mehr als eine Sicherheitsrichtlinie. Institute brauchen ein belastbares Inventar ihrer IKT-Systeme, eine Abbildung kritischer und wichtiger Funktionen, klare Zuständigkeiten, Schutzmaßnahmen, Überwachungsprozesse, Wiederherstellungsmechanismen und regelmäßige Reviews. Das Management ist dabei nicht Zuschauer, sondern verantwortlich für Genehmigung, Kontrolle und fortlaufende Überprüfung des Rahmens.

Besonders relevant ist der Governance-Charakter. DORA verlangt kein isoliertes IT-Sicherheitsprojekt, sondern einen durch das Leitungsorgan verantworteten Steuerungsansatz. Vorstände, Geschäftsführung und vergleichbare Leitungsorgane müssen Risiken verstehen, Entscheidungen dokumentieren und sich regelmäßig berichten lassen. Wer DORA nur in der Informationssicherheit „parkt“, verfehlt den aufsichtsrechtlichen Ansatz.

Für die Umsetzung ist meist ein Stufenmodell sinnvoll:

1. Kritische und wichtige Funktionen definieren.
2. IKT-Assets, Datenflüsse und Abhängigkeiten kartieren.
3. Schutz-, Erkennungs-, Reaktions- und Wiederherstellungsprozesse dokumentieren.
4. Rollen von IT, Security, Risk, Compliance, Einkauf und Fachbereich sauber zuordnen.
5. Regelmäßige Management-Reviews verankern.

IKT-Vorfallmanagement und -meldung (Kap. III, Art. 17-23)

Die zweite Säule betrifft IKT-bezogene Vorfälle und deren Meldung. Finanzunternehmen müssen Vorfälle nicht nur technisch behandeln, sondern nach einheitlichen Kriterien erfassen, klassifizieren, eskalieren und bei Erreichen der Schwellenwerte an die zuständige Aufsicht melden.

Der Unterschied zur üblichen Incident-Response-Praxis ist erheblich. DORA verlangt eine Aufsichtsperspektive auf Vorfälle: Welche Störung ist „major“, wann muss sie klassifiziert werden, welche Inhalte sind zu melden, welche Zwischenberichte folgen und wie wird der Abschlussbericht aufgebaut? Deshalb reicht ein internes Ticket-System ohne regulatorische Klassifikationslogik nicht aus.

In der Praxis sind drei Punkte kritisch:

1. Vorfälle müssen früh und konsistent klassifiziert werden.
2. Meldeketten zwischen Betrieb, Security, Compliance und Aufsicht müssen vorab definiert sein.
3. Dienstleister müssen vertraglich so eingebunden sein, dass relevante Informationen rechtzeitig vorliegen.

Wer dieses Thema vertiefen möchte, findet die operative Tiefe im Beitrag zu DORA-Incident-Reporting. Für viele Institute ist genau diese Säule der akuteste Umsetzungsdruck, weil verspätete oder unvollständige Meldungen unmittelbar aufsichtsrelevant werden können.

Testen der digitalen Betriebsstabilität (Kap. IV, Art. 24-27)

Die dritte Säule ist das Testen der digitalen Betriebsstabilität. DORA verlangt damit ausdrücklich mehr als einen sporadischen Penetrationstest. Finanzunternehmen müssen ihr Resilienzniveau aktiv prüfen, dokumentieren und aus den Ergebnissen Verbesserungen ableiten.

Die Tests sollen zum Risiko, zur Größe und zur Kritikalität des Unternehmens passen. Dazu können Schwachstellenanalysen, Szenariotests, Wiederanlauftests, Failover-Übungen, Krisensimulationen oder fortgeschrittene testspezifische Verfahren gehören. Für besonders relevante Unternehmen kommen auch bedrohungsgeleitete Penetrationstests in Betracht.

Wesentlich ist nicht nur der Test selbst, sondern der Regelkreis danach. DORA erwartet, dass Ergebnisse in Maßnahmen, Fristen, Verantwortlichkeiten und Nachtests übersetzt werden. Ein Testbericht ohne Remediation ist regulatorisch zu wenig. Genau hier scheitern viele Programme: Sie testen, aber sie steuern die Konsequenzen nicht verbindlich nach.

IKT-Drittparteienrisikomanagement (Kap. V, Art. 28-44)

Die vierte Säule betrifft IKT-Drittparteien und ist für die meisten Finanzunternehmen einer der größten Aufwandsblöcke. DORA behandelt Cloud, Software, Infrastruktur, Plattformen, Managed Services und weitere digitale Abhängigkeiten nicht als Nebenthema, sondern als zentrales Resilienzrisiko.

Institute müssen Drittparteirisiken vor Vertragsschluss, während der Leistungserbringung und bei Beendigung der Beziehung steuern. Dazu gehören unter anderem Due Diligence, Risikoanalysen, Dokumentation kritischer oder wichtiger Auslagerungen, zwingende Vertragsklauseln, Audit- und Zugriffsrechte, Exit-Strategien, Konzentrationsrisiken und laufendes Monitoring.

Diese Säule ist deshalb so relevant, weil viele Finanzunternehmen große Teile ihrer Betriebsrealität an Cloud- oder SaaS-Anbieter ausgelagert haben. Ohne saubere Vertragsgrundlagen und eine aktuelle Abhängigkeitsübersicht wird DORA schnell zur Dokumentationslücke. Für die Lieferantenseite vertiefen wir das in DORA für IT-Dienstleister.

Informationsaustausch (Kap. VI, Art. 45)

Die fünfte Säule ist der Informationsaustausch. DORA erlaubt Finanzunternehmen unter bestimmten Bedingungen den Austausch von Informationen und Erkenntnissen über Cyberbedrohungen, Schwachstellen, Taktiken und Schutzmaßnahmen.

Der Zweck ist nicht Marketing, sondern kollektive Resilienz. Gerade im Finanzsektor können Muster aus Angriffen, Störungen oder Drittparteienproblemen schnell sektorrelevant werden. DORA schafft dafür einen geregelten Rahmen, ohne die übrigen Vorgaben zu Datenschutz, Vertraulichkeit und Wettbewerbsrecht auszublenden.

Für viele Häuser ist diese Säule nicht der erste Umsetzungshebel. Sie wird aber wichtig, sobald Institute ihre Reife erhöhen und sektorübergreifende Frühwarn- und Austauschmechanismen sinnvoll nutzen wollen.

DORA als Lex Specialis zu NIS2

DORA ist für Finanzunternehmen nicht einfach „eine weitere Cyberregel neben NIS2“, sondern die sektorspezifische Spezialregel. Genau deshalb ist der Begriff Lex Specialis so wichtig: Das speziellere Gesetz geht dem allgemeineren Gesetz vor, soweit es denselben Regelungsbereich präziser abdeckt.

Für DORA ist das nicht nur juristische Theorie. Art. 1 Abs. 2 der Verordnung stellt klar, dass DORA gegenüber der NIS2-Richtlinie als sektorbezogener Unionsrechtsakt gilt. Die Folge ist: Für Finanzunternehmen verdrängen die DORA-Vorgaben insbesondere in den Bereichen IKT-Risikomanagement, Vorfallmanagement, Meldung schwerwiegender IKT-bezogener Vorfälle, Resilienztests und IKT-Drittparteienrisiken die allgemeineren NIS2-Regeln.

Das bedeutet aber nicht, dass NIS2 im Finanzsektor vollständig bedeutungslos wäre. Wo DORA eine Materie spezifisch regelt, ist DORA maßgeblich. Wo DORA keine spezifische Sonderregel enthält oder andere horizontale Anforderungen einschlägig bleiben, müssen Finanzunternehmen die Schnittstellen weiter sauber prüfen. Genau deshalb empfiehlt sich in größeren Häusern eine Compliance-Matrix statt der pauschalen Annahme „DORA ersetzt alles“.

Die praktische Faustregel lautet:

Wenn Sie diese Abgrenzung operativ aufarbeiten wollen, ist unser Vergleich DORA vs. NIS2 der passende Deep Dive.

Fristen und Inkrafttreten — Seit 17. Januar 2025

Die wichtigste Frist ist bereits erreicht: DORA gilt seit dem 17. Januar 2025. Seit diesem Datum handelt es sich nicht mehr um ein Vorbereitungsprojekt, sondern um laufende Compliance im Wirkbetrieb.

Für die Praxis hilft ein kurzer Zeitstrahl:

Viele Institute haben DORA zunächst vor allem als Projekt für Policies, Register und Verträge verstanden. Seit dem 17. Januar 2025 prüfen Aufsicht und Interne Revision aber zu Recht, ob Prozesse tatsächlich funktionieren: Werden Vorfälle klassifiziert? Sind Drittparteien erfasst? Gibt es belastbare Testpläne? Werden Managemententscheidungen dokumentiert? Gibt es Schulungsnachweise für die relevanten Rollen?

Genau an diesem Punkt wird DORA schnell zu einem Schulungs- und Governance-Thema. Richtlinien helfen nur, wenn Fachbereiche, IT, Security, Beschaffung, Compliance und Management dieselben Begriffe, Eskalationswege und Kontrollpunkte verstehen. Mehr dazu lesen Sie in unserem Beitrag DORA-Schulung.

Bußgelder und Sanktionen

DORA kennt Sanktionen, aber nicht in Form eines einfachen, einheitlichen Bußgeldkatalogs für alle Finanzunternehmen in der EU. Wer hier mit einer einzigen Maximalzahl argumentiert, verkürzt die Rechtslage zu stark.

Richtig ist: Zuständige Behörden können Maßnahmen, Anordnungen und Sanktionen durchsetzen, wenn Finanzunternehmen ihre Pflichten nicht erfüllen. Hinzu kommt die spezifische Aufsicht über kritische IKT-Drittdienstleister. Für diese kritischen Anbieter sieht DORA ausdrücklich periodische Zwangsgelder vor, die bis zu 1 % des durchschnittlichen täglichen weltweiten Umsatzes des vorangegangenen Geschäftsjahres pro Tag betragen können, und zwar für bis zu sechs Monate.

Für Finanzunternehmen selbst ist die Lage differenzierter:

1. Aufsichtsmaßnahmen können verbindliche Anordnungen und Abhilfemaßnahmen umfassen.
2. Nationale Sanktionsregime und sektoraufsichtliche Instrumente bleiben relevant.
3. Reputationsschäden, Sonderprüfungen und verschärfte Aufsicht sind oft fast so gravierend wie finanzielle Sanktionen.

Die sinnvolle Management-Aussage lautet daher nicht „DORA kostet maximal X Euro“, sondern: DORA-Verstöße können operative Einschränkungen, intensive Aufsicht, Reputationsschäden und je nach Fall erhebliche finanzielle Folgen nach sich ziehen. Gerade bei Vorfällen, Drittparteien oder dokumentierten Steuerungsdefiziten ist diese Wirkung real.

Was Finanzunternehmen jetzt tun müssen — Checkliste

Finanzunternehmen sollten DORA jetzt als Betriebsmodell und nicht als Dokumentenprojekt behandeln. Wer 2026 noch immer an Grundlagen arbeitet, ist zu spät.

Die folgende Checkliste ist ein pragmatischer Startpunkt:

1. Anwendungsbereich sauber bestimmen. Prüfen Sie, in welche DORA-Kategorie Ihr Unternehmen fällt und welche Gruppenunternehmen zusätzlich betroffen sind.
2. Kritische und wichtige Funktionen definieren. Ohne diese Einordnung bleiben Asset-Inventar, Vorfallschwellen und Drittparteiensteuerung unscharf.
3. IKT-Landschaft und Abhängigkeiten kartieren. Dokumentieren Sie Systeme, Datenflüsse, Schnittstellen und besonders kritische Dienstleister.
4. Incident Governance regulatorisch ausrichten. Ergänzen Sie Klassifikation, Eskalation, Rollen und Meldewege um die DORA-Perspektive.
5. Testprogramm aufbauen oder schärfen. Planen Sie risikobasierte Resilienztests mit Maßnahmenverfolgung.
6. Drittparteiverträge prüfen. Kontrollieren Sie Auditrechte, Informationspflichten, Exit-Regelungen und Vorfallkommunikation.
7. Management-Berichterstattung etablieren. DORA ist nur belastbar umgesetzt, wenn das Leitungsorgan regelmäßig informiert und eingebunden ist.
8. Rollenbezogene Schulungen durchführen. IT, Security, Risk, Compliance, Einkauf, Auslagerungssteuerung und Management brauchen jeweils angepasste Inhalte.
9. Schnittstellen zu NIS2, MaRisk, BAIT-Nachfolgeregeln und anderen Aufsichtsvorgaben dokumentieren. DORA ersetzt kein sauberes Gesamtbild.
10. Nachweise revisionsfest sichern. Policies, Protokolle, Tests, Reports, Verträge und Schulungsunterlagen müssen konsistent auffindbar sein.

Wer diese Schritte strukturieren möchte, findet die Detailanforderungen in DORA-Anforderungen. Für Häuser mit Versicherungsfokus ist außerdem die Branchenseite Versicherungen relevant, weil dort DORA mit sektoralen Besonderheiten zusammenläuft.

Für die ersten 90 Tage empfiehlt sich ein klarer Umsetzungsrhythmus statt eines unstrukturierten Sammelprojekts:

Der typische Fehler in dieser Phase ist eine Reihenfolge von „Policy zuerst, Realität später“. Belastbar ist DORA nur, wenn die Dokumente aus realen Prozessen entstehen: aus tatsächlichen Systemen, tatsächlichen Dienstleistern, tatsächlichen Eskalationswegen und tatsächlichen Managemententscheidungen. Genau deshalb sollten Finanzunternehmen zunächst Transparenz schaffen, dann Steuerung verbindlich machen und erst danach in die Verfeinerung einzelner Dokumente gehen.

Ebenso wichtig ist die Schulungslogik. Das Leitungsorgan braucht vor allem Entscheidungs- und Überwachungswissen, IT und Security brauchen prozessuale Tiefe, Einkauf und Auslagerungssteuerung müssen Drittparteienklauseln und Exit-Szenarien verstehen, und Compliance sowie Risikomanagement müssen Aufsicht, Evidenz und Kontrollrahmen zusammenführen. Eine rollenbezogene DORA-Schulung ist deshalb in der Regel wirksamer als ein allgemeines Cybersecurity-Format ohne Finanzsektorbezug.

Häufig gestellte Fragen (FAQ)

Gilt DORA auch für kleine Finanzunternehmen?

Ja, DORA gilt nicht nur für Großbanken. Maßgeblich ist zunächst, ob ein Unternehmen in den Anwendungsbereich des Art. 2 der Verordnung (EU) 2022/2554 fällt. Die Verordnung arbeitet zwar mit dem Verhältnismäßigkeitsprinzip, enthält aber keine generelle Ausnahme für kleine Finanzunternehmen.

Was ist der Unterschied zwischen DORA und NIS2?

DORA ist die sektorspezifische Spezialregel für die digitale operationelle Resilienz im Finanzsektor, während NIS2 sektorübergreifend für kritische und wichtige Einrichtungen gilt. Für Finanzunternehmen verdrängt DORA als Lex Specialis vor allem die NIS2-Vorgaben zu IKT-Risikomanagement, Incident Reporting, Resilienztests und IKT-Drittparteirisiken.

Müssen IT-Dienstleister DORA erfüllen?

IT-Dienstleister fallen nicht automatisch vollständig unter DORA wie ein Finanzunternehmen. Relevant wird DORA aber sehr wohl, wenn sie IKT-Drittdienstleistungen für Finanzunternehmen erbringen. Dann müssen Verträge, Meldewege, Auditrechte, Sicherheitsmaßnahmen und gegebenenfalls die Aufsicht über kritische IKT-Drittdienstleister berücksichtigt werden.

Welche Schulungspflichten gibt es unter DORA?

DORA verlangt im Rahmen des IKT-Risikomanagements, dass Mitarbeitende mit Aufgaben rund um kritische oder wichtige Funktionen die Prozesse, Risiken und Eskalationswege verstehen. In der Praxis betrifft das insbesondere IT, Informationssicherheit, Risikomanagement, Compliance, Beschaffung, Auslagerungssteuerung und das Management. Die Schulung sollte rollenbezogen, regelmäßig und dokumentiert erfolgen.

Seit wann gilt DORA?

Die Verordnung (EU) 2022/2554 ist seit dem 17. Januar 2025 anwendbar. Seit diesem Datum müssen betroffene Finanzunternehmen ihre DORA-Pflichten operativ erfüllen und nicht nur vorbereiten.

Nächster Schritt für Ihr DORA-Programm

Der nächste sinnvolle Schritt ist kein weiteres PDF, sondern ein gemeinsames Verständnis im Unternehmen, wie DORA praktisch funktioniert. Wenn Ihr Haus DORA-Anforderungen, Incident Reporting, Drittparteiensteuerung und Schulungsnachweise belastbar zusammenziehen will, nutzen Sie unsere DORA-Schulung als Einstieg und vertiefen Sie danach die operativen Bausteine über DORA-Anforderungen, DORA-Incident-Reporting und DORA für IT-Dienstleister.