Was DORA ist und seit wann sie gilt
DORA ist die EU-Verordnung über die digitale operationale Resilienz im Finanzsektor. Anders als eine Richtlinie, die erst in nationales Recht umgesetzt werden muss, gilt eine Verordnung unmittelbar in allen Mitgliedstaaten — ohne Umsetzungsgesetz und grundsätzlich mit demselben Wortlaut überall. DORA wurde Ende 2022 verabschiedet und ist nach einer zweijährigen Vorbereitungsphase seit dem 17. Januar 2025 anwendbar (Verordnung (EU) 2022/2554). Ihr Ziel ist es, die zuvor fragmentierten Anforderungen an IT-Sicherheit und Ausfallsicherheit im Finanzsektor zu einem einheitlichen, verbindlichen Rahmenwerk zusammenzuführen.
Die drei Europäischen Aufsichtsbehörden (ESAs) — die Europäische Bankenaufsichtsbehörde (EBA), die Europäische Wertpapier- und Marktaufsichtsbehörde (ESMA) und die Europäische Aufsichtsbehörde für das Versicherungswesen und die betriebliche Altersversorgung (EIOPA) — haben die technischen Detailregeln in Form von technischen Regulierungs- und Durchführungsstandards (RTS und ITS) ausgearbeitet (ESAs). Die laufende Aufsicht über die einzelnen Finanzunternehmen liegt bei den zuständigen nationalen Behörden, während die kritischen IKT-Drittdienstleister direkt auf EU-Ebene beaufsichtigt werden (Verordnung (EU) 2022/2554).
Für die betroffenen Unternehmen bedeutet der unmittelbare Geltungsbeginn, dass die Vorbereitung bereits abgeschlossen sein sollte. Die zweijährige Frist zwischen Inkrafttreten und Anwendbarkeit war die eigentliche Umsetzungsphase — seit Januar 2025 zählt der Ist-Zustand. DORA führt dabei zuvor verstreute Vorgaben zusammen, etwa zu Auslagerung, IT-Sicherheit und Vorfallmeldung, und hebt sie auf ein einheitliches, prüfbares Niveau (Verordnung (EU) 2022/2554). Wer seine Prozesse, Verträge und Nachweise erst jetzt aufsetzt, arbeitet damit nicht mehr auf eine künftige Frist hin, sondern schließt eine bereits offene Lücke.
DORA gilt unmittelbar und musste nicht wie die NIS2-Richtlinie erst in nationales Recht überführt werden. Für Unternehmen, die sowohl unter DORA als auch unter NIS2 fallen, gilt DORA als sektorspezifische Sonderregel (lex specialis) für die IKT-Anforderungen des Finanzsektors (Verordnung (EU) 2022/2554).
Wer in den Anwendungsbereich fällt
Der Anwendungsbereich von DORA ist einer der breitesten im EU-Finanzrecht. Artikel 2 der Verordnung nennt 21 Kategorien von Finanzunternehmen (Verordnung (EU) 2022/2554); in der Summe fallen EU-weit über 22.000 Finanzunternehmen in den Anwendungsbereich (PwC). Erfasst werden nicht nur die großen, systemrelevanten Institute, sondern auch viele kleinere und spezialisierte Akteure — vom Zahlungsinstitut bis zum Krypto-Dienstleister.
Banken und Kreditinstitute jeder Größe, von der Großbank bis zum regionalen Institut.
Zahlungsdienstleister, E-Geld-Institute und Kontoinformationsdienste.
Wertpapierfirmen, Fondsverwalter und Anbieter von Handelsplätzen.
Versicherungs- und Rückversicherungsunternehmen sowie Versicherungsvermittler.
Anbieter von Krypto-Dienstleistungen und Emittenten wertreferenzierter Token nach MiCAR.
Als kritisch eingestufte IKT-Dienstleister unterstehen direkt der EU-Aufsicht durch die ESAs.
Neben den Finanzunternehmen selbst adressiert DORA ausdrücklich deren IKT-Drittdienstleister. Über die Vertragsanforderungen der Finanzunternehmen werden Sicherheits- und Resilienzpflichten in die Lieferkette weitergereicht. Zusätzlich können einzelne Dienstleister als kritische IKT-Drittdienstleister (CTPPs) eingestuft werden und unterliegen dann einer direkten, EU-weiten Aufsicht durch die ESAs (Verordnung (EU) 2022/2554).
Wer Finanzunternehmen mit Web-, API- oder Hosting-Leistungen beliefert, bekommt DORA-Anforderungen vertraglich weitergereicht — etwa zu Verfügbarkeit, Meldewegen und Nachweisführung. Das ähnelt dem Lieferketten-Gedanken, der auch der Überwachung der Skript-Integrität und Client-Side-Security nach PCI DSS 4.0.1 zugrunde liegt.
Die fünf Säulen von DORA
DORA ordnet die Anforderungen an digitale Resilienz in fünf thematische Säulen. Sie greifen ineinander: Ohne durchgängiges Risikomanagement gibt es keine belastbare Vorfallbehandlung, und ohne Vorfallbehandlung keine fristgerechte Meldung (Verordnung (EU) 2022/2554).
Ein umfassender Rahmen mit Strategien, Leitlinien, Verfahren und Werkzeugen, um IKT-Risiken zu erkennen, zu schützen und zu überwachen — verantwortet vom Leitungsorgan.
Ein Prozess, um IKT-Vorfälle zu erkennen, zu klassifizieren und die schwerwiegenden fristgerecht an die zuständige Behörde zu melden.
Regelmäßige Tests der digitalen operationalen Resilienz, für bestimmte Institute bis hin zu bedrohungsorientierten Penetrationstests (TLPT).
Steuerung und Überwachung der Auslagerungen an IKT-Dienstleister, inklusive eines vollständigen Informationsregisters.
Freiwilliger Austausch von Erkenntnissen über Cyberbedrohungen und Schwachstellen zwischen Finanzunternehmen.
Für die Praxis auf der Web- und API-Ebene sind vor allem die erste, zweite und vierte Säule relevant: Die kontinuierliche Überwachung von Verfügbarkeit und Integrität zahlt auf das IKT-Risikomanagement ein, die zeitgestempelte Erkennung auf die Vorfallbehandlung, und die Überwachung ausgelagerter Dienste auf das Drittparteienrisiko. Wer die technischen Sicherheitsgrundlagen dahinter vertiefen möchte, findet in den OWASP Top 10 2025 der wichtigsten Web-Risiken eine strukturierte Orientierung.
Die IKT-Vorfall-Meldefristen: 4 h, 72 h, 1 Monat
Das operative Herzstück von DORA ist die gestaffelte Meldung schwerwiegender IKT-Vorfälle. Ob ein Vorfall als schwerwiegend gilt, richtet sich nach Kriterien, die die ESAs in den technischen Standards festgelegt haben — darunter die Zahl betroffener Kunden, die Dauer und geografische Ausbreitung der Störung, Datenverluste, wirtschaftliche Auswirkungen und die Kritikalität der betroffenen Dienste (ESAs). Erst wenn ein Vorfall diese Schwelle erreicht und als schwerwiegend klassifiziert wird, beginnen die eigentlichen Meldefristen zu laufen.
- Erstmeldung (initial notification) — so früh wie möglich, in jedem Fall innerhalb von 4 Stunden ab der Klassifizierung als schwerwiegend und spätestens 24 Stunden nach Kenntnis des Vorfalls (ESAs, RTS zur IKT-Vorfallmeldung).
- Zwischenmeldung (intermediate report) — spätestens 72 Stunden nach der Erstmeldung, mit aktualisiertem Sachstand; eine weitere Aktualisierung folgt, sobald der Regelbetrieb wiederhergestellt ist (ESAs).
- Abschlussmeldung (final report) — spätestens einen Monat nach der (letzten aktualisierten) Zwischenmeldung, mit Ursachenanalyse, Auswirkungen und getroffenen Maßnahmen (ESAs).
Eine begrenzte Fristverlängerung über Wochenenden und Feiertage gilt nicht für alle Institute gleichermaßen; für Kreditinstitute, zentrale Gegenparteien, Handelsplatzbetreiber und unter NIS2 als wesentlich oder wichtig eingestufte Einrichtungen entfällt sie (ESAs). In der Praxis bedeutet das: Die enge 4-Stunden-Frist ist für viele Adressaten die Regel, nicht die Ausnahme.
Die 4-Stunden-Frist läuft ab der Klassifizierung — und die kann nur erfolgen, wenn der Vorfall überhaupt bemerkt wurde. Wird ein Ausfall oder eine Manipulation erst Stunden später zufällig entdeckt, verschiebt sich die Klassifizierung entsprechend, und die verbleibende Reaktionszeit schrumpft. Je früher und je präziser der Erkennungszeitpunkt zeitgestempelt ist, desto realistischer bleibt eine geordnete, fristgerechte Meldung.
Neben der Pflichtmeldung schwerwiegender Vorfälle können Finanzunternehmen erhebliche Cyberbedrohungen freiwillig melden. Sind Kunden von einem Vorfall betroffen, sind sie zudem ohne unangemessene Verzögerung zu informieren (Verordnung (EU) 2022/2554). Die Meldekette endet also nicht bei der Aufsicht, sondern schließt die Kommunikation nach außen mit ein.
Das Informationsregister der IKT-Drittparteien
Eine eigenständige Pflicht ist das Register der Informationen (Register of Information, RoI). Jedes Finanzunternehmen muss ein vollständiges Verzeichnis aller vertraglichen Vereinbarungen mit IKT-Drittdienstleistern führen — auf Einzel-, teilkonsolidierter und konsolidierter Ebene. Die zuständigen Behörden hatten dieses Register erstmals bis zum 30. April 2025 an die ESAs zu übermitteln (EBA). Das Register ist damit nicht bloß Dokumentation, sondern ein aktives Aufsichtsinstrument, um Konzentrationsrisiken in der Lieferkette sichtbar zu machen.
Wie anspruchsvoll die Datenqualität dabei ist, zeigte der freiwillige Probelauf Ende 2024: Rund 1.000 Finanzunternehmen nahmen teil, davon reichten 1.039 ihre Register unter realistischen Bedingungen ein (EBA/ESAs). Viele Teilnehmer stellten fest, dass die lückenlose und korrekte Erfassung von Verträgen, Dienstleister-Kennungen und Funktionsketten mehr Aufwand erfordert als zunächst angenommen.
Am 18. November 2025 haben die ESAs die erste Liste designierter kritischer IKT-Drittdienstleister veröffentlicht — 19 Anbieter, darunter mehrere große Cloud- und Plattformanbieter, unterliegen seither einer direkten EU-Aufsicht (EBA/ESMA/EIOPA). Für Finanzunternehmen unterstreicht das, wie stark die eigene Resilienz an der Verfügbarkeit ausgelagerter Dienste hängt.
Warum die Web- und API-Ebene zur Resilienz-Evidenz wird
DORA ist ein breites Governance-Rahmenwerk — im operativen Kern geht es jedoch um die Verfügbarkeit und Integrität von Diensten. Genau dort, an der öffentlichen Web- und API-Ebene, werden Störungen zuerst sichtbar: ein nicht erreichbares Kundenportal, eine langsame oder fehlerhafte Zahlungs-API, ein abgelaufenes Zertifikat, eine manipulierte Seite. Kontinuierliche, automatisierte Überwachung verwandelt die abstrakte Resilienzpflicht in messbare, zeitgestempelte Evidenz.
Mehrregionale Checks erkennen Ausfälle in Minuten und dokumentieren Beginn und Ende mit Zeitstempel — die Basis des Uptime-Monitorings.
Zahlungs- und Kundendaten-Schnittstellen werden gegen Assertions und Schwellenwerte geprüft, wie im API-Monitoring beschrieben.
Ablaufende oder zurückgezogene Zertifikate und Veränderungen an DNS-Einträgen werden früh gemeldet, bevor daraus eine Störung wird.
Visuelle und inhaltliche Abweichungen werden gegen eine Baseline geprüft — Grundlage der Screenshot- und Defacement-Überwachung.
Sicherheitsrelevante HTTP-Header und gängige Schwachstellenmuster werden regelmäßig gegen den Security-Scan geprüft.
Jeder relevante Zustandswechsel wird mit Zeitstempel protokolliert — die lücken- und manipulationsarme Chronik für die Meldekette.
Wichtig ist die ehrliche Einordnung: Ein Web-Monitoring ist ein operativer Baustein, kein Ersatz für das gesamte IKT-Risikomanagement. Es liefert die zeitlich präzise Erkennung und die Nachweisführung für die Verfügbarkeits- und Integritätsschicht — die rechtliche Bewertung, ob ein Vorfall im Sinne von DORA schwerwiegend ist, treffen die Verantwortlichen im Einzelfall, idealerweise mit fachlicher und juristischer Begleitung.
Von der Überwachung zur belegbaren Meldekette
Der eigentliche Compliance-Nutzen liegt in der Verkettung: Ereignis, Erkennung, Klassifizierung, Erstmeldung, Zwischenmeldung, Abschlussmeldung. Ein kontinuierliches Monitoring erkennt den Statuswechsel selbst, versieht ihn mit einem Zeitstempel und alarmiert die Kontaktstelle. Dieses Protokoll — wann eine Störung begann, wann sie erkannt wurde, wann sie behoben war — speist alle drei Meldestufen und bleibt als Beleg erhalten.
| Dimension | Ohne kontinuierliche Überwachung | Mit kontinuierlicher Überwachung |
|---|---|---|
| Erkennung eines Ausfalls | oft erst durch Kundenhinweis, Stunden später | automatisiert, typischerweise in Minuten |
| Startzeitpunkt der Frist | unklar, schwer belegbar | zeitgestempelt und nachvollziehbar |
| Nachweis für die Meldung | nachträglich rekonstruiert | lücken- und manipulationsarme Historie |
| Statuskommunikation | ad hoc und uneinheitlich | Statuspage mit dokumentiertem Incident-Verlauf |
| Abschlussbericht | aufwendige Handarbeit | aus dem Protokoll ableitbar |
Die 4-Stunden-Frist läuft ab der Klassifizierung. Wer früh und zeitgestempelt erkennt, gewinnt genau die Stunden, die über eine geordnete, fristgerechte Erstmeldung entscheiden.
— XICTRAQ Compliance-Monitoring
Damit aus Rohdaten belastbare Nachweise werden, braucht es zwei Dinge: eine verlässliche Alarmierung mit Eskalation und ein sauberes Reporting. Die Alarmkette bis zur richtigen Person beschreibt der Beitrag zum Incident-Management mit Eskalationsstufen; die betriebswirtschaftliche Seite einer schnellen Erkennung zeigt der Beitrag zu den Kosten von Website-Ausfällen. Für die dokumentierte Außenkommunikation während eines Vorfalls dient eine öffentliche Statusseite für Kunden, und für die belastbare Grenzwertsteuerung helfen Error-Budgets und Burn-Rate-Alerts. Reporting und Statuspage bilden zusammen die lückenarme Resilienz- und Incident-Evidenz, die DORA in der Praxis so wertvoll macht.
Bußgelder und Aufsicht: Was auf dem Spiel steht
DORA ist mit spürbaren Durchsetzungsmitteln versehen. Für kritische IKT-Drittdienstleister kann der federführende Überwacher ein Zwangsgeld von bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes verhängen — täglich, für einen Zeitraum von bis zu sechs Monaten, bis die geforderten Maßnahmen umgesetzt sind (Verordnung (EU) 2022/2554, Art. 35). Für die Finanzunternehmen selbst legen die Mitgliedstaaten die konkreten verwaltungsrechtlichen Sanktionen und Maßnahmen fest; verantwortlich ist ausdrücklich auch das Leitungsorgan (Verordnung (EU) 2022/2554).
Dass die Aufsicht die tatsächliche Widerstandsfähigkeit prüft, zeigte bereits der Cyber-Resilienz-Stresstest der Europäischen Zentralbank: 2024 nahmen 109 direkt beaufsichtigte Banken teil, eine Teilstichprobe von 28 durchlief vertiefte Tests inklusive echter Wiederherstellungsprüfungen (EZB 2024). Parallel bleibt die Bedrohungslage hoch — im ENISA-Bedrohungslagebild für den Finanzsektor war die Branche das dritthäufigste Angriffsziel, und bei den beobachteten DDoS-Vorfällen entfielen 58 % auf Banken (ENISA 2024). Auch wirtschaftlich sind Zwischenfälle teuer: Der Finanzsektor zählt mit im Schnitt rund 5,56 Mio. US-Dollar je Datenschutzverletzung zu den kostspieligsten Branchen (IBM Cost of a Data Breach 2025).
Ein verbreiteter Irrtum lautet, Maßnahmen der Aufsicht setzten erst nach einem Sicherheitsvorfall ein. Tatsächlich können bereits ein fehlendes oder unzureichendes IKT-Risikomanagement, ein unvollständiges Informationsregister oder verspätete Meldungen aufsichtliche Konsequenzen nach sich ziehen (Verordnung (EU) 2022/2554). Die Vorsorge beginnt also mit nachweisbarer, laufender Sorgfalt — nicht erst im Ernstfall. Wer parallel die Schwachstellen-Meldepflicht des Cyber Resilience Act im Blick hat, kann verwandte Nachweispflichten auf derselben Überwachungsbasis bedienen.
Dieser Artikel stützt sich auf: Verordnung (EU) 2022/2554 (Digital Operational Resilience Act, DORA) inklusive der technischen Standards der Europäischen Aufsichtsbehörden (ESAs — EBA, ESMA, EIOPA) zur Meldung schwerwiegender IKT-Vorfälle und zum Informationsregister; Europäische Bankenaufsichtsbehörde (EBA), Preparation for DORA application und FAQ zum Register of Information sowie Dry-Run-Auswertung 2024/2025; ESAs, Pressemitteilung zur Designierung kritischer IKT-Drittdienstleister vom 18. November 2025 (EBA/ESMA/EIOPA); Europäische Zentralbank (EZB), Cyber Resilience Stress Test 2024; ENISA, Threat Landscape Finance Sector 2024; IBM, Cost of a Data Breach Report 2025; PwC, Analysen zum Anwendungsbereich von DORA. Dieser Beitrag ist eine allgemeine Information und ersetzt keine Rechtsberatung.