Leitfrage: Wie kann ein Finanzunternehmen die DORA Wiederherstellung nachweisen, also belegen, dass es kritische Prozesse bei einem IT- oder Dienstleisterausfall aufrechterhält und im definierten Szenario wiederherstellt?
Version 1.0 Stichtag der Quellenrecherche: 27.09.2026 Kernquellen: 9 Untersuchungskomplexe Rechtsstand: September 2026 Lesezeit: 32 Minuten
Wer die DORA Wiederherstellung nachweisen will, braucht mehr als ein Rahmenwerk. Die ausgewerteten Veröffentlichungen zeigen, dass Reaktions- und Wiederherstellungsrahmen vielfach vorhanden sind, in manchen Bereichen aber Verbesserungsbedarf besteht[1]. Zugleich kritisiert die britische Aufsicht Selbsteinschätzungen, die die Beherrschbarkeit jedes Szenarios behaupten, ohne Tests unter ausreichend schweren Bedingungen zu belegen[2]. Belastbar wird Resilienz erst, wenn die Wiederherstellung eines Geschäftsprozesses einschließlich Daten, Kontrollen, Dienstleistern und Entscheidungen im definierten Szenario nachgewiesen ist.
Der erste gemeinsame Vorfallbericht der europäischen Aufsichtsbehörden unter DORA erfasst 3.383 schwerwiegende IKT-bezogene Vorfälle des Jahres 2025. Rund 29 % gingen auf Ausfälle zurück, die Dritten zuzurechnen sind, rund 10 % waren cybersicherheitsbezogen[3]. Ein Resilienznachweis, der nur Cyberangriffe betrachtet, greift deshalb zu kurz: Systemfehler, Änderungen, externe Ereignisse und Abhängigkeiten gehören in dasselbe Prüfbild.
Eine repräsentative Quote wirksam aufgestellter Institute lässt sich aus den Quellen nicht ableiten. Meldedaten, Aufsichtsprüfungen, Selbsteinschätzungen, technische Tests und modellierte Stresstests haben unterschiedliche Bezugsgrößen. Diese Auswertung stellt sie getrennt dar und verrechnet sie nicht zu einer Erfolgsquote.
K1 Thematische Prüfung
Alle 109 Banken des EZB-Cyberresilienz-Stresstests reichten Fragebogen und Unterlagen ein. Nur eine Stichprobe von 28 Banken musste zusätzlich einen echten IT-Wiederherstellungstest durchführen und dessen Erfolg nachweisen[1].
Bezugsgröße: 109 direkt von der EZB beaufsichtigte Banken, davon 28 in der vertieften Stichprobe; Stresstest 2024; keine veröffentlichte Bestehensquote.
K2 Thematische Prüfung
Die australische Aufsicht beobachtete trotz vorhandener Backup-Praktiken unzureichende Trennung von Produktiv- und Sicherungsumgebung, zu wenig Tests der Schutzkontrollen und zu wenig Tests der Wiederherstellung innerhalb der Toleranzen[4].
Bezugsgröße: Feststellungen aus laufenden Aufsichtsaktivitäten, Schreiben vom Juni 2024; die Quelle veröffentlicht keinen Nenner.
K3 Thematische Prüfung
Im DORA-Probelauf 2024 bestanden 6,5 % der analysierten Informationsregister alle Datenqualitätsprüfungen; die Hälfte der übrigen scheiterte an weniger als fünf der 116 Prüfungen[5].
Bezugsgröße: Register von knapp 1.000 Finanzunternehmen im freiwilligen Probelauf 2024; gemessen wurde Datenqualität, nicht Wiederanlauffähigkeit.
K4 Jahresbericht
Knapp ein Drittel der schwerwiegenden Vorfälle 2025 ging auf Ausfälle bei Dritten zurück, darunter IKT-Dienstleister, andere Finanzunternehmen und Infrastrukturbetreiber. Ein einzelnes Ereignis bei gemeinsam genutzter Infrastruktur kann Dutzende verbundene Meldungen auslösen[3].
Bezugsgröße: 3.383 institutsspezifische Meldungen für 2025 mit Abschlussmeldung bis 05.02.2026; keine Zahl eindeutiger externer Ereignisse.
K5 Thematische Prüfung
Im britischen Cyber-Stresstest hatten einige Teilnehmer nicht alle verfügbaren Ausweichverfahren getestet. Die Zusicherung Dritter vor einem sicheren Wiederanschluss könnte zudem länger dauern als die eigenen Auswirkungstoleranzen[6].
Bezugsgröße: freiwilliger, modellierter Stresstest 2024 mit Datenlieferungen und Workshops, Ergebnisse Juli 2025; kein Nenner veröffentlicht.
K6 Thematische Prüfung
Die FCA fand unklare Genehmigungswege, fehlende Verantwortliche für Maßnahmen und wenig Evidenz für die Beteiligung der zweiten und dritten Verteidigungslinie an den Selbsteinschätzungen[2].
Bezugsgröße: jährliche Selbsteinschätzungen von Unternehmen im Anwendungsbereich der britischen Regeln, März 2026; Stichprobengröße nicht veröffentlicht.
Die Auswertung prüft, ob und anhand welcher Nachweise Finanzunternehmen kritische Prozesse bei einem IT- oder Dienstleisterausfall aufrechterhalten und wiederherstellen. Sie betrachtet sieben Untersuchungsfelder: Wiederanlauftests, Vorfallmanagement, Informationsregister, IKT-Drittdienstleister, Konzentrationsrisiken, Exit und Leitungsorgan. Im Mittelpunkt steht die Wirksamkeit im Betrieb, nicht die vollständige Kommentierung aller DORA-Pflichten.
Jeder Befund trägt genau eine Evidenzstufe. Die Stufe sagt, wofür ein Befund einstehen kann und wofür nicht. Die Farbe der Tags ist einheitlich; unterschieden wird ausschließlich über den Text.
| Stufe | Evidenztyp | Trägt | Trägt nicht |
|---|---|---|---|
| Länderbewertung | FATF- oder vergleichbare Systembewertung | strukturelle Unterschiede | Aussagen über einzelne Institute; in dieser Auswertung nicht belegt |
| Thematische Prüfung | Aufsichtsprüfung oder -analyse über mehrere Institute | Prozessmuster, gute und schlechte Praxis | Marktprävalenz |
| Einzelfall | Veröffentlichung zu einer Maßnahme oder zur Abhilfe | konkreten Fehlermechanismus | Häufigkeit; in dieser Auswertung nicht belegt |
| Jahresbericht | Tätigkeits- oder Jahresübersicht einer Aufsicht | Prüfungsumfang, Meldezahlen, Maßnahmenzahlen | Fehlerquoten |
| Rechtsakt | verkündete Norm, finale Leitlinie oder Entwurf | Maßstab und Frist | Umsetzungsstand |
Quellen: eigene Zuordnung dieser Auswertung nach dem Methodik-Kasten.
Ein Prozess gilt nicht schon dann als wiederhergestellt, wenn ein Server wieder erreichbar ist. Erforderlich ist ein vorab definierter fachlicher Mindestbetrieb mit nutzbaren Daten, funktionierenden Kontrollen und belastbarer Freigabe. Die folgenden Begriffe sind Arbeitsdefinitionen dieser Auswertung.
Einheitliche Wiederherstellungszeiten für alle Institute lassen sich daraus nicht ableiten. Die Zwei-Stunden-Erwartung aus dem Rahmen für Finanzmarktinfrastrukturen[7] gilt für diese Infrastrukturen und ist nicht pauschal auf Finanzunternehmen übertragbar.
Die Tabelle stellt die quantitativen und qualitativen Kernaussagen je Untersuchungskomplex nebeneinander. Jede Zeile nennt ihre Bezugsgröße und die Grenze ihrer Aussage.
| Untersuchung | Ergebnis | Bezugsgröße | Was folgt und was nicht |
|---|---|---|---|
| Jahresbericht DORA-Vorfallbericht 2025 der ESAs | 3.383 schwerwiegende Vorfälle, davon 1.056 mit grenzüberschreitender Wirkung; 29 % auf Ausfälle Dritter zurückgeführt; 10 % cybersicherheitsbezogen[3] | Institutsspezifische Meldungen 2025 mit Abschlussmeldung bis 05.02.2026; rund 15 % der Meldungen mangels Abschlussmeldung ausgeschlossen | Belegt Breite und Art der Störungen. Keine Zahl eindeutiger Ereignisse, keine Resilienzquote. |
| Thematische Prüfung EZB-Cyberresilienz-Stresstest | Rahmen für Reaktion und Wiederherstellung vorhanden, in manchen Bereichen Verbesserungsbedarf; 28 Banken mit echtem Wiederherstellungstest und Vor-Ort-Besuch[1] | 109 Banken, Stresstest 2024 | Trennt Dokumentation von Ausführung. Die 28 Tests sind nicht mit 28 nachweislich resilienten Banken gleichzusetzen. |
| Thematische Prüfung ESAs-Probelauf Informationsregister | 6,5 % der analysierten Register bestanden alle Prüfungen; 50 % der übrigen scheiterten an weniger als fünf von 116 Prüfungen[5] | Knapp 1.000 Finanzunternehmen, freiwilliger Probelauf 2024 | Belegt Datenqualitätslücken vor Anwendungsbeginn. Keine Aussage, dass 93,5 % der Institute nicht resilient waren. |
| Thematische Prüfung FCA, ein Jahr nach der Übergangsfrist | Starkes Engagement und gute Fortschritte; zugleich unbelegte Wiederherstellungsaussagen, technikzentriertes Mapping und kaum getestete Kommunikationswege[2] | Jährliche Selbsteinschätzungen; Stichprobengröße nicht veröffentlicht | Zeigt Muster in der Evidenzführung. Britischer Maßstab, kein EU-Prüfmaßstab. |
| Thematische Prüfung APRA, Sicherheit und Eignung von Backups | Wiederkehrende Probleme bei Trennung, Schutztests und Wiederherstellungstests innerhalb der Toleranzen[4] | Aufsichtsfeststellungen; kein Nenner veröffentlicht | Gut übertragbare Fehlermechanismen. Keine Aussage über ihre Häufigkeit in DORA-Instituten. |
| Thematische Prüfung CPMI-IOSCO, Cyberresilienz von Finanzmarktinfrastrukturen | Relativ hohe Umsetzung der Leitlinien; einzelne Schwächen bei Wiederherstellungsplanung, Tests nach Systemänderungen und Szenariotests[7] | 37 Infrastrukturen aus 29 Jurisdiktionen, Stand Februar 2021 | Historischer Infrastrukturbefund. Kein heutiger DORA-Stand, kein allgemeiner Maßstab für Banken. |
| Thematische Prüfung Bank of England, Cyber-Stresstest 2024 | Reife Szenariomodellierung; nicht alle Ausweichverfahren getestet; Zusicherungen Dritter vor Wiederanschluss könnten länger dauern als die Toleranzen[6] | Freiwilliger, modellierter Test; Ergebnisse Juli 2025 | Erkenntnisse zu Abhängigkeiten und Wiederanschluss. Kein tatsächlicher Exit-Test. |
| Thematische Prüfung US-Finanzministerium, Cloud-Bericht | Transparenzlücken, Fachkräftemangel, Konzentration und praktische Hürden bei der Migration zu anderen Anbietern[8] | Mehrmonatige Behörden- und Stakeholderanalyse 2023; kein Stichprobennenner | Qualitative Evidenz. Keine gemessene Ausfallwahrscheinlichkeit. |
| Jahresbericht APRA System Risk Outlook | Einige der größten beaufsichtigten Unternehmen stützen sich im Durchschnitt auf rund 150 wesentliche Dienstleister für kritische Abläufe[9] | Teilgruppe der größten Unternehmen, November 2025 | Zeigt die Breite der Abhängigkeiten. Viele Anbieter bedeuten nicht automatisch geringe Konzentration. |
Quellen: [3], [1], [5], [2], [4], [7], [6], [8], [9]
Der Bericht wertet reale Meldungen unter DORA aus und ist deshalb die aktuellste Datenbasis. Er berücksichtigt Vorfälle mit Abschlussmeldung bis zum 5. Februar 2026; für rund 15 % der gemeldeten Vorfälle lag diese nicht vor[3]. Sind mehrere Finanzunternehmen vom selben Ereignis betroffen, meldet jedes Unternehmen den Vorfall selbst. Die 3.383 Vorfälle sind damit weder 3.383 Angriffe noch 3.383 verschiedene Dienstleisterausfälle.
Der Drittparteienanteil umfasst neben IKT-Dienstleistern auch andere Finanzunternehmen und Infrastrukturbetreiber. Er ist deshalb weder eine Cloud-Ausfallquote noch ein Anteil gescheiterter Auslagerungsverträge.
Die EZB legte ein Szenario zugrunde, in dem alle präventiven Maßnahmen versagen und die Datenbanken der Kernsysteme schwer getroffen sind. Bewertet wurden Reaktion und Wiederherstellung, nicht die Abwehr[1]. Der Unterschied zwischen der Dokumentenprüfung aller Teilnehmer und dem echten Test der Stichprobe zeigt, warum eine Selbstauskunft nicht mit technischer Ausführung gleichgesetzt werden darf.
Die australische Aufsicht beschreibt, wie mangelnde Isolation und schwache Tests den Nutzen vorhandener Backups mindern[4]. Die CPMI-IOSCO-Untersuchung nennt fehlende Tests nach wesentlichen Systemänderungen, zu wenig umfassende Szenariotests und eine unzureichende Beteiligung relevanter Akteure[7].
Die Prüffrage an dein Haus lautet: Kann ein definierter Geschäftsprozess mit konsistenten Daten und funktionierenden Kontrollen wieder aufgenommen werden, oder wird nur die Erreichbarkeit einzelner Komponenten bestätigt? Als Nachweis eignen sich Zeitstempel, Wiederherstellungsprotokolle, Abgleich der Datenpopulation, fachliche Testfälle und eine dokumentierte Betriebsfreigabe.
Die FCA sieht begrenzte Evidenz dafür, dass Kommunikationsstrategien in Szenarioübungen getestet werden oder dass Pläne den Ausfall der üblichen Kanäle abdecken[2]. Die Bank of England berichtet, dass Kundenbetreuer und andere Ersthelfer im Vorfall die eigenen Notfallverfahren nicht immer kennen[6].
Für die Meldekette gilt: Die Erstmeldung ist innerhalb von vier Stunden nach Einstufung als schwerwiegend und spätestens 24 Stunden nach Kenntniserlangung fällig[10]. Kenntnis und Einstufung gehören deshalb in getrennte Zeitstempel. Dasselbe gilt für Entscheidung, Meldung, technischen Wiederanlauf und fachliche Freigabe, damit eine schnelle technische Reaktion keine Verzögerung im Meldeprozess verdeckt.
Der Probelauf 2024 belegt Datenqualitätslücken in einem vorbereitenden Meldeprozess. Die ESAs hielten ausreichende Registerqualität für 2025 mit zusätzlichem Aufwand der Branche für erreichbar[5]. Die 6,5 % sind deshalb keine Qualitätsquote für 2026 und keine Aussage über Notfallvorsorge.
Das Register nach Art. 28 Abs. 3 DORA erfasst die vertraglichen Vereinbarungen über IKT-Dienstleistungen[11]; die Vorlagen legt die Durchführungsverordnung (EU) 2024/2956 fest[12]. Die ESAs wollen das Register künftig mit den Vorfallmeldungen verknüpfen, um Vorfälle bei kritischen IKT-Drittdienstleistern und Konzentrationen besser zu erkennen[3]. Technische Validierung und fachliche Vollständigkeit bleiben getrennte Prüfergebnisse: Ein formal plausibles Register kann eine relevante Abhängigkeit trotzdem falsch abbilden.
Nach dem Vorfallbericht stimmen Finanzunternehmen Folgemaßnahmen mit externen Dienstleistern ab, vor allem wenn der Vorfall dort entstanden ist[3]. Das US-Finanzministerium beschreibt, dass insbesondere kleinere Banken oft keine Details zu Vorfällen erhalten, die ihre Systeme betreffen[8]. Zertifikate und allgemeine Anbieterberichte beantworten deshalb nicht automatisch, ob die konkret genutzte Konfiguration und Prozesskette wiederherstellbar ist.
Als Nachweiskette empfiehlt diese Auswertung: zugesicherte Leistung, konkret genutzte Architektur, gemeinsame Abhängigkeiten, Reaktionswege, Mitwirkung an Tests und belegte Behandlung von Feststellungen. Ein Anbietertest ist verwendbar, wenn sein Umfang zur bezogenen Leistung passt; für das Urteil „nachweislich wirksam“ kommen die eigenen Schnittstellen, Daten und Kontrollschritte hinzu.
Das US-Finanzministerium verweist auf einen Markt mit wenigen Cloud-Anbietern, in dem ein Vorfall bei einem Anbieter viele Kunden gleichzeitig treffen kann[8]. Die australische Aufsicht sammelt Daten zu wesentlichen Dienstleistern, um zu erkennen, wo sich mehrere Institute auf dieselben Anbieter stützen[9]. Der DORA-Vorfallbericht beschreibt, wie kleinere Gruppenunternehmen auf dieselbe Infrastruktur und dieselben großen Dienstleister zugreifen, sodass ein einzelner Ausfall Dutzende Meldungen erzeugen kann[3].
Zu prüfen sind deshalb gemeinsame Ausfallursachen: Cloud-Region, Identitätsdienst, Netzanbindung, Schlüsselverwaltung, Unterauftragnehmer und der Zugriff des Krisenteams. Zwei Anbieter können dieselbe kritische Infrastruktur nutzen; eine gut getrennte Architektur bei einem Anbieter kann bestimmte Störungen wirksam begrenzen.
Das US-Finanzministerium nennt praktische Hürden, Risiken zu mindern oder den Betrieb zu einem anderen Anbieter zu verlagern[8]. Die Bank of England hält fest, dass komplexe Großbetragszahlungsdienste oft weder ersetzbar noch übertragbar sind[6]. Der Cloud-Leitfaden der EZB ist nicht rechtsverbindlich und schafft keine Anforderungen über DORA hinaus[13].
Eine belastbare Quote erfolgreich durchgeführter Cloud-Exits von DORA-Instituten liefern die Quellen nicht. Diese Lücke darf nicht mit der Behauptung gefüllt werden, die Mehrheit der Institute könne ihre Anbieter nicht verlassen. Zu unterscheiden sind drei Nachweise: eine geregelte Exit-Option, eine praktisch verfügbare Alternative und die erprobte Übertragung wesentlicher Daten und Funktionen. Für die Zeit zwischen Ausfall und abgeschlossenem Wechsel ist ein Überbrückungsbetrieb gesondert zu bewerten.
Die FCA fand gute Beispiele aktiver Gremienarbeit, aber auch unklare Genehmigungswege, fehlende Maßnahmenverantwortliche und Zweifel am Verständnis der Leitungsebene für ihre Verantwortung[2]. DORA weist dem Leitungsorgan die letztendliche Verantwortung für das IKT-Risikomanagement zu[11]. Eine Freigabe ist deshalb nur dann ein Resilienznachweis, wenn sie sich auf konkrete Testergebnisse, deren Grenzen und die verbleibenden Risiken bezieht.
Die Quellen tragen keine pauschale Krisenerzählung. Zwei Drittel der schwerwiegenden Vorfälle 2025 führten zu keiner oder nur geringer Beeinträchtigung von Kunden und Transaktionen; die ESAs sehen darin einen Hinweis auf wirksame Erkennung und Eindämmung[3]. Die FCA beschreibt starkes Engagement und gute Fortschritte in allen Bereichen ihrer Regeln[2]. CPMI-IOSCO stellt eine relativ hohe Umsetzung der Cyber-Leitlinien fest[7], und die Bank of England bescheinigt den Teilnehmern reife Szenariomodellierung sowie Reaktions- und Wiederherstellungsfähigkeiten[6]. Ein flächendeckender Nachweis belastbarer Resilienz folgt daraus ebenso wenig wie ein pauschales Scheitern.
DORA gilt seit dem 17. Januar 2025[11]. Die Umsetzung ist kein Projekt mit bevorstehendem Anwendungsbeginn, sondern laufender Pflichtenbetrieb. Vor jeder Bewertung sind Anwendungsbereich, Ausnahmen, ein etwaiger vereinfachter Rahmen und die Verhältnismäßigkeit für das eigene Haus zu klären.
Die Tests der IKT-Geschäftsfortführungspläne nach Art. 11 Abs. 6 DORA konkretisiert Art. 25 der Delegierten Verordnung (EU) 2024/1774: Die Tests stützen sich auf schwere, aber plausible Szenarien, beziehen gegebenenfalls die Leistungen von IKT-Drittdienstleistern ein und umfassen Umstellungen auf redundante Kapazitäten[14].
| Feld | Grundlage | Abgrenzung |
|---|---|---|
| Governance | Art. 5 DORA | Letztverantwortung des Leitungsorgans für das IKT-Risikomanagement; institutsspezifische Rahmenbedingungen bleiben zu berücksichtigen. |
| Geschäftsfortführung und Tests der Pläne | Art. 11 Abs. 6 DORA, Art. 25 VO 2024/1774 | Schwere, aber plausible Szenarien, Drittdienstleister, Umstellungen auf redundante Kapazitäten. |
| Allgemeines Testprogramm | Art. 24 DORA | Risikobasiertes Testprogramm; Systeme und Anwendungen kritischer oder wichtiger Funktionen werden mindestens jährlich getestet. |
| Bedrohungsorientierte Tests (TLPT) | Art. 26 DORA | Nur für von der Aufsicht ermittelte Finanzunternehmen, grundsätzlich mindestens alle drei Jahre; kein pauschaler Maßstab für alle Institute. |
| Informationsregister | Art. 28 Abs. 3 DORA, DVO 2024/2956 | Vertragliche Vereinbarungen über IKT-Dienstleistungen in standardisierten Vorlagen. |
| Exit und Verträge | Art. 28 DORA | Ausstiegsstrategien für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen. |
| Vorfallmeldung | Art. 19 DORA, Art. 5 VO 2025/301 | Erstmeldung innerhalb von vier Stunden nach Einstufung, spätestens 24 Stunden nach Kenntniserlangung; weitere Fristen und Sonderregeln im Einzelfall prüfen. |
Quellen: [11], [14], [12], [10]
Die EBA hat im September 2026 ihre finalen Leitlinien EBA/GL/2026/09 veröffentlicht und eine zweijährige Übergangsfrist angekündigt[15]. Die Leitlinien gelten für Nicht-IKT-Dienstleistungen; das IKT-Risikomanagement und die Nutzung von IKT-Dienstleistungen bleiben nach Rn. 7 ausgenommen, weil sie unter DORA fallen[16].
Der Adressatenkreis nach Rn. 9 ist nicht mit dem DORA-Anwendungsbereich identisch. Er umfasst Institute im Sinne der CRR, Wertpapierfirmen mit Ausnahme kleiner und nicht verflochtener, Zahlungs- und E-Geld-Institute, Emittenten vermögenswertreferenzierter Token sowie Kreditgeber nach der Wohnimmobilienkreditrichtlinie, soweit sie Finanzinstitute sind. Die Adressateneigenschaft ist gesondert zu prüfen.
Zum zeitlichen Status: Die finale Fassung enthält in Rn. 18 und Rn. 22 für Anwendung und Aufhebung der Leitlinien von 2019 noch Datumsplatzhalter; Rn. 20 knüpft die Übergangsmarke an zwei Jahre ab Anwendung. Aus der Veröffentlichung folgt deshalb weder eine sofortige Anwendung noch eine feste Umsetzungsfrist. Rn. 58 verlangt, IKT-Unterauftragnehmer zu dokumentieren, die Nicht-IKT-Leistungen für kritische oder wichtige Funktionen tatsächlich stützen; Rn. 61 erlaubt ein gemeinsames Register mit dem DORA-Register.
Laufende Entwürfe wertet diese Auswertung nicht aus. Wo Konkretisierungen im Verfahren sind, gilt der Stand der verkündeten Norm.
| Regelungskreis | Status | Frist | Umgang |
|---|---|---|---|
| Verordnung (EU) 2022/2554 (DORA) | verkündet, anwendbar | seit 17.01.2025 | Eigene Rechtsprüfung und IKT-Testnachweise; Defizite sofort behandeln. |
| Delegierte VO (EU) 2024/1774 | verkündet, in Kraft | Amtsblatt vom 25.06.2024 | Maßstab für Testdesign und Geschäftsfortführung. |
| Durchführungsverordnung (EU) 2024/2956 | verkündet, in Kraft | laufende Registerführung | Vorlagen des Informationsregisters. |
| Delegierte VO (EU) 2025/301 | verkündet, in Kraft | Amtsblatt vom 20.02.2025 | Meldefristen im Vorfalltest getrennt protokollieren. |
| EBA/GL/2026/09 (Nicht-IKT-Drittparteien) | final veröffentlicht, noch nicht anwendbar | veröffentlicht September 2026; Anwendungsdatum in der Fassung offen | Nicht-IKT-Prüfpfad vorbereiten, keine Frist unterstellen, Adressateneigenschaft prüfen. |
| Entwürfe | in dieser Auswertung nicht ausgewertet | keine | Nicht als Prüfmaßstab verwenden. |
Resilienz scheitert selten an einer einzelnen Stelle. Sie scheitert, wenn Verantwortung, Durchführung und Überprüfung nicht getrennt sind oder wenn Testbefunde auf keiner Ebene zu einer Entscheidung führen. Die folgenden Leitungsfragen leiten sich aus den Befunden in Kapitel 03 ab.
Trägt die letztendliche Verantwortung für das IKT-Risikomanagement nach Art. 5 DORA[11]. Sie entscheidet über Wiederherstellungsziele, Ressourcen und die Akzeptanz verbleibender Risiken.
Leitungsfrage: Welche kritischen Funktionen sind nur beschrieben, welche getestet und welche innerhalb der Ziele erfolgreich erprobt?
Überwacht die Geschäftsleitung. Für die Resilienz heißt das: nach Testbefunden, offenen wesentlichen Feststellungen und deren Nachprüfung fragen, nicht nach dem Projektstatus.
Leitungsfrage: Liegt ein evidenzbasiertes Profil der sieben Felder vor, und sind kritische Lücken mit Verantwortlichen und Fristen versehen?
Die Funktionen für IKT-Risiko und Informationssicherheit bewerten Tests und Abhängigkeiten als zweite Verteidigungslinie. Ihre Beteiligung muss in den Unterlagen erkennbar sein; die FCA fand dafür oft wenig Evidenz[2].
Leitungsfrage: Weist das Reporting offene Risiken und benötigte Entscheidungen aus, oder nur Bearbeitungsstände?
Prüft Verfahren, Tests und Maßnahmenabschlüsse unabhängig vom bewerteten Prozess. Eine Maßnahme gilt erst als geschlossen, wenn ihre Wirksamkeit nachgeprüft ist.
Leitungsfrage: Ist die Prüfinstanz personell und organisatorisch von dem Prozess getrennt, den sie bewertet?
Ordne jedes Feld ein. Zu jedem Zustand erscheint eine Empfehlung. Die Selbsteinschätzung ersetzt keine evidenzbasierte Prüfung; sie zeigt, wo die Leitung zuerst nachfragen sollte. Es werden keine Angaben gespeichert oder übertragen.
Ein „Offen“ bei Wiederanlauf oder Konzentration wiegt schwerer als mehrere „Teilweise“ in anderen Feldern. Ein Durchschnitt darf schwere Einzelmängel nicht verdecken.
Diese Schritte sind unabhängig vom weiteren Verfahrensstand richtig. Sie schaffen Nachweisfähigkeit nach geltendem Recht.
Tatsächliche kritische Funktionen, Wiederherstellungsziele, Datenwege, Dritte und offene Befunde in einer Liste abgleichen.
Wiederanlauf nicht beim Systemstart, sondern bei fachlicher Freigabe mit abgeglichenen Daten als erreicht werten.
Informationsregister gegen Vertragsbestand, Funktions- und Systeminventar und bekannte Unterauftragnehmer abgleichen.
Gemeinsame technische und organisatorische Ausfallursachen je kritischer Funktion ausweisen.
Krisenkommunikation und Freigaben bei Ausfall von Identitäts-, Telefonie- und Kollaborationsdiensten üben.
Jede Leitungsentscheidung zu Resilienz mit Testbefund, Grenzen, Restrisiko, Verantwortlichem und Frist dokumentieren.
Die Zeitabschnitte sind ein Arbeitsvorschlag und keine regulatorische Schonfrist. Bestehende Pflichtverletzungen und kritische Betriebsrisiken sind unverzüglich zu behandeln.
| Zeitraum | Priorität | Ergebnis und Entscheidungsnachweis |
|---|---|---|
| Tage 1 bis 30 | Kritische Funktionen, Ziele, Datenwege, Dritte und offene Befunde abgleichen | Freigegebener Scope, bekannte Blindstellen, Zwischenmaßnahmen, Verantwortliche |
| Tage 31 bis 60 | Register und Abhängigkeitsübersicht plausibilisieren; Restore-, Failover- und Kommunikationsannahmen prüfen | Belegte Datenqualität, nutzbare Ersatzpfade, priorisierte Testfälle |
| Tage 61 bis 90 | Cloud- und Monitoring-Szenario mit technischer und fachlicher Beteiligung durchführen | Messwerte, Abweichungen, kritische Befunde, Leitungsentscheidungen |
| Tage 91 bis 120 | Konzentration und Exit vertiefen; kritische Migrationsschritte prüfen | Realistische Übergangspläne, geprüfte Migrationsschritte |
| Tage 121 bis 180 | Wesentliche Befunde schließen, unabhängig nachprüfen, in Regelbetrieb und Schulung überführen | Aktualisiertes Profil mit sichtbaren Restlücken und nachvollziehbarer Abnahme |
Quellen: eigene Ableitung aus den Befunden, insbesondere [2], [6], [5]
Eigene methodische Entwicklung dieser Auswertung, kein Messergebnis. Der Rahmen misst keine Branchenverteilung, sondern legt fest, welche Evidenz eine Einstufung tragen muss.
Ein fehlgeschlagener Test bleibt als „getestet, mit wesentlichem Befund“ sichtbar und wird nicht als Erfolg dargestellt. Wesentliche unbehobene Schwächen erhalten unabhängig von der Stufe den Status „kritisch“, damit Testaktivität allein kein positives Urteil erzeugt.
| Stufe | Mindestvoraussetzung | Was noch nicht bewiesen ist |
|---|---|---|
| Geregelt | Aktuelles Konzept, Umfang, Ziele, Verantwortliche und Freigaben liegen vor. | Tatsächliche Einsatzfähigkeit |
| Implementiert | Systeme, Rechte, Prozesse und Schnittstellen sind nachweislich eingerichtet und nutzbar. | Funktionieren unter schwerer Störung |
| Getestet | Eine geeignete Prüfung wurde durchgeführt; Bedingungen, Messwerte und Abweichungen sind dokumentiert. | Zielerreichung; der Test kann gescheitert sein |
| Nachweislich wirksam | Ein angemessen schweres Szenario wurde im Umfang erfolgreich bewältigt; Zeit-, Daten-, Kapazitäts- und Kontrollziele sind belegt, Befunde nachgeprüft. | Andere Szenarien, nicht getestete Abhängigkeiten, dauerhafte Fehlerfreiheit |
| Nicht nachgewiesen | Evidenz fehlt oder reicht für keine Einstufung. | Kein bestätigtes Versagen und keine gemessene niedrige Reife |
Quellen: eigene methodische Entwicklung auf Grundlage von [1], [2], [14]
Der Katalog umfasst 28 Kriterien, vier je Feld. Bewertet wird die nachgewiesene Stufe, nicht der Umfang der Dokumentation.
| Feld | Vier Kriterien | Evidenz für „nachweislich wirksam“ |
|---|---|---|
| Wiederanlauf | Funktionsbezogene Ziele; tatsächlicher Restore oder Failover; Datenkonsistenz; fachlicher Mindest- und Normalbetrieb | Messwerte, Abgleiche, Kontrollausführung und fachliche Freigabe unter Szenariobedingungen |
| Vorfallmanagement | Erkennung und Einstufung; Krisenentscheidung; erreichbare Kommunikations- und Meldewege; Nachbearbeitung und Re-Test | Vollständige Zeitachse, genutzte Ausweichkanäle, nachvollziehbare Entscheidungen |
| Informationsregister | Vollständige Verträge; korrekte Funktionszuordnung; Unterauftragnehmer und Abhängigkeiten; Änderungsqualität | Abgleich mit unabhängigen Beständen und Nutzung der Daten für die Auswirkungsanalyse einer Übung |
| IKT-Drittdienstleister | Leistungsbezogene Due Diligence; nutzbare Vertragsrechte; Reaktions- und Testmitwirkung; Maßnahmenverfolgung | Abgestimmte Ausführung und passende Anbieterbelege einschließlich eigener Schnittstellen |
| Konzentration | Direkte Exponierung; gemeinsame Unterauftragnehmer und Infrastruktur; Ersatz- und Überbrückungskapazität; Entscheidung über Restkonzentration | Geprüfte gemeinsame Ausfallursachen und tragfähige Ersatzpfade |
| Exit | Auslöser und Rollen; verfügbare Alternative; Daten- und Funktionsübertragung; Übergangsbetrieb und fachliche Abnahme | Erfolgreich geprüfte kritische Migrationsschritte mit realistischen Zeit- und Ressourcennachweisen |
| Leitungsorgan | Ziel- und Risikoentscheidung; Ressourcen; Krisenentscheidungen; Nachverfolgung und Qualifizierung | Nachvollziehbare Entscheidungen anhand realer Testbefunde und deren Nachprüfung |
Quellen: eigene methodische Entwicklung auf Grundlage von [2], [4], [5], [6]
Die primäre Darstellung ist ein Profil der sieben Felder. Ein Feld erhält die höchste Stufe nur, wenn alle als wesentlich festgelegten Kriterien sie erreichen. Selbsteinschätzung und unabhängige Evidenzbewertung werden getrennt erfasst. Eine Umrechnung der Stufen in eine prozentuale Ausfallsicherheit wird nicht empfohlen.
Vorgeschlagenes Testdesign, keine durchgeführte Untersuchung. Ein Cloud-Dienst unterstützt eine kritische oder wichtige Funktion; die primäre Region ist nicht verfügbar, der Anbieter nennt zunächst keinen Wiederherstellungstermin.
| Phase | Einspielung | Geforderter Nachweis |
|---|---|---|
| Erkennung | Geschäftsservice gestört, technische Meldungen uneindeutig | Erkennungszeit, betroffene Funktionen, vorläufige Auswirkungsanalyse |
| Verschärfung | Identitäts- oder Kollaborationsdienst ebenfalls beeinträchtigt | Nutzbare Ausweichkommunikation, Zugriff auf Pläne und Freigaben |
| Abhängigkeitsprüfung | Ersatzdienst nutzt denselben Unterauftragnehmer | Korrigierte Abhängigkeitsübersicht, Entscheidung über den Ersatzpfad |
| Wiederanlauf | Ersatzkapazität aktiv, Daten nicht vollständig aktuell | Tatsächliche Wiederherstellungszeit, Datenstand, Abgleiche, Mindestbetrieb |
| Stabilisierung | Last steigt, Rückstände und Dubletten werden sichtbar | Kapazitätsprüfung, priorisierter Rückstandsabbau, konsistente Verarbeitung |
| Exit-Prüfung | Längere Beeinträchtigung wird plausibel | Entscheidungsgrundlage für Überbrückung oder Wechsel, geprüfte Migrationsschritte |
Quellen: eigene methodische Entwicklung auf Grundlage von [8], [6], [3]
Vorgeschlagenes Testdesign, keine durchgeführte Untersuchung. Das AML-Transaktionsmonitoring erzeugt keine neuen Alerts, die Transaktionsverarbeitung läuft weiter. Unklar ist, ob Oberfläche, Szenarioausführung oder Datenzuführung betroffen sind.
| Phase | Einspielung | Geforderter Nachweis |
|---|---|---|
| Erkennung | Alert-Volumen fällt unerwartet auf null | Erkennung ohne Fehlermeldung, Abgleich mit dem Transaktionsvolumen |
| Eingrenzung | Anbieter bestätigt Störung, Beginn der Datenlücke offen | Betroffene Population, Zeitfenster, Produkte, Kundenrisiken |
| Entscheidung | Geschäft und AML-Funktion bewerten Weiterbetrieb unterschiedlich | Dokumentierte risikobezogene Entscheidung mit Zuständigkeit und Befristung |
| Ersatzbetrieb | Manuelle Kapazität reicht nicht für alle Vorgänge | Priorisierung, Kapazitätsnachweis, Umgang mit nicht beherrschbaren Risiken |
| Wiederherstellung | Dienst verfügbar, aufgelaufene Daten müssen nachverarbeitet werden | Vollständige Nachverarbeitung, Kontrolle auf Lücken und Dubletten |
| Fachliche Abnahme | Neue und nachträgliche Alerts treffen gleichzeitig ein | Risikobasierte Bearbeitung, Rückstandsabbau, Freigabe durch die Zuständigen |
Quellen: eigene methodische Entwicklung auf Grundlage von [6], [2]
Das Szenario begründet weder eine pauschale Pflicht, sämtliche Transaktionen einzustellen, noch eine generelle Erlaubnis zum Weiterbetrieb. Eine grüne Systemstatusmeldung ist kein ausreichender Nachweis des fachlichen Wiederanlaufs.
Die Kennzahlen sind Vorschläge dieser Auswertung. Sie werden nach Kritikalität, Szenario, Testumgebung und Datenbasis getrennt ausgewiesen. Niedrige Vorfallzahlen allein gelten nicht als Wirksamkeitsnachweis.
| Kennzahl | Definition mit Nenner | Interpretationsschutz |
|---|---|---|
| Testabdeckung | Geprüfte relevante Prozess-Szenario-Paare / geplante relevante Paare im Zeitraum | Durchführung sagt nichts über Erfolg |
| Zielerreichung Wiederanlauf | Getestete Paare mit erreichtem RTO und fachlicher Freigabe / bewertbare getestete Paare | RPO und Kontrollqualität zusätzlich ausweisen |
| Datenwiederherstellung | Paare mit erreichtem RPO und abgeschlossenem Datenabgleich / entsprechend geprüfte Paare | Unterschiedliche Datenpopulationen nicht gleichsetzen |
| Ungesicherte Ersatzannahmen | Wesentliche Ersatzpfade ohne ausreichende Evidenz / alle wesentlichen Ersatzpfade | Nicht bewertbar ist kein bestätigter Ausfall |
| Konzentration | Kritische oder wichtige Funktionen je gemeinsamem Ausfallbereich, mit geprüften Ersatzpfaden | Lieferantenzahl oder Einkaufsvolumen genügen nicht |
| Exit-Nachweistiefe | Kritische Exit-Schritte mit bestandenem Nachweis / als wesentlich definierte Exit-Schritte | Teilschritte nicht als Anbieterwechsel ausgeben |
| Offene wesentliche Befunde | Anzahl, Alter und Risikoklasse ungeschlossener wesentlicher Befunde | Schließung nur nach Nachprüfung |
| Entscheidungsdauer | Dauer von definierter Eskalation bis dokumentierter Entscheidung | Nur zusammen mit Entscheidungsqualität bewerten |
Quellen: eigene methodische Entwicklung; Messlogik angelehnt an [3], [2]
Diese Arbeit ist keine erschöpfende systematische Literaturübersicht, keine kausale Wirkungsanalyse zu DORA und keine repräsentative Erhebung deutscher Institute. Sie verfügt nicht über vertrauliche Einzeltestdaten, einheitlich beobachtete Wiederherstellungszeiten oder eine Datenbasis erfolgreicher Exits; mehrere Quellen veröffentlichen keinen Nenner, zwei stammen aus Beobachtungszeiträumen vor dem DORA-Anwendungsbeginn, und britische, US-amerikanische und australische Befunde folgen eigenen Regelwerken. Gerade zur aktuellen Exit-Wirksamkeit bleibt die öffentliche quantitative Evidenz dünn.
Wer die DORA Wiederherstellung nachweisen will, beantwortet die Leitfrage instituts- und szenariobezogen: Kritische Prozesse sind erst belastbar abgesichert, wenn ihr Betrieb oder ihre Wiederherstellung unter angemessen schweren Bedingungen mit nutzbaren Daten, wirksamen Kontrollen und tragfähigen Abhängigkeiten belegt ist. Der Messrahmen in Kapitel 06 macht sichtbar, wo ein Haus noch auf Annahmen statt auf geprüfte Fähigkeiten vertraut.
DORA gilt seit dem 17. Januar 2025. Die Umsetzung ist deshalb kein Projekt mit bevorstehendem Anwendungsbeginn, sondern laufender Pflichtenbetrieb. Vor jeder Bewertung sind Anwendungsbereich, Ausnahmen und Verhältnismäßigkeit für das eigene Haus zu klären.
Nein. Ein Backup-Test zeigt, dass Daten gesichert und zurückgespielt werden können. Der Nachweis der Wiederherstellung verlangt zusätzlich isolierte Sicherungen, geprüfte Schutzkontrollen, konsistente Daten und eine fachliche Freigabe des Prozesses innerhalb der festgelegten Ziele.
Sie zählt institutsspezifische Meldungen des Jahres 2025 mit Abschlussmeldung bis zum 5. Februar 2026. Mehrere Institute können dasselbe Ereignis jeweils selbst melden. Die Zahl beschreibt Breite und Art der Störungen, aber keine Resilienzquote.
Nein. Der Probelauf 2024 prüfte die Datenqualität der Informationsregister in einem freiwilligen Vorbereitungskontext. Er misst weder die heutige Registerqualität noch die Fähigkeit, kritische Prozesse wiederherzustellen.
Noch nicht. Die EBA hat die finalen Leitlinien im September 2026 veröffentlicht. Die Fassung nennt in Rn. 18 noch kein Anwendungsdatum; die Übergangsmarke nach Rn. 20 knüpft an zwei Jahre ab Anwendung an. IKT-Dienstleistungen bleiben im Regelungskreis von DORA.
Die Quellen beruhen auf unterschiedlichen Rechtsordnungen, Zeiträumen, Untersuchungseinheiten und Auswahlverfahren, und mehrere nennen keinen Nenner. Eine gemeinsame Quote ließe sich nur rechnerisch erzeugen, nicht belastbar ableiten. Die Wirksamkeit muss im eigenen Haus gemessen werden.
Alle Quellen wurden am 27.09.2026 abgerufen. Die Nummern folgen der ersten Nennung im Text, die Gruppen der Rangfolge der Quellen. Zu jedem Eintrag steht, wofür er in dieser Auswertung einsteht.
Die Tabelle dokumentiert den Kernbestand der Auswertung. Rechtsakte, die finale EBA-Leitlinie und der EZB-Cloud-Leitfaden zählen nicht als empirische Untersuchungen.
| ID | Veröffentlichung | Untersuchungseinheit | Methodische Einordnung |
|---|---|---|---|
| D01 | ESAs, Vorfallbericht 2025, 03.06.2026[3] | 3.383 institutsspezifische Meldungen | Jahresbericht; Melde- und Datenqualitätsgrenzen, Mehrfachbetroffenheit |
| D02 | EZB, Cyberresilienz-Stresstest, 26.07.2024[1] | 109 Banken, davon 28 vertieft | Thematische Prüfung; keine veröffentlichte Erfolgsquote |
| D03 | ESAs, Probelauf Register, 17.12.2024[5] | Register von knapp 1.000 Finanzunternehmen | Thematische Prüfung; Datenqualität, nicht Resilienz |
| D04 | FCA, Operational Resilience, 27.03.2026[2] | Jährliche Selbsteinschätzungen, ohne Nenner | Thematische Prüfung; britischer Maßstab |
| D05 | APRA, Backups, 03.06.2024[4] | Aufsichtsfeststellungen, ohne Nenner | Thematische Prüfung; übertragbare Fehlermechanismen |
| D06 | CPMI-IOSCO, Level-3-Assessment, 29.11.2022[7] | 37 Infrastrukturen aus 29 Jurisdiktionen, Stand 02/2021 | Thematische Prüfung; historischer Infrastrukturbefund |
| D07 | Bank of England, Cyber-Stresstest, 09.07.2025[6] | Freiwillige Teilnehmer, modelliertes Szenario | Thematische Prüfung; kein tatsächlicher Exit-Test |
| D08 | US-Finanzministerium, Cloud-Bericht, 08.02.2023[8] | Behörden- und Stakeholderanalyse, ohne Nenner | Thematische Prüfung; qualitative Evidenz |
| D09 | APRA, System Risk Outlook, 20.11.2025[9] | Teilgruppe der größten Unternehmen | Jahresbericht; nicht auf den Gesamtmarkt übertragbar |
S+P Governance (2026): DORA Wiederherstellung nachweisen statt Resilienz dokumentieren. Version 1.0, Stand 27.09.2026. https://schulz-beratung.de/dora-wiederherstellung-nachweisen/
Einzelne Befunde sind direkt verlinkbar, etwa über die Anker #dor-k1 bis #dor-k6.
| Version | Datum | Änderung |
|---|---|---|
| 1.0 | 27.09.2026 | Erstveröffentlichung |
Quellen: Versionsführung dieser Auswertung.
Grundlagen zum Register, auf das sich Befund K3 bezieht.
Vertiefung zu Konzentration und gemeinsamen Ausfallbereichen.
Grundlage für funktionsbezogene Wiederherstellungsziele.
Hintergrund zur Auswahl schwerer, aber plausibler Szenarien.
Überblick über Resilienz als Leitungsaufgabe.
Ergänzende Einordnung kritischer Prozesse im Finanzsektor.
S+P Compliance
Wenn im eigenen Haus Kapazität für Registerabgleich, Testnachweise oder eine vom Prozess unabhängige Prüfung fehlt, übernimmt S+P Compliance die operative Seite. Zu S+P Compliance
S+P Seminare
Wenn Leitung, IKT-Risikofunktion und Auslagerungsmanagement die Nachweislogik selbst tragen sollen, bietet S+P Seminare Programme dafür. Zu S+P Seminare
Achim Schulz kennt den Druck von IT-Audits aus dem täglichen Geschäft. Mit der S+P Compliance Services agiert er permanent als Auslagerungsdienstleister für regulierte Unternehmen. Er steckt jeden Tag tief in der Materie. Er weiß genau: DORA, NIS-2 und der CRA dulden keine Ausreden. Er ist der perfekte Sparringspartner für IT-Verantwortliche und die Geschäftsleitung. Warum? Weil er die strengen Vorgaben der Aufsicht täglich in der eigenen Praxis umsetzt. Er schließt die gefährliche Lücke zwischen technischer IT-Sicherheit und aufsichtsrechtlicher Pflicht. Er weiß exakt, was Prüfer heute sehen wollen. In seinen Seminaren gibt es keine abstrakte Theorie. Er übersetzt komplexe RTS-Vorgaben in glasklare Prozesse. Mithilfe der S+P Tool Box liefert er dir sofort anwendbare Templates aus der eigenen Dienstleister-Praxis. Vom IKT-Drittparteien-Register bis zum rechtssicheren Incident-Reporting. Das klare Ziel: Dein Unternehmen wird zu 100 % audit-ready. Du bestehst jeden Belastungstest souverän. Und du schützt das Unternehmen zuverlässig vor drastischen Sanktionen.
LinkedIn-Profil → · Redaktion & Experten →Wir verwenden Cookies und ähnliche Technologien, um Ihre Erfahrung auf unserer Website zu verbessern. Weitere Informationen in unserer Datenschutzerklärung.