DORA-Compliance im Jahr 2026: Vollständiger Leitfaden für EU-Finanzunternehmen

DORA im Jahr 2026: ein Jahr Anwendung, was sich änderte

Vor einem Jahr, am 17. Januar 2025, trat der Digital Operational Resilience Act in Kraft. Als Verordnung und nicht als Richtlinie galt DORA vom ersten Tag an unmittelbar in allen 27 EU-Mitgliedstaaten — keine Umsetzung nötig, keine nationalen Abweichungen bei den Kernpflichten. Bis Mai 2026 ist der Rahmen über die Umsetzungsphase hinaus in die aktive Durchsetzungsphase übergegangen. Die zuständigen nationalen Behörden — BaFin in Deutschland, ACPR in Frankreich, CSSF in Luxemburg, MNB in Ungarn, ČNB in Tschechien und ihre Entsprechungen in der gesamten Union — sind von der Herausgabe von Leitlinien zur Durchführung von Inspektionen übergegangen.

Der Übergang verlief nicht reibungslos. Die Probeübung der Europäischen Aufsichtsbehörden von 2024 zum Informationsregister ergab, dass nur 6,5 % von fast 1.000 Unternehmen in der gesamten EU alle 116 Datenqualitätsprüfungen erfolgreich bestanden. Der Zyklus 2025 zeigte Verbesserungen, offenbarte aber weiterhin erhebliche Compliance-Lücken bei der Dokumentation von Drittparteirisiken, den Verfahren zur Vorfalleinstufung und den Tests der operativen Resilienz. Der Zyklus 2026 mit Stichtag 31. Dezember 2025 ist der erste, der vollständig unter einer Durchsetzungshaltung bewertet wird.

Zwei Entwicklungen Ende 2025 und Anfang 2026 haben die Regulierungslandschaft herauskristallisiert. Erstens veröffentlichten die Europäischen Aufsichtsbehörden am 18. November 2025 die erste offizielle Liste von 19 benannten kritischen IKT-Drittdienstleistern nach DORA — darunter AWS, Microsoft Azure, Google Cloud, IBM, Bloomberg, die London Stock Exchange Group, Tata Consultancy Services und Orange. Diese Benennungen bringen namentlich genannte globale Anbieter unter direkte EU-Aufsicht, wobei nun gemeinsame Prüfteams aktiv sind.

Zweitens hat die Überprüfung der Kommission nach Artikel 58, fällig bis zum 17. Januar 2026, untersucht, ob die DORA-Anforderungen für Abschlussprüfer und Prüfungsgesellschaften verschärft werden sollten — derzeit im Anwendungsbereich, aber mit begrenzten Pflichten. Die Überprüfung öffnet die Tür für schrittweise Anpassungen des Anwendungsbereichs im weiteren Verlauf des Jahrzehnts. Vorerst arbeiten die erfassten Unternehmen unter dem ursprünglichen Rahmen, und der praktische Test ist, ob sie innerhalb der Vier-Stunden-Uhr belastbare Beweise vorlegen können, wenn ein Vorfall eintritt.

Für Organisationen, die DORA unterliegen, konzentriert sich dieser Leitfaden auf den betrieblichen Test statt auf den Gesetzestext. Die dreistufige Meldekaskade des Artikels 19 ist die folgenreichste Einzelpflicht der Verordnung, und das Zeitfenster von vier Stunden für die Erstmeldung ist deutlich enger als die 24-Stunden-Frühwarnung von NIS2. Der Rest der Verordnung — Drittparteirisiko, operative Tests, Sanktionen — kreist um diesen zentralen Punkt: Kann Ihre Organisation, wenn etwas schiefgeht, mit der Geschwindigkeit und Integrität dokumentieren, was geschehen ist, die die Regulierungsbehörde nun erwartet?

Anwendungsbereich: wer unter DORA fällt

Der Anwendungsbereich von DORA ist positiv und breit definiert. Anders als NIS2, das Sektorkritikalität plus eine Größenobergrenze verwendet, gilt DORA für praktisch jedes regulierte Finanzunternehmen in der Europäischen Union — für die meisten Kategorien ohne Mindestgrößenschwelle. Die Europäische Bankenaufsichtsbehörde schätzt, dass rund 22.000 Finanzunternehmen in der gesamten Union in den Anwendungsbereich von DORA fallen.

Erfasste Finanzunternehmen (nicht erschöpfende Liste)

Zu den Kategorien zählen Kreditinstitute, Zahlungsinstitute und E-Geld-Institute, Wertpapierfirmen, Anbieter von Krypto-Dienstleistungen, Zentralverwahrer, zentrale Gegenparteien, Handelsplätze, Transaktionsregister, Verwalter alternativer Investmentfonds, Verwaltungsgesellschaften von OGAW, Datenbereitstellungsdienste, Versicherungs- und Rückversicherungsunternehmen, Versicherungsvermittler, Einrichtungen der betrieblichen Altersversorgung, Ratingagenturen, Abschlussprüfer und Prüfungsgesellschaften, Administratoren kritischer Referenzwerte, Schwarmfinanzierungsdienstleister und Verbriefungsregister. Nahezu jede im EU-Finanzdienstleistungsrecht spezifisch definierte Kategorie ist erfasst.

Keine allgemeine Ausnahme über eine Größenobergrenze

Dies ist ein grundlegender Unterschied zu NIS2. Wo NIS2 Einrichtungen unter 50 Beschäftigten und 10 Mio. EUR Umsatz standardmäßig ausnimmt, gilt DORA grundsätzlich unabhängig von der Größe. Kleinere Finanzunternehmen — kleine Zahlungsinstitute, kleinere Wertpapierfirmen, kleinere Anbieter von Krypto-Dienstleistungen — fallen neben den größten Banken in den Anwendungsbereich. DORA enthält einen Verhältnismäßigkeitsgrundsatz: Die Verordnung verlangt ausdrücklich, dass die Pflichten für bestimmte Kleinstunternehmen und kleinere Institute in vereinfachter Weise anzuwenden sind, doch die materiellen Pflichten gelten.

IKT-Drittdienstleister als eigene Kategorie

IKT-Drittdienstleister, die Finanzunternehmen bedienen, werden anders behandelt. Sie sind keine unmittelbaren Adressaten der Risikomanagement- oder Meldepflichten von DORA. Stattdessen werden sie mittelbar über die vertraglichen Anforderungen des Kapitels V erreicht, die den Finanzunternehmen auferlegt werden, und unmittelbar — für die größten Anbieter — über den Aufsichtsrahmen für kritische IKT-Drittdienstleister (CTPPs). Die im November 2025 benannten 19 CTPPs unterliegen nun der direkten EU-Aufsicht durch gemeinsame Prüfteams und zahlen eine Aufsichtsgebühr.

Geografische Reichweite und extraterritoriale Wirkung

DORA gilt für in der Union niedergelassene Finanzunternehmen. IKT-Drittdienstleister, die außerhalb der Union niedergelassen sind, aber erfasste EU-Finanzunternehmen bedienen, werden vertraglich über die Anforderungen des Kapitels V erreicht — das Finanzunternehmen muss dem Dritten DORA-konforme Bedingungen auferlegen, unabhängig davon, wo der Dritte niedergelassen ist. Dies hat DORA-äquivalente Pflichten faktisch in die Standardvertragsbedingungen großer globaler Cloud-Anbieter, Softwarelieferanten und Outsourcing-Partner gedrückt, selbst wenn diese Anbieter ihren Sitz in den Vereinigten Staaten oder anderswo außerhalb der EU haben.

Die fünf Säulen von DORA im Überblick

DORA wird üblicherweise als auf fünf Säulen ruhend beschrieben, die seinen wichtigsten materiellen Kapiteln entsprechen. Das Verständnis der fünf Säulen und ihres Zusammenspiels bildet den Rahmen für den Rest dieses Leitfadens.

Säule 1: IKT-Risikomanagement (Artikel 5–16)

Finanzunternehmen müssen einen umfassenden Rahmen für das IKT-Risikomanagement umsetzen, wobei die Verantwortung auf Ebene des Leitungsorgans liegt. Der Rahmen muss Identifizierung, Schutz, Erkennung, Reaktion, Wiederherstellung und kontinuierliches Lernen abdecken. Artikel 6 führt die Komponenten auf: Governance-Regelungen, IKT-Geschäftsfortführungsleitlinie, Reaktions- und Wiederherstellungsverfahren sowie Lern- und Weiterentwicklungsmechanismen. Der Rahmen muss mindestens jährlich überprüft und nach schwerwiegenden IKT-bezogenen Vorfällen aktualisiert werden.

Säule 2: Management, Einstufung und Meldung IKT-bezogener Vorfälle (Artikel 17–23)

Die Artikel 17 bis 23 legen fest, wie Finanzunternehmen IKT-bezogene Vorfälle erkennen, einstufen, verwalten und melden müssen. Die Meldepflichten nach Artikel 19 — und die enge dreistufige Frist, die sie auferlegen — sind die operativ anspruchsvollste Komponente von DORA für Vorfallreaktionsteams. Diese Säule steht im Mittelpunkt großer Teile dieses Leitfadens.

Säule 3: Test der digitalen operativen Resilienz (Artikel 24–27)

Finanzunternehmen müssen ihre digitale operative Resilienz regelmäßig testen, wobei das Testprogramm im Verhältnis zu Größe und Risiko steht. Artikel 25 legt grundlegende Testanforderungen fest, die für alle erfassten Unternehmen gelten; Artikel 26 führt bedrohungsgeleitete Penetrationstests für bedeutende Finanzunternehmen ein, die auf dem TIBER-EU-Rahmen beruhen und mindestens alle drei Jahre auf Live-Produktivsystemen durchgeführt werden.

Säule 4: Management des IKT-Drittparteirisikos (Artikel 28–44)

Kapitel V befasst sich mit dem Drittparteirisiko, das die Regulierungsbehörde als den wichtigsten Vektor für systemische Störungen in modernen Finanzdienstleistungen betrachtet. Das Kapitel umfasst Pflichten zu Vertragsbedingungen, Lieferanten-Due-Diligence, dem Informationsregister, Kontrollen der Unterauftragsvergabe und — am markantesten — den Aufsichtsrahmen für kritische IKT-Drittdienstleister. Hier liegen die neuartigsten strukturellen Innovationen der Verordnung.

Säule 5: Vereinbarungen zum Informationsaustausch (Artikel 45)

Artikel 45 ermutigt Finanzunternehmen zur Teilnahme an Vereinbarungen zum Austausch von Informationen und Erkenntnissen über Cyberbedrohungen. Die Teilnahme ist freiwillig, doch die Verordnung schafft einen erlaubenden rechtlichen Rahmen — einschließlich der wichtigen Klarstellung, dass der Informationsaustausch innerhalb der Parameter des Rahmens keinen Verstoß gegen Vertraulichkeits- oder Datenschutzpflichten darstellt. Die Säule ist operativ leichter als die anderen, aber rechtlich ermöglichend.

Rahmen für das IKT-Risikomanagement (Artikel 5–16)

Kapitel II von DORA, das die Artikel 5 bis 16 umfasst, legt den Rahmen für das IKT-Risikomanagement fest, den jedes erfasste Finanzunternehmen umsetzen und aufrechterhalten muss. Der Rahmen ist das Fundament, auf dem die Säulen Vorfallreaktion, Tests und Drittparteirisiko ruhen. Wo der Rahmen schwach ist, können die abhängigen Pflichten während einer Inspektion nicht glaubwürdig erfüllt werden.

Verantwortung des Leitungsorgans (Artikel 5)

Artikel 5 legt die letztendliche Verantwortung für den Rahmen des IKT-Risikomanagements auf das Leitungsorgan — Vorstand oder gleichwertiges Gremium. Das Leitungsorgan muss den Rahmen festlegen und genehmigen, seine Umsetzung überwachen und ausreichende Budget- und Personalressourcen sicherstellen. Mitglieder des Leitungsorgans müssen ausreichende Kenntnisse und Fähigkeiten aufrechterhalten, um IKT-Risiken zu verstehen und zu beurteilen; dies ist eine materielle, keine formale Pflicht, und die Regulierungsbehörde kann Nachweise für Schulungen auf Vorstandsebene und aktives Engagement verlangen.

Umfassender Rahmen für das IKT-Risikomanagement (Artikel 6)

Artikel 6 legt die Komponenten fest: ein dokumentierter, vom Leitungsorgan genehmigter Rahmen, organisatorische Regelungen mit klaren Rollen und Verantwortlichkeiten, Geschäftsfortführungsleitlinie, Reaktions- und Wiederherstellungsverfahren, Lernmechanismen und der Schutz von IKT-Ressourcen über ihren gesamten Lebenszyklus. Der Rahmen muss im Verhältnis zu Größe, Art, Komplexität und Risikoprofil des Unternehmens stehen — doch die materiellen Elemente sind verpflichtend. Die Verhältnismäßigkeit betrifft die Intensität, nicht die Abdeckung.

Identifizierung, Schutz, Erkennung, Reaktion, Wiederherstellung (Artikel 7–13)

Die Artikel 7 bis 13 führen die funktionalen Fähigkeiten aus. Die Identifizierung umfasst IKT-Systeme, die Klassifizierung von Informationswerten und die Identifizierung IKT-gestützter Geschäftsfunktionen. Der Schutz umfasst Sicherheitsrichtlinien, Identitäts- und Zugriffsmanagement, Verschlüsselung und Betriebssicherheit. Die Erkennung umfasst Überwachung, Anomalieerkennung und Alarmierung. Reaktion und Wiederherstellung umfassen Geschäftsfortführung, Reaktionsverfahren und Krisenkommunikation. Das Lernen umfasst Überprüfungen nach Vorfällen, Ursachenanalysen und kontinuierliche Verbesserung.

Krisenkommunikationsplan (Artikel 14)

Artikel 14 verlangt von Unternehmen einen Krisenkommunikationsplan, der internes Personal, Kunden, Finanzpartner, die Öffentlichkeit und die Aufsichtsbehörden abdeckt. Der Plan muss regeln, wie die Kommunikation koordiniert wird, wenn ein Vorfall mehrere Interessengruppen betrifft — wofür forensische Beweise unverzichtbar werden, sowohl als Input für die Kommunikation als auch als defensive Aufzeichnung, falls die Kommunikation später von Kunden, Gegenparteien oder Regulierungsbehörden infrage gestellt wird.

Jährliche Überprüfung (Artikel 6 Absatz 5)

Der Rahmen muss mindestens jährlich überprüft und aktualisiert werden, wann immer schwerwiegende IKT-bezogene Vorfälle auftreten, aufsichtsrechtliche Anweisungen ergehen oder wesentliche Änderungen an der IKT-Umgebung des Unternehmens stattfinden. Die jährliche Überprüfung ist selbst dokumentiert und nachweisbar; sie ist Teil der Prüfspur, die Aufsichtsbehörden bei Inspektionen untersuchen, und Lücken in der Überprüfungshistorie sind in der frühen Durchsetzungsphase zu einem wiederkehrenden Punkt der aufsichtsrechtlichen Rückmeldung geworden.

Artikel 19: die dreistufige Meldefrist

Artikel 19 ist das operative Herzstück von DORA für die Vorfallreaktion. Er legt eine dreistufige Meldekaskade fest, die ausgelöst wird, wenn ein IKT-bezogener Vorfall als schwerwiegend eingestuft wird — und die Fristen sind merklich enger als die entsprechenden Pflichten von NIS2. Die detaillierten Fristen und Inhaltsanforderungen sind in der Delegierten Verordnung (EU) 2025/301 vom 23. Oktober 2024 festgelegt, mit Vorlagen und Verfahren nach der Durchführungsverordnung (EU) 2025/302.

Stufe 1 — Erstmeldung: 4 Stunden ab Einstufung, max. 24 Stunden ab Erkennung

Die Erstmeldung muss die zuständige Behörde binnen 4 Stunden ab dem Moment erreichen, in dem das Finanzunternehmen den Vorfall als schwerwiegend einstuft. Die Einstufung selbst muss so bald wie nach vernünftigem Ermessen praktikabel nach der Erkennung erfolgen, in jedem Fall aber binnen 24 Stunden ab Erkennung. Die kombinierte Wirkung: Von der Erkennung bis zur Erstmeldung beträgt die maximal zulässige verstrichene Zeit 28 Stunden — doch in der Praxis erwarten die Regulierungsbehörden, dass sich die Kette auf Stunden statt Tage verdichtet. Das Zurückhalten der Meldung, weil die Untersuchung unvollständig ist, ist ausdrücklich nicht konform; die Erstmeldung soll frühzeitige Kenntnis verschaffen, keine vollständige Analyse.

Stufe 2 — Zwischenmeldung: 72 Stunden ab Erstmeldung

Binnen 72 Stunden ab der Erstmeldung muss das Finanzunternehmen eine Zwischenmeldung mit einer inhaltlich reicheren Beschreibung des Vorfalls einreichen, einschließlich aktuellem Status, verfeinerter Einstufung, Folgenabschätzung und etwaigen weiteren von der zuständigen Behörde angeforderten Informationen. Wo der Vorfall aktiv bleibt oder die Ursachenanalyse unvollständig ist, erkennt die Zwischenmeldung dies ausdrücklich an und skizziert die nächsten Schritte. Die 72 Stunden laufen ab der Erstmeldung, nicht ab der Erkennung — eine entscheidende Unterscheidung gegenüber der DSGVO.

Stufe 3 — Abschlussmeldung: spätestens einen Monat nach der Zwischenmeldung

Spätestens einen Monat nach der Zwischenmeldung reicht das Finanzunternehmen die Abschlussmeldung ein. Diese enthält eine umfassende Beschreibung des Vorfalls, seiner Ursache, der technischen und operativen Details, der Auswirkungen (einschließlich finanzieller Verluste und Zahl der betroffenen Kunden), der ergriffenen Abhilfemaßnahmen, der gewonnenen Erkenntnisse und der geplanten Verbesserungen. Die Abschlussmeldung ist das Dokument, auf das Aufsichtsbehörden bei späteren Inspektionen und Prüfungen zurückkommen — ihre Qualität bestimmt, wie der Vorfall in der Regulierungsakte in Erinnerung bleibt.

Freiwillige Meldung erheblicher Cyberbedrohungen (Artikel 19 Absatz 2)

Artikel 19 Absatz 2 erlaubt — verlangt aber nicht — dass Finanzunternehmen erhebliche Cyberbedrohungen freiwillig melden. Das freiwillige Melderegime erlaubt es Unternehmen, Bedrohungserkenntnisse auch dann zu teilen, wenn kein Vorfall eingetreten ist, und hilft dem breiteren Finanzsektor bei der Vorbereitung. Die Mitgliedstaaten können die Weiterleitung freiwilliger Meldungen auch auf NIS2-CSIRTs erstrecken. Obwohl freiwillig, sind diese Meldungen Teil der Einschätzung der Regulierungsbehörde zur IKT-Risikoreife und Engagementhaltung des Unternehmens.

Pflicht zur Kundenbenachrichtigung (Artikel 19 Absatz 3)

Wenn ein schwerwiegender IKT-bezogener Vorfall die finanziellen Interessen von Kunden beeinträchtigt, muss das Finanzunternehmen die Kunden — unverzüglich, sobald es davon Kenntnis erhält — über den Vorfall und die zur Minderung nachteiliger Auswirkungen ergriffenen Maßnahmen unterrichten. Kundenbenachrichtigungen sind Teil der öffentlichen Beweisakte; einmal veröffentlicht, begrenzen sie, wie das Unternehmen den Vorfall später in aufsichtsrechtlichen Eingaben oder in einem Rechtsstreit charakterisieren kann. Die forensische Erfassung der Kundenbenachrichtigungen selbst — einschließlich der veröffentlichten Version, des Zeitstempels und etwaiger späterer Aktualisierungen — wird Teil der defensiven Aufzeichnung.

Einstufung schwerwiegender Vorfälle: die sieben Kriterien

Nur schwerwiegende IKT-bezogene Vorfälle lösen die Meldepflichten des Artikels 19 aus. Die Schwelle wird durch die Delegierte Verordnung (EU) 2024/1772 definiert, die sieben Einstufungskriterien und die Wesentlichkeitsschwellen für jedes festlegt. Die Kriterien präzise zu verstehen ist unerlässlich — eine falsche Einstufung ist selbst ein Compliance-Verstoß, und Übermeldung wird nicht sanktioniert, während Untermeldung unmittelbare verwaltungsrechtliche Folgen hat.

Die sieben Einstufungskriterien

Die sieben Kriterien sind: Kritikalität der betroffenen Dienste; Zahl und Bedeutung der betroffenen Kunden, Finanzpartner und Transaktionen; Reputationsschaden; Dauer und Ausfallzeit der Dienste; geografische Ausbreitung; Datenverluste; und wirtschaftliche Auswirkungen. Jedes Kriterium hat seine eigene Wesentlichkeitsschwelle, und die Einstufungslogik kombiniert sie über eine Doppelauslöserstruktur, statt ein einzelnes Kriterium als entscheidend zu behandeln.

Der Doppelauslöser: kritische Dienste + Datenverlust ODER zwei Schwellen

Ein IKT-bezogener Vorfall wird als schwerwiegend eingestuft, wenn kritische oder wichtige Dienste beeinträchtigt wurden und entweder die Wesentlichkeitsschwelle für Datenverluste erreicht ist — also jeder erfolgreiche, böswillige und unbefugte Zugriff auf Netz- und Informationssysteme, der zu Datenverlust führt — oder mindestens zwei der anderen Wesentlichkeitsschwellen überschritten wurden. Die Doppelauslöserlogik stellt sicher, dass schwere Ein-Kriterien-Vorfälle (insbesondere Datenverluste) ebenso erfasst werden wie vielschichtige Störungen, die einzeln möglicherweise keine einzelne Obergrenze überschreiten.

Quantitative Wesentlichkeitsschwellen

Mehrere Schwellen sind quantitativ. Die Zahl der betroffenen Finanzpartner muss 30 % aller den betroffenen Dienst nutzenden Finanzpartner übersteigen. Die Zahl der betroffenen Transaktionen muss 10 % der täglichen Durchschnittszahl oder 10 % des täglichen Durchschnittswerts der dienstbezogenen Transaktionen übersteigen. Andere Schwellen sind qualitativ, einschließlich des Reputationsschadens, der anhand von Faktoren wie Berichterstattung in reichweitenstarken Medien, Eskalation der aufsichtsrechtlichen Prüfung und wesentlichem Kundenabwanderungsrisiko beurteilt wird.

Erfolgreicher böswilliger unbefugter Zugriff als automatischer Auslöser

Wie bei der Durchführungsverordnung (EU) 2024/2690 der Kommission zu NIS2 behandeln die Einstufungsregeln von DORA erfolgreichen böswilligen unbefugten Zugriff als automatischen Erheblichkeitsindikator. Wo ein Angreifer mit erkennbar böswilliger Absicht Zugriff auf Netz- und Informationssysteme erlangt hat und der Zugriff zu Datenverlust geführt hat oder führen kann, ist der Vorfall unabhängig von den anderen Schwellen schwerwiegend. Dies beseitigt die Debatte während der ersten Stunden der Reaktion: Wenn ein Eindringling bestätigt ist und der Zugriff verdächtig ist, beginnt die Vier-Stunden-Uhr.

Wiederkehrende Vorfälle und Gesamtbeurteilung

Eine Reihe kleinerer Vorfälle kann gemeinsam die Schwelle für schwerwiegende Vorfälle erreichen, auch wenn kein einzelnes Ereignis dies täte. Die Einstufungsverordnung verlangt von Unternehmen, wiederkehrende Vorfälle in ihrer Gesamtheit zu beurteilen, insbesondere wo dieselbe Ursache mehrere unterschiedliche Ereignisse hervorruft. Die Verbindung zwischen Vorfällen zu dokumentieren ist selbst eine Beweisherausforderung — sie erfordert konsistente Protokollaufbewahrung, forensische Erfassung wiederkehrender webseitiger Angriffsartefakte und eine dokumentierte analytische Kette, die die Ereignisse über möglicherweise Wochen oder Monate verbindet.

Warum Beweissicherung gleich DORA-Compliance ist

Das Zeitfenster von vier Stunden für die Erstmeldung von DORA verändert die operative Rechnung für die Vorfallreaktion in einer Weise, die wenige DORA-regulierte Unternehmen im ersten Jahr vollständig verinnerlicht haben. Wo die 24-Stunden-Frühwarnung von NIS2 etwas Zeit zur Triage erlaubt, erwartet DORA, dass die Erstmeldung mit den verfügbaren Informationen eingereicht wird — und später in der Zwischen- und Abschlussmeldung verfeinert wird. Das bedeutet, dass die Beweise, die die spätere Abschlussmeldung stützen, während der ersten Stunden des Vorfalls erfasst werden müssen, wenn die Teams gleichzeitig den Angriff eindämmen, Dienste wiederherstellen und Behörden benachrichtigen. Das Fenster zum Aufbau von Fähigkeiten schließt sich in dem Moment, in dem die Erkennung erfolgt.

Die Delegierte Verordnung (EU) 2025/301, die den Inhalt der Erst- und Folgemeldungen festlegt, verlangt, dass die Erstmeldung — soweit verfügbar — Informationen darüber enthält, ob der Vorfall böswillige Aktivität umfasst, die unmittelbaren Auswirkungen auf die Dienste, die geografische Ausbreitung und die betroffenen Finanzpartner. Bis zur Zwischenmeldung müssen diese Inhalte verfeinert und erweitert werden. Bis zur Abschlussmeldung müssen Ursachenanalyse, technische Details des Angriffs und gewonnene Erkenntnisse alle dokumentiert sein. Nichts davon ist ohne forensische Beweise erreichbar, die vom Moment der Erkennung an gesichert sind.

Die operativ anfälligste Beweiskategorie für Finanzunternehmen ist webseitige Angriffsinfrastruktur. Phishing-Seiten, die Retail-Banking-Oberflächen imitieren, gefälschte Zahlungsautorisierungsportale, betrügerische KYC-Dokumenteneinreichungsseiten, ähnlich aussehende Anlageplattformen und Markenimitationskampagnen in sozialen Medien sind alle darauf ausgelegt, Finanzzugangsdaten, Zahlungsdaten oder Onboarding-Dokumentation abzugreifen. Jede davon wird auf einer Infrastruktur gehostet, die das Finanzunternehmen nicht kontrolliert. Hosting-Anbieter nehmen Phishing-Seiten binnen Stunden nach der Meldung offline. Angreifer geben entdeckte Infrastruktur auf. Bis die Zwischenmeldung 72 Stunden später fällig ist, ist der Beweis verschwunden, sofern er nicht während der ersten Stunden erfasst wurde.

Dies ist die operative Lücke, die forensische Web-Beweisplattformen wie GetProofAnchor schließen sollen. Eine im Moment der Vorfallerkennung vorgenommene Erfassung erzeugt ein manipulationssicheres Paket — vollständiges HTML, gerenderter Screenshot, extrahierter Inhalt, Netzwerk-Metadaten und gegebenenfalls die TLS-Zertifikatskette — verbunden durch einen qualifizierten elektronischen Zeitstempel nach eIDAS Artikel 42 und unabhängig in der Bitcoin-Blockchain über OpenTimestamps verankert. Wenn die zuständige nationale Behörde zwei Wochen später einen Nachweis dafür verlangt, dass die Phishing-Seite existierte und gegen die Kunden der Bank betrieben wurde, steht der Beweis mit mathematischer Integrität statt rekonstruierter Erinnerung zur Verfügung.

Der Punkt ist nicht, dass jedes DORA-Unternehmen ein bestimmtes Werkzeug übernehmen muss. Der Punkt ist, dass die Beweissicherung während der ersten Stunden eines Vorfalls eine erstrangige Compliance-Pflicht unter DORA ist — und dass Finanzunternehmen, die diese Fähigkeit nicht aufgebaut haben, bevor ein Vorfall eintritt, während der Vier-Stunden-Uhr feststellen werden, dass das Fehlen gesicherter Beweise selbst zu einem meldepflichtigen Versagen wird. Die Zwischenmeldung ist 72 Stunden nach der Erstmeldung fällig. Die Abschlussmeldung ist einen Monat später fällig. Die Beweise, die beide stützen, müssen intakt sein, und sie müssen gegenüber einer Aufsichtsbehörde belastbar sein.

Forensische Erfassung von IKT-Vorfallsbeweisen im Finanzsektor

IKT-Vorfälle im Finanzsektor hinterlassen ihre primäre forensische Spur in charakteristischen Mustern. Die spezifischen Beweiskategorien zu verstehen, die bei schwerwiegenden DORA-Vorfällen wiederkehren – und wie man sie so erfasst, dass sie den Erwartungen der zuständigen Behörde genügen –, gehört zu den wirkungsvollsten operativen Fähigkeiten, die ein Finanzunternehmen 2026 aufbauen kann. Die folgenden fünf Kategorien decken den Großteil der web-basierten forensischen Beweise bei DORA-Vorfällen ab.

Phishing-Seiten, die Online-Banking-Oberflächen imitieren

Phishing-Seiten im Privatkundengeschäft sind der häufigste einzelne Angriffsvektor gegen Bankkunden und zugleich die beweisrechtlich fragilsten. Ein Phishing-Betreiber stellt die Seite auf einer täuschend ähnlichen Domain bereit, betreibt die Kampagne über Stunden oder Tage und gibt die Infrastruktur auf oder verlagert sie, sobald die Seite gemeldet wird. Die forensische Erfassung muss das vollständige HTML, die visuelle Darstellung über Desktop- und Mobil-Viewports, die TLS-Kette mit dem Zertifikat der nachgeahmten Domain (häufig ein kostenloses Let's-Encrypt-Zertifikat, was für sich genommen beweisrelevant ist) und die Netzwerkaufzeichnungen des Endpunkts zur Ausleitung der Zugangsdaten umfassen. Die Aufsichtsbehörde wird das zugrunde liegende DOM und die Netzwerkidentität der bösartigen Infrastruktur verlangen, nicht einen Screenshot.

Gefälschte Zahlungsautorisierungs- und Bestätigungsseiten

Eine ausgefeiltere Variante fängt den Zahlungsauthentifizierungsablauf ab – typischerweise, indem während einer scheinbar legitimen Transaktion eine gefälschte 3-D-Secure- oder PSD2-Seite zur starken Kundenauthentifizierung präsentiert wird. Diese Seiten existieren, um Einmalpasswörter zusammen mit den primären Zugangsdaten abzugreifen. Der Beweiswert liegt darin, die präzise visuelle Nachahmung, die Netzwerkaufrufe zur Erfassung des OTP und die Weiterleitungslogik zu belegen. Die Erfassung muss während des laufenden Betriebs der Kampagne erfolgen; nachdem die Seite abgeschaltet ist, besteht die forensische Spur ausschließlich aus dem, was zum jeweiligen Zeitpunkt erfasst wurde, und die Verteidigungsposition der Bank hängt von der Qualität dieser Erfassung ab.

Markenimitierende Investmentplattformen und Krypto-Börsen

Ein wachsender Anteil DORA-relevanter Vorfälle in den Jahren 2025 und 2026 betraf gefälschte Investmentplattformen und nachgeahmte Oberflächen von Krypto-Dienstleistern. Diese kombinieren typischerweise Domain-Imitation mit umfangreicher mehrseitiger Nachahmung – gefälschte Konto-Dashboards, gefälschte Transaktionshistorien, gefälschte Einzahlungsoberflächen. Die forensische Erfassung muss den vollständigen Nutzerpfad der Imitation durchlaufen und idealerweise jede Seite der Angreiferoberfläche zusammen mit dem Netzwerkzustand zum Erfassungszeitpunkt festhalten. Das resultierende Beweispaket unterstützt sowohl die DORA-Meldung als auch die anschließende Zusammenarbeit mit Strafverfolgungsbehörden nach nationalem Strafverfahrensrecht.

Gefälschte KYC- und Onboarding-Portale zur Dokumentübermittlung

Manche Angriffskampagnen zielen auf das Kunden-Onboarding statt auf aktive Konten ab. Gefälschte KYC-Portale sammeln Ausweisdokumente – Reisepässe, Führerscheine, Adressnachweise –, die dann weiterverkauft oder für nachfolgenden Betrug verwendet werden. Aus Sicht des Finanzunternehmens sind Beweise dieser Kampagnen sowohl für die DORA-Vorfallsmeldung als auch für Meldungen von Verletzungen des Schutzes personenbezogener Daten nach Artikel 33 DSGVO relevant. Eine einzige forensische Erfassung unterstützt beide regulatorischen Spuren, sofern sie mit den Integritätsprimitiven aufgebaut ist, die beide Aufsichtsbehörden erwarten.

Beweise zu Ausfällen und Vorfällen kritischer IKT-Drittdienstleister

Wenn ein benannter kritischer IKT-Drittdienstleister einen Ausfall erleidet, der die Dienstleistungen eines Finanzunternehmens beeinträchtigt, muss das Finanzunternehmen Beweise über den Zustand des Drittdienstleisters zum Zeitpunkt des Vorfalls erfassen. Dies ist beweisrechtlich echtes Neuland unter DORA – das Unternehmen muss etwas dokumentieren, das es nicht kontrolliert, auf einer Infrastruktur, die von einem kritischen Drittdienstleister unter direkter Aufsicht der ESAs betrieben wird. Die forensische Erfassung der Statusseite des Drittdienstleisters, der eigenen Telemetrie zur Dienstverschlechterung und etwaiger öffentlicher Erklärungen des Drittdienstleisters während des Vorfalls wird zur Grundlage der DORA-Vorfallsmeldung des Unternehmens und jedes späteren Regressanspruchs gegen den Drittdienstleister.

Management des IKT-Drittparteienrisikos (Kapitel V)

Kapitel V von DORA – die Artikel 28 bis 44 – befasst sich mit dem, was europäische Aufsichtsbehörden als den wichtigsten Vektor für systemische Störungen in modernen Finanzdienstleistungen ansehen: die Abhängigkeit von Finanzunternehmen von einer geringen Zahl großer IKT-Drittdienstleister. Das Kapitel ist das intern umstrittenste Element von DORA in den Branchenkonsultationen und das operativ anspruchsvollste für die betroffenen Unternehmen, insbesondere für jene, die im vergangenen Jahrzehnt wesentliche Teile ihres Technologie-Stacks ausgelagert haben.

Artikel 28 legt den allgemeinen Grundsatz fest: Finanzunternehmen bleiben in vollem Umfang für die Einhaltung all ihrer Pflichten nach DORA verantwortlich, unabhängig davon, in welchem Umfang sie sich auf IKT-Drittdienstleister stützen. Dieser Grundsatz der Nicht-Delegierbarkeit ist das Fundament des Drittparteienregimes – die Aufsichtsbehörde kann den Dritten nicht für die Versäumnisse des Unternehmens belangen, aber das Unternehmen kann sich der Verantwortung nicht entziehen, indem es auf den Dritten verweist. Die Vertragskette muss das Verhalten des Dritten durch spezifische, durchsetzbare Mechanismen in den Kontrollbereich des Unternehmens bringen.

Artikel 30 legt verpflichtende Vertragsbestimmungen für IKT-Dienstleistungen fest, die kritische oder wichtige Funktionen unterstützen. Die Verträge müssen – unter anderem – eine vollständige Beschreibung der Dienstleistungen, die Orte der Leistungserbringung und der Datenverarbeitung, Anforderungen an das Dienstleistungsniveau, Anforderungen an IKT-Sicherheit und -Resilienz, die Prüfungsrechte des Unternehmens, Kündigungsrechte einschließlich Ausstiegsstrategien, die Zusammenarbeit mit zuständigen Behörden sowie Vorfallsmeldepflichten des Dritten gegenüber dem Finanzunternehmen enthalten. Die Delegierte Verordnung (EU) 2025/532 der Kommission vom 24. März 2025 legt die Elemente fest, die Finanzunternehmen bestimmen und bewerten müssen, wenn sie IKT-Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen weiterverlagern.

Das Informationsregister – gefordert nach Artikel 28 Absatz 3 und in technischen Durchführungsstandards spezifiziert – ist das zentrale Verzeichnis, das Finanzunternehmen über alle ihre vertraglichen Vereinbarungen mit IKT-Drittdienstleistern, einschließlich Unterauftragnehmern, führen müssen. Der Meldezyklus 2026 umfasst Vereinbarungen mit dem Stichtag 31. Dezember 2025, wobei die nationalen Einreichungsfristen je nach Mitgliedstaat variieren. Die Testübung der ESAs von 2024 ergab, dass nur 6,5 % von fast 1.000 Unternehmen in der gesamten EU alle 116 Datenqualitätsprüfungen erfolgreich bestanden – was das Ausmaß der operativen Anpassung verdeutlicht, die selbst für die Dokumentationspflichten des Kapitels V noch erforderlich ist.

Kritische IKT-Drittdienstleister: die Benennungen vom November 2025

Am 18. November 2025 veröffentlichten die Europäischen Aufsichtsbehörden – EBA, EIOPA und ESMA – die erste offizielle Liste von 19 benannten kritischen IKT-Drittdienstleistern unter DORA. Die Benennung stellt diese Anbieter erstmals unter direkte EU-Aufsicht, getrennt von und zusätzlich zu jeglicher bereits geltenden sektoralen Regulierung. Zu den 19 benannten kritischen Drittdienstleistern gehören die dominierenden Hyperscale-Cloud-Anbieter (AWS, Microsoft Azure, Google Cloud), zentrale Anbieter von Finanzdaten und -plattformen (Bloomberg, die London Stock Exchange Group, IBM) sowie weitere große Dienstleister für den EU-Finanzsektor (Tata Consultancy Services, Orange).

Der Benennungsrahmen beruht auf Kriterien, die in Artikel 31 festgelegt und in delegierten Rechtsakten näher ausgeführt sind. Kritische Drittdienstleister werden auf Grundlage ihrer systemischen Bedeutung benannt – gemessen an Zahl und Bedeutung der auf sie angewiesenen betroffenen Finanzunternehmen, der Ersetzbarkeit ihrer Dienstleistungen und den Folgen ihres Ausfalls. Die Benennung löst eine direkte Aufsicht durch gemeinsame Prüfteams aus, die vom jeweils federführenden Überwacher koordiniert werden, eine vom Drittdienstleister zu entrichtende Aufsichtsgebühr sowie eine Reihe von Aufsichtsbefugnissen, darunter Untersuchung, Vor-Ort-Inspektion und verbindliche Empfehlungen.

Für Finanzunternehmen sind die praktischen Folgen der Benennung eines kritischen Drittdienstleisters erheblich. Die Abhängigkeit von einem benannten kritischen Drittdienstleister muss explizit im Informationsregister dokumentiert werden. Das Konzentrationsrisiko – das Risiko, dass das Finanzunternehmen übermäßig von einem kritischen Drittdienstleister oder einer kleinen Gruppe korreliert agierender Drittdienstleister abhängig ist – muss bewertet und gesteuert werden. Ausstiegsstrategien müssen glaubwürdig sein: Verträge müssen den Wechsel zu einem alternativen Anbieter in einem handhabbaren Zeitrahmen ermöglichen, selbst wenn faktisch keine vollständig gleichwertige Alternative existiert.

Die gemeinsamen Prüfteams haben ihre Aufsichtstätigkeit im ersten Quartal 2026 aufgenommen. Die kritischen Drittdienstleister selbst unterliegen nun erstmals einer direkten aufsichtlichen Befassung auf EU-Ebene, zusätzlich zu jeder bereits geltenden sektoralen Regulierung – häufig in den Vereinigten Staaten, wo die meisten der benannten Unternehmen ihren Hauptsitz haben. Das Zusammenspiel zwischen EU-Aufsicht und heimatstaatlicher Regulierung ist selbst ein sich entwickelndes Praxisfeld, das die Durchsetzungsrealität von DORA in den kommenden Jahren prägen wird.

Speziell für die Vorfallsreaktion schafft die Benennung kritischer Drittdienstleister eine neue beweisrechtliche Dimension. Wenn ein benannter kritischer Drittdienstleister einen Vorfall erleidet, der die Dienstleistungen eines Finanzunternehmens beeinträchtigt, muss die DORA-Meldung des Finanzunternehmens mit der eigenen Vorfallsreaktion des Drittdienstleisters, mit der Aufsichtsbefassung des gemeinsamen Prüfteams und mit etwaigen parallelen regulatorischen Anfragen abgestimmt werden. Die forensische Erfassung des externen Zustands des Drittdienstleisters während des Vorfalls – öffentliche Statusseiten, Vorfallskommunikation, teilweise Dienstnachweise – wird zu einem entscheidenden Bestandteil der Verteidigungsdokumentation des Finanzunternehmens, insbesondere wenn später Vertragsverhandlungen oder Ansprüche auf Dienstgutschriften entstehen.

Bedrohungsgeleitete Penetrationstests (Artikel 26) und TIBER-EU

Artikel 26 von DORA führt eine inhaltlich neue operative Testpflicht für bedeutende Finanzunternehmen ein: bedrohungsgeleitete Penetrationstests, kurz TLPT. Der Rahmen basiert auf TIBER-EU – dem von der Europäischen Zentralbank entwickelten Rahmen für bedrohungsinformiertes ethisches Red Teaming – und stellt gegenüber herkömmlichen Penetrationstests einen qualitativen Sprung in Umfang, Intensität und aufsichtlicher Befassung dar.

TLPT sind für Finanzunternehmen erforderlich, die von der zuständigen Behörde als bedeutend eingestuft werden. Die Liste ist nicht öffentlich, doch die Kriterien beruhen auf der systemischen Bedeutung des Unternehmens, seiner Rolle in kritischen Finanzmarktinfrastrukturen und seinem IKT-Risikoprofil. Einmal identifiziert, muss das Unternehmen mindestens alle drei Jahre eine TLPT-Übung durchführen. Die Tests werden an Live-Produktivsystemen durchgeführt – nicht in isolierten Testumgebungen –, erstrecken sich auf kritische oder wichtige Funktionen und folgen einer strukturierten Methodik einschließlich der Aufbereitung von Bedrohungsinformationen, der Durchführung durch das Red Team und der Behebung.

Der Testumfang muss mehrere kritische oder wichtige Funktionen abdecken und die Live-Produktion einschließen. Dies ist die operativ eingriffsintensivste Einzelpflicht unter DORA. Die zuständige Behörde ist durchgängig eingebunden, von der Umfangsdefinition über die Auswahl des Red Teams (das akkreditierte Tester umfassen muss) bis zur Ergebnisbewertung. Die zuständige Behörde kann zusätzliche Tests verlangen, wenn die anfängliche Übung eine unzureichende Abdeckung oder unbefriedigende Ergebnisse erbringt.

Die gegenseitige Anerkennung zwischen den Mitgliedstaaten ist ein zentrales Merkmal: Eine unter der Aufsicht der zuständigen Behörde eines Mitgliedstaats durchgeführte TLPT-Übung wird von anderen Mitgliedstaaten anerkannt, in denen das Finanzunternehmen tätig ist. Dies vermeidet doppelte Tests für grenzüberschreitend tätige Unternehmen und stellt zugleich sicher, dass jedes Unternehmen unter einem einzigen koordinierten Regime getestet wird. Die Umsetzung des Rahmens erfolgte schrittweise über 2025 und 2026, wobei der erste Zyklus von TLPT-Übungen nun in bedeutenden Finanzunternehmen angelaufen ist.

Aus Beweissicht erzeugt TLPT eine umfangreiche Dokumentationsspur – Bedrohungsanalysen, Red-Team-Pläne, Ausnutzungsbefunde, Behebungspläne und Berichte nach der Übung. Die Integrität dieser Dokumentation ist wichtig, weil TLPT-Befunde selbst zur Grundlage aufsichtlicher Maßnahmen werden können, wenn sich kritische oder wichtige Funktionen als unzureichend geschützt erweisen. Diese Nachweiskette mit derselben beweisrechtlichen Integrität zu führen, die für die Vorfallsmeldung erwartet wird, ist Teil des Aufbaus einer kohärenten DORA-Beweisarchitektur.

Sanktionen, persönliche Haftung und sektorübergreifende Zusammenarbeit

Das Sanktionsregime von DORA wirkt auf zwei Ebenen: verwaltungsrechtliche Sanktionen, die von den zuständigen nationalen Behörden gegen Finanzunternehmen verhängt werden, und die vom federführenden Überwacher gegen kritische IKT-Drittdienstleister im Rahmen der Aufsicht verhängten Zwangsgelder. Die Mitgliedstaaten können zudem strafrechtliche Sanktionen nach nationalem Recht vorsehen, wenn DORA-Verstöße Verletzungen des nationalen Strafrechts beinhalten (Artikel 52).

Artikel 50 verpflichtet die Mitgliedstaaten sicherzustellen, dass die zuständigen Behörden befugt sind, angemessene verwaltungsrechtliche Sanktionen und Abhilfemaßnahmen für Verstöße gegen DORA zu verhängen. Die konkreten quantitativen Obergrenzen bleiben der nationalen Umsetzung der begleitenden Richtlinie (EU) 2022/2556 überlassen, mit der Folge, dass die Höchstbußgelder unionsweit variieren. In der Praxis haben mehrere Mitgliedstaaten Höchstbeträge in der Größenordnung von 5–10 Millionen Euro oder 10 % des jährlichen Gesamtumsatzes umgesetzt, was der Höhe vergleichbarer Sanktionen des Finanzsektors für Governance-Versäumnisse entspricht.

Für kritische IKT-Drittdienstleister ermächtigt Artikel 35 den federführenden Überwacher, Zwangsgelder von bis zu 1 % des durchschnittlichen weltweiten Tagesumsatzes des Drittdienstleisters im vorangegangenen Geschäftsjahr zu verhängen. Der periodische Charakter ist bedeutsam: Das Zwangsgeld läuft täglich während des Zeitraums der Nichtkonformität auf und erzeugt anhaltenden Druck zur Behebung, statt ein festes Bußgeld als Kosten der Geschäftstätigkeit erscheinen zu lassen. Die ersten Anwendungen dieser Befugnis werden für 2026 und 2027 erwartet, wenn die Aufsichtsbefassungen der gemeinsamen Prüfteams reifen.

Die persönliche Haftung der Geschäftsleitung ist eher implizit als ausdrücklich ausgestaltet, wie sie es in Artikel 20 der NIS2-Richtlinie ist. DORA legt die Verantwortung für das IKT-Risikomanagement dem Leitungsorgan (Artikel 5) und der Geschäftsleitung im weiteren Sinne auf, mit der Folge, dass Versäumnisse in diesen Bereichen Erwägungen zu Eignung und Zuverlässigkeit nach der sektoralen Finanzregulierung – Bankenaufsicht, Versicherungsaufsicht, Wertpapieraufsicht – auslösen, die persönliche Sanktionen, Tätigkeitsverbote und Aberkennungen umfassen können. Der Mechanismus ist indirekt, aber die Folgen sind unmittelbar.

Artikel 47 begründet eine förmliche Zusammenarbeit zwischen den zuständigen DORA-Behörden und der NIS2-Architektur – den nach NIS2 benannten CSIRTs, dem EU-CSIRTs-Netzwerk und der ENISA. Die Zusammenarbeit wirkt in beide Richtungen: DORA-Behörden erhalten von NIS2-CSIRTs Informationen über Vorfälle, die möglicherweise Finanzunternehmen betreffen, und sie können nach DORA gemeldete Vorfälle an NIS2-CSIRTs weiterleiten, wenn die sektorübergreifenden Auswirkungen dies rechtfertigen. Für Finanzunternehmen bedeutet dies, dass ein einziger Vorfall regulatorische Befassung über DORA, NIS2 (über den CSIRT-Kooperationskanal), die DSGVO (wenn personenbezogene Daten betroffen sind) und die sektorale Finanzregulierung hinweg auslösen kann – wobei jede Aufsichtsbehörde denselben zugrunde liegenden Sachverhalt unabhängig bewertet.

DORA, NIS2 und DSGVO: lex specialis und überlappende Pflichten

DORA wirkt innerhalb eines regulatorischen Verbunds, der NIS2, die DSGVO, die CER-Richtlinie und die sektorspezifische Finanzaufsicht umfasst. Bei einem einzelnen bedeutenden IKT-bezogenen Vorfall kann ein Finanzunternehmen gleichzeitig Pflichten aus drei, vier oder fünf dieser Rahmenwerke unterliegen. Zu verstehen, wie sie ineinandergreifen, ist entscheidend, um sowohl Lücken als auch Doppelarbeit während einer ohnehin druckvollen Reaktionsphase zu vermeiden.

DORA ist für Finanzunternehmen lex specialis gegenüber NIS2. Artikel 4 der Richtlinie (EU) 2022/2555 (NIS2) nimmt Finanzunternehmen ausdrücklich von den Pflichten zum Risikomanagement und zur Vorfallsmeldung nach NIS2 aus und erkennt DORA als das anwendbare Rahmenwerk an. Die Ausnahme ist nicht absolut – die Mitgliedstaaten können Finanzunternehmen weiterhin als kritische Einrichtungen nach der CER-Richtlinie benennen, und der NIS2-CSIRT-Kooperationskanal gilt über Artikel 47 DORA –, doch die operativen Pflichten liegen bei DORA. Dies ist die sauberste rahmenübergreifende Beziehung im EU-Cybersicherheitsrecht.

Artikel 33 DSGVO hingegen gilt parallel ohne Verdrängung. Wenn ein schwerwiegender IKT-bezogener DORA-Vorfall eine Verletzung des Schutzes personenbezogener Daten beinhaltet – und die meisten Angriffe auf Finanzunternehmen tun dies –, läuft die 72-Stunden-Meldung an die zuständige Datenschutzbehörde parallel zur 4-Stunden-/72-Stunden-/1-Monats-Kaskade von DORA. Die Auslöser unterscheiden sich (DORA: operative Auswirkung; DSGVO: Risiko für die betroffenen Personen), sodass ein einziger Vorfall beide auslösen kann. Die Beweise zur Untermauerung beider müssen in einer Form aufbewahrbar sein, die den jeweils strengsten geltenden Anforderungen genügt – was typischerweise kryptografisches Hashing der Artefakte, qualifizierte elektronische Zeitstempel nach Artikel 42 eIDAS und unabhängige Überprüfbarkeit durch Dritte bedeutet.

Forensische Web-Beweisplattformen wie GetProofAnchor sind darauf ausgelegt, Beweispakete zu erzeugen, die alle drei Aufsichtsbehörden gleichzeitig zufriedenstellen. Das Beweis-ZIP – versiegelt mit einem qualifizierten eIDAS-Zeitstempel, ausgestellt über einen in der EU gelisteten qualifizierten Vertrauensdiensteanbieter, unabhängig über OpenTimestamps in der Bitcoin-Blockchain verankert und mit einem quelloffenen Prüftool geliefert – funktioniert gleichermaßen für die zuständige DORA-Behörde, das NIS2-CSIRT (wenn der Kooperationskanal in Anspruch genommen wird) und die Datenschutzbehörde. Eine einzige Erfassung zum Zeitpunkt der Vorfallserkennung bedient alle nachfolgenden Meldepflichten ohne weiteren Aufwand.

Über diese drei Aufsichtsbehörden hinaus sollten Finanzunternehmen auch sektorale Wechselwirkungen berücksichtigen. Die Meldung operativer und sicherheitsbezogener Vorfälle nach der Zweiten Zahlungsdiensterichtlinie (PSD2) wurde für betroffene Zahlungsinstitute weitgehend durch DORA ersetzt, doch ihre materiellen Pflichten sind in die Kaskade des Artikels 19 DORA übergegangen. Die eIDAS-Verordnung regelt die für die Beweissicherung genutzten Vertrauensdienste. Die sektorale Finanzregulierung besteht neben DORA fort. Eine einzige kohärente Beweisarchitektur aufzubauen – statt getrennter Beweisflüsse für jede Aufsichtsbehörde – ist die operative Effizienz, die gut vorbereitete Finanzunternehmen in der DORA-Ära auszeichnet.

Checkliste für DORA-Vorfallsbeweise (15 Punkte)

Die folgende Checkliste bündelt die operativen Prioritäten aus diesem Leitfaden. Sie ersetzt weder eine Rechtsberatung noch die spezifischen Vorgaben Ihrer zuständigen nationalen Behörde, doch sie erfasst die unterscheidenden Merkmale von Finanzunternehmen, die operativ DORA-bereit sind, im Gegensatz zu lediglich dokumentarisch bereit.

• Bestimmen Sie Ihre DORA-Einstufung (Unterkategorie als Finanzunternehmen) und dokumentieren Sie die Bestimmung mit unterstützenden Verweisen auf die Anwendungsbereichsbestimmungen des Artikels 2 und Ihren nationalen Aufsichtsrahmen.
• Identifizieren Sie die zuständige Behörde und jede für Ihre Unterkategorie geltende Aufsichtsbehörde und richten Sie Kommunikationskanäle vor dem Vorfall ein, einschließlich Vorlagen für die Erstmeldung, die Zwischenmeldung und die Abschlussmeldung.
• Definieren Sie interne Einstufungskriterien für schwerwiegende IKT-bezogene Vorfälle im Einklang mit der Delegierten Verordnung (EU) 2024/1772 der Kommission, einschließlich der Doppelauslöser-Logik (kritische Dienste + Datenverlust ODER kritische Dienste + zwei Schwellenwerte), und überprüfen Sie sie mindestens jährlich.
• Stellen Sie eine 24/7-Erkennungsfähigkeit sicher, damit die Vier-Stunden-Uhr für die Erstmeldung im Moment der Einstufung anlaufen kann, unabhängig von Geschäftszeiten oder Wochenenden.
• Benennen Sie einen primären Vorfallsmeldeverantwortlichen und mindestens einen Stellvertreter mit voller Befugnis, Erstmeldungen innerhalb des Vier-Stunden-Fensters ohne Verzögerungen durch die Zustimmung der Geschäftsleitung einzureichen.
• Führen Sie eine manipulationssichere Protokollierung über die gesamte IKT-Landschaft ein, mit dokumentierten Integritätsprimitiven (Hash-Ketten, qualifizierte elektronische Zeitstempel oder Gleichwertiges) und einer Aufbewahrung, die den sektoralen Erwartungen angemessen ist – typischerweise mindestens 12 Monate, mit längeren Zeiträumen für bestimmte Kategorien.
• Etablieren Sie forensische Erfassungsverfahren für die web-basierten Angriffsartefakte, die für Finanzunternehmen am relevantesten sind – Phishing-Seiten, die Privatkundenoberflächen imitieren, gefälschte Zahlungsautorisierungsseiten, markenimitierende Investmentplattformen, gefälschte KYC-Portale und den Status kritischer IKT-Drittdienstleister während Ausfällen.
• Verbinden Sie Erfassungsartefakte über kryptografische Manifeste (SHA-256 über alle Dateien) und übermitteln Sie den Manifest-Hash an einen in der EU gelisteten qualifizierten Vertrauensdiensteanbieter für einen qualifizierten elektronischen Zeitstempel nach Artikel 42 der Verordnung (EU) 910/2014.
• Verankern Sie Beweispakete unabhängig – zum Beispiel über die Bitcoin-Blockchain via OpenTimestamps –, damit die Integrität ohne Abhängigkeit vom Unternehmen, vom Vertrauensdiensteanbieter oder von einem einzelnen Ausfallpunkt überprüft werden kann.
• Dokumentieren Sie die Beweiskette im Einklang mit den Phasen der ISO/IEC 27037:2012 (Identifizierung, Sammlung, Erfassung, Aufbewahrung) für jedes Beweisstück, mit erfassten Rollen, Zeitstempeln und Handlungen.
• Führen Sie ein aktuelles Informationsregister für alle IKT-Drittparteienvereinbarungen zur Unterstützung kritischer oder wichtiger Funktionen, mit einer Zuordnung der Unterauftragnehmer im Einklang mit der Delegierten Verordnung (EU) 2025/532 der Kommission, bereit zur Einreichung im nationalen Meldezyklus.
• Ermitteln Sie Ihre Abhängigkeit von jedem der 19 benannten kritischen IKT-Drittdienstleister (Stand November 2025), bewerten Sie das Konzentrationsrisiko und dokumentieren Sie Ausstiegsstrategien gemäß Artikel 28.
• Führen Sie die bedrohungsgeleitete Penetrationstestübung nach Artikel 26 durch oder planen Sie sie ein, wenn Sie ein bedeutendes Finanzunternehmen sind, wobei der Übungsplan mit der zuständigen Behörde abgestimmt und die Beweissicherung für den Test selbst dokumentiert ist.
• Ordnen Sie die Überschneidung zwischen DORA und anderen anwendbaren Vorschriften (NIS2-Kooperationskanal über Artikel 47, Artikel 33 DSGVO, PSD2-Übergang, sektorale Finanzregulierung) zu, sodass ein einziger Vorfall koordinierte Meldungen über alle anwendbaren Regime hinweg erzeugt, gestützt auf ein einziges kohärentes Beweispaket.
• Machen Sie alle Beweispakete unabhängig durch Dritte überprüfbar – zuständige Behörden, den federführenden Überwacher bei Angelegenheiten kritischer Drittdienstleister, Gerichte, Versicherer, Rechtsbeistand – mithilfe quelloffener Prüftools und ohne Abhängigkeit von der Infrastruktur des erzeugenden Unternehmens.

Häufig gestellte Fragen und Fazit

Die folgenden Antworten behandeln die Fragen, die am häufigsten aufkommen, wenn Finanzunternehmen beginnen, den DORA-Umgang mit Beweisen operativ umzusetzen. Sie sind als praktische Orientierung gedacht, nicht als Rechtsberatung für eine bestimmte Situation.

Das erste Anwendungsjahr von DORA hat bestätigt, was in der Vorbereitungsphase weithin erwartet wurde: Die Verordnung ist operativ anspruchsvoll, die Fristen sind knapp und die aufsichtliche Befassung ist anhaltend. Die Bestehensquote von 6,5 % bei der Testübung 2024 verdeutlichte die Kluft zwischen politischer Konformität und operativer Bereitschaft. Der Meldezyklus 2026, durchgeführt unter aktiver Durchsetzung, wird ein klareres Bild davon zeichnen, wo einzelne Unternehmen stehen.

Die Fähigkeiten, die operativ DORA-bereite Finanzunternehmen auszeichnen, sind erkennbar. Erkennungssysteme, die Vorfälle mit Tempo einstufen können. Meldeabläufe, die Erstmeldungen innerhalb des Vier-Stunden-Fensters ohne Verzögerungen durch die Zustimmung der Geschäftsleitung erzeugen. Forensische Sicherung von Vorfallsartefakten – insbesondere der web-basierten Angriffsinfrastruktur, die in den Stunden nach der Erkennung am schnellsten verschwindet. Unabhängige Überprüfbarkeit der resultierenden Beweise durch die zuständige Behörde, den federführenden Überwacher bei Angelegenheiten kritischer Drittdienstleister und jedes spätere Gericht oder jeden Versicherer. Keine dieser Fähigkeiten ist exotisch; was das gut vorbereitete Unternehmen auszeichnet, ist, dass sie alle vor dem ersten schwerwiegenden Vorfall vorhanden sind.

GetProofAnchor existiert, um die Komponente der forensischen Sicherung dieses Stacks – konkret die web-basierten Artefakte, die in den Momenten nach der Erkennung am schnellsten verschwinden – unkompliziert, verteidigungsfähig und über DORA, NIS2-Kooperation und DSGVO hinweg gleichzeitig unabhängig überprüfbar zu machen. Wenn Ihr Finanzunternehmen seine DORA-Fähigkeit zum Umgang mit Beweisen aufbaut und sehen möchte, wie sich qualifiziert-zeitgestempelte forensische Web-Erfassung in den Vier-Stunden-Meldeablauf einfügt, ist der direkteste Weg, aus einer beliebigen öffentlichen URL einen Musternachweis zu erstellen und das Beweis-ZIP zu prüfen. Die Verifikation ist quelloffen und läuft auf jedem Laptop. Der Standard ist reproduzierbar, weil er es unter DORA sein muss.