DORA: Was die BaFin 2026 konkret von Banken und Versicherern erwartet

Wer als Bank, Versicherer oder Kapitalverwaltungsgesellschaft noch glaubt, DORA sei eine „ferne EU-Verordnung“, die mit dem Stichtag 17. Januar 2025 erledigt ist, der irrt. Die Verordnung (EU) 2022/2554 (Digital Operational Resilience Act) ist seit über einem Jahr vollständig anwendbar – und die BaFin-Aufsicht beginnt 2026, die ersten Prüfungen durchzuziehen. Wer in der ersten Welle auffällt, sollte sich nicht wundern, wenn die Aufsicht nach den Befunden die Aufsichtsgespräche verschärft.

Der Beitrag führt operativ durch das, was DORA von Finanzinstituten verlangt und was die BaFin in den ersten Aufsichtsverfahren tatsächlich prüft. Er richtet sich an Vorstände, Chief Information Security Officer und IKT-Risikomanagement-Verantwortliche. Stand: 19. August 2026.

Warum DORA jetzt zählt

DORA ist nicht BaFin-Rundschreiben 10/2017 in neuem Gewand. Die Verordnung schafft einen eigenen Aufsichtsraum für die IKT-Resilienz von Finanzinstituten – europaweit unmittelbar geltend, ohne nationale Umsetzung. Wer in Deutschland betroffen ist, kann sich nicht auf nationales Recht zurückziehen, sondern muss die europäischen Vorgaben direkt anwenden.

Was sich gegenüber den alten BAIT (Bankaufsichtliche Anforderungen an die IT) verändert hat: DORA denkt IKT-Risiko nicht mehr als IT-Frage, sondern als operative Resilienz. Backup-Strategien, Drittdienstleister-Management, Vorfalls­meldungen – alles wird integriert betrachtet. Wer sich bisher auf das BAIT-Silo verlassen hat, muss jetzt Querverbindungen schaffen, die vorher nicht verlangt wurden.

Hinzu kommt: die ersten Bußgelder nach DORA sind in anderen EU-Staaten bereits verhängt worden, in Deutschland hat die BaFin Ende 2025 eine erste öffentliche Mitteilung zu Aufsichtserwartungen veröffentlicht. Die Phase der Großzügigkeit ist vorbei.

Wer betroffen ist – und wer nicht

DORA gilt für eine breite Palette von Finanzinstituten: Kreditinstitute, Wertpapierfirmen, Versicherungs­unternehmen, Rückversicherer, Kapitalverwaltungs­gesellschaften, Zahlungsdienstleister und einige mehr. Im Kern der Anhang I und II der Verordnung: alle Institute, die bereits unter CRD, CRR, Solvency II, MiFID II oder vergleichbare Regelwerke fallen. Was die wenigsten wissen: auch IKT-Drittdienstleister, die kritische Dienste für diese Institute erbringen, geraten mittelbar unter Aufsicht – nicht direkt durch DORA, aber durch die Pflicht der Institute, ihre Dienstleister zu auditieren und an die BaFin zu melden.

Ausgenommen sind im Wesentlichen sehr kleine Institute, die unter die proportionalitäts-Schwellen fallen, sowie einige Einrichtungen der betrieblichen Altersversorgung. Wer unsicher ist, ob DORA greift, prüft am besten den Anhang der Verordnung oder fragt bei der BaFin nach – die Auskunft ist kostenlos und entlastet im Zweifel die eigene Risikobewertung.

ICT-Risikomanagement nach den Art. 5 bis 16 DORA

Das IKT-Risikomanagement ist das Kernstück. Art. 5 bis 16 verlangt ein vollständiges Rahmenwerk: Governance, Risiko­identifikation, Schutzmaßnahmen, Erkennung, Reaktion, Wiederherstellung. Wer das mit dem BAIT-Rahmenwerk vergleicht, wird viele alte Bekannte finden – aber DORA verlangt eine durchgängige Verbindung zwischen IKT-Risikobewertung, Geschäftsfortführung und Drittdienstleister-Management. Die drei Säulen waren vorher nebeneinander dokumentiert; sie müssen jetzt ineinandergreifen.

Konkret heißt das: ein Vorfall bei einem Cloud-Anbieter muss in der eigenen Risikobewertung sofort Auswirkungen auf die Geschäftsfortführung haben. Wer das nicht abbildet, fällt spätestens bei der ersten BaFin-Prüfung auf – nicht weil das Cloud-Risiko neu ist, sondern weil die Querverbindungslücke neu bewertet wird.

In der Mandatspraxis sehe ich, dass Institute die größte Schwierigkeit mit dem „vollständigen“ Charakter des Rahmens haben. Wer BAIT umgesetzt hat, hat eine Teilmenge erfüllt; wer DORA umsetzt, muss den Rest schließen. Das fängt bei der Inventarisierung aller IKT-Vermögenswerte an und hört bei der Schulung aller IKT-relevanten Mitarbeitenden auf. Ein Ein-Sparten-Projekt reicht dafür selten.

ICT-Vorfälle melden: die BaFin-Pflicht

Art. 19 DORA verpflichtet Institute, schwerwiegende ICT-Vorfälle an die BaFin zu melden – und zwar gestaffelt: eine erste Meldung binnen vier Stunden nach Eingruppierung als schwerwiegend, eine Zwischenmeldung binnen 72 Stunden und ein Abschlussbericht binnen eines Monats. Die Frist von vier Stunden klingt kurz – und ist es auch. Wer hier improvisiert, bekommt ein zweites Problem, wenn die BaFin später nachfragt.

Die BaFin hat hierzu im Sommer 2025 ein Hinweispapier veröffentlicht, in dem die Klassifizierung als „schwerwiegend“ konkretisiert wird. Danach ist ein Vorfall schwerwiegend, wenn er eines von mehreren Kriterien erfüllt: Auswirkungen auf kritische Funktionen, finanzieller Schaden über einer bestimmten Schwelle, Datenschutzvorfall mit Meldungspflicht nach DSGVO, oder ein Vorfall bei einem IKT-Drittdienstleister mit Auswirkungen auf das Institut. Die Kriterien sind additiv zu lesen, nicht alternativ.

In der Praxis bedeutet das: wer bereits einen NIS2-Meldeprozess nach § 32 BSIG aufgesetzt hat, kann die Strukturen für DORA teilweise wiederverwenden. Aber die Klassifizierungskriterien sind anders, die BaFin hat ihre eigenen Meldewege, und die Vier-Stunden-Frist beginnt früher als die NIS2-24-Stunden-Frist. Wer die Schnittstellen nicht dokumentiert, zahlt das im Ernstfall doppelt.

Resilienztests: TLPT und Übungen

Art. 24 bis 27 DORA verlangt Resilienztests – in unterschiedlicher Intensität je nach Größe und Risikoprofil des Instituts. Die Königsdisziplin ist der Threat-Led Penetration Test (TLPT) nach Art. 26: alle drei Jahre, von zertifizierten Testern durchgeführt, mit Vorlage der Ergebnisse bei der BaFin. Der TLPT orientiert sich am TIBER-EU-Rahmenwerk der EZB und ist methodisch anspruchsvoll.

Auch kleinere Institute müssen testen – nur eben nicht als TLPT, sondern als skalierte Programme: regelmäßige Schwachstellen­scans, Penetrationstests auf Kernsystemen, Phishing-Simulationen, Krisenstabsübungen. Wer 2026 noch keinen Testkalender hat, fängt nicht bei null an, aber braucht eine Projektwoche.

Was oft unterschätzt wird: die Tests müssen dokumentiert sein. Die BaFin will nicht nur das Ergebnis, sondern auch den Prozess sehen – wer hat getestet, mit welcher Methodik, welche Befunde, welche Maßnahmen, welche Wirksamkeitsprüfung im Folgejahr. Wer das schlank dokumentiert, kann eine Prüfung bestehen; wer das im Sande verlaufen lässt, bekommt Auflagen.

Kritische IKT-Drittdienstleister: das Aufsichtsregime

Art. 30 bis 44 DORA schaffen ein eigenes Aufsichtsregime für „kritische IKT-Drittdienstleister“ – also Anbieter, die kritische Dienste für mehrere Finanzinstitute erbringen. Microsoft, Amazon, Google, SAP, Oracle, die großen Cloud-Provider und einige mehr stehen bereits auf der ersten Liste, die die europäischen Aufsichtsbehörden (ESA) im November 2024 veröffentlicht haben. Die Liste wird regelmäßig aktualisiert.

Was das für ein einzelnes Institut bedeutet: es muss dokumentieren, welche IKT-Drittdienstleister es nutzt, ob einer davon als kritisch eingestuft ist, und welche vertraglichen und operativen Vorkehrungen bestehen. Das fängt bei der Cloud an und hört bei SaaS-Lösungen, Rechenzentrums­anbietern und sogar Telekommunikations­diensten auf.

Vertraglich verlangt Art. 30 unter anderem klare Ausstiegs­regelungen, Audit-Rechte des Instituts (und mittelbar der Aufsicht), Standort- und Notfall­vorschriften. Wer bestehende Verträge nicht anpasst, läuft Gefahr, dass die BaFin bei der nächsten Prüfung genau diese Klauseln einfordert – und zwar rückwirkend für die kritischen Dienstleister. In Konzernen mit langen Vertrags­laufzeiten ist das eine Mammutaufgabe, die 2026 eigentlich laufen sollte.

BaFin-Aufsicht 2026 – erste Erfahrungen

Was die BaFin tatsächlich prüft, lässt sich aus den ersten Aufsichtsschreiben und -gesprächen 2025/2026 herauslesen. Vier Schwerpunkte zeichnen sich ab.

Die Vollständigkeit des IKT-Inventars. Die BaFin will alle IKT-Vermögenswerte sehen, einschließlich der Drittdienstleister-Beziehungen. Wer hier eine Lücke hat, wird gefragt, wie er sein Risiko ohne das fehlende Element bewertet – die Antwort lautet meistens: gar nicht.

Die Belastbarkeit der Resilienztests. Tests werden nicht nur dem Namen nach verlangt, sondern mit konkreten Befunden. Wer den gleichen Befund dreimal in Folge dokumentiert, ohne dass sich etwas ändert, muss erklären, warum.

Die Konsistenz zwischen Anlagemanagement und IKT-Risikomanagement. Wer in seinem Outsourcing-Register eine Cloud-Migration hat, das IKT-Risikomanagement aber nichts davon weiß, fällt negativ auf. Die BaFin will Querverbindungen sehen, nicht isolierte Dokumente.

Die tatsächliche Funktion der Meldemechanismen. Bei einer simulierten oder tatsächlichen Störung will die BaFin sehen, dass die Meldung in der vorgesehenen Zeit und Form bei ihr ankommt. Wer hier nur eine E-Mail-Adresse hinterlegt hat, aber kein getestetes Verfahren, fällt durch.

Bußgelder und aufsichtliche Maßnahmen

DORA kennt kein unmittelbares Bußgeld für die Institute – die Sanktionierung läuft über die nationalen Aufsichtsgesetze (KWG, VAG, KAGB) und über die BaFin, die auf das Instrument der „aufsichtlichen Maßnahme“ zurückgreift. In der Praxis heißt das: Auflagen, Sonderprüfungen, im äußersten Fall die Einschränkung der Geschäftstätigkeit.

Was außerdem greift: die persönliche Haftung der Geschäftsleitung. DORA verlangt explizit, dass die Geschäftsleitung in die IKT-Risikosteuerung eingebunden ist – nach deutschem Recht entspricht das der Compliance- und Risikomanagement-Pflicht nach § 25a KWG. Wer hier Dokumentationslücken hat, dem droht nicht nur ein aufsichtliches Verfahren, sondern auch eine persönliche Inanspruchnahme.

Anders bei den IKT-Drittdienstleistern: hier kann die europäische Aufsicht (ESA) direkte Sanktionen verhängen. Die ESAs haben seit 2025 die Möglichkeit, Auflagen zu verhängen und Bußgelder bis zu einer Million Euro pro Tag bei schwerwiegenden Verstößen zu verhängen. Das ist ein Hebel, der noch nie auf der Tagesordnung war und jetzt Realität wird.

Schnittstelle zu NIS2 und BAIT/VAIT

DORA steht nicht allein. Parallel laufen NIS2 (für die kritische Infrastruktur), BAIT (für Banken) und VAIT (für Versicherer). DORA ersetzt die nationalen Rundschreiben nicht, sondern überlagert sie. Wer heute alle drei Regelwerke parallel betreibt, braucht ein gemeinsames Rahmenwerk – nicht drei separate.

In der Mandatspraxis sieht das so aus: ein IKT-Risikomanagement-Rahmenwerk, das DORA vollständig abdeckt, ist die Basis. BAIT/VAIT werden darin als nationale Spezifizierungen abgebildet. NIS2 wird als zusätzliche Schicht für die Sektoren Energie, Gesundheit oder Verkehr integriert. Wer die Dokumente parallel führt, hat bei jeder Prüfung drei Mal den Aufwand.

Wer seine NIS2-Meldung nach § 32 BSIG bereits aufgesetzt hat, kann Teile davon für DORA wiederverwenden – die Vorfalls­definition ist ähnlich, die Meldestruktur ist ähnlich, die Klassifizierungs­schwellen sind ähnlich. Aber die BaFin-Meldung läuft über das BaFin-Melde- und Informationsportal (MIP), nicht über das BSI-Portal. Wer beide Verfahren aus einer Hand steuert, spart sich Doppelarbeit; wer sie getrennt führt, riskiert Widersprüche.

Konkrete To-Do-Liste für 2026

Wer in der zweiten Jahreshälfte 2026 noch nachziehen muss, kann mit folgenden sechs Bausteinen anfangen – pragmatisch, nicht als Compliance-Theater.

Das IKT-Inventar abschließen. Alle Vermögenswerte, alle Dienstleister, alle Standorte, alle Datenflüsse. Wer hier eine Lücke hat, kann die anderen Bausteine nicht sauber darauf aufbauen.

Das Drittdienstleister-Register aufbauen. Mit Verträgen, Klassifizierungen, Audit-Rechten, Ausstiegsszenarien. Kritische IKT-Drittdienstleister müssen gesondert ausgewiesen sein.

Den Vorfallsprozess durchspielen. Nicht nur die Meldung an die BaFin, sondern auch die interne Eskalation, die Klassifizierung und die Übergabe an die Aufsicht. Wer noch keinen Test gemacht hat, plant eine Übung für Q3/Q4 2026.

Die Resilienztests organisieren. Auch wenn kein TLPT verlangt wird, will die BaFin einen Testkalender sehen. Wer 2026 keinen Test hat, sollte 2027 planen.

Das IKT-Risikomanagement mit der Geschäftsleitung verzahnen. Quartalsberichte an die Geschäftsleitung, dokumentierte Entscheidungen, dokumentierte Schulungs­teilnahmen.

Die Schnittstellen zu NIS2 und BAIT/VAIT dokumentieren. Wer alle drei Regelwerke führt, ohne die Querverbindungen zu zeigen, fällt bei jeder Prüfung auf. Ein gemeinsames Rahmenwerk spart vieles.

Einordnung: DORA im Compliance-Puzzle

DORA reiht sich ein in eine ganze Generation europäischer Digitalregulierung: neben der KI-Verordnung (KI-VO), der NIS2-Umsetzung und dem Data Act ist DORA der Baustein, der speziell für den Finanzsektor die operative Resilienz regelt. Wer DORA sauber aufgesetzt hat, hat methodisch vieles gewonnen – einen klareren Blick auf Drittdienstleister, einen besseren Vorfalls­prozess, einen ernsthafteren Resilienztest.

Wer parallel von der KI-Verordnung betroffen ist, sollte die Schnittstellen prüfen: DORA verlangt IKT-Risikomanagement für alle IKT-Systeme, einschließlich KI-gestützter Entscheidungs­systeme. Wer ein KI-System für Kreditentscheidungen einsetzt, muss dessen Ausfallverhalten im Resilienzrahmen abbilden. Für Krypto-Dienstleister im MiCA-Sinne und für PSPs im PSR-Sinne gilt das erst recht – auch GwG-Verpflichtungen laufen parallel.

Und für die kommenden zwei Jahre ist absehbar, dass die BaFin ihre Aufsicht weiter verschärft. Die nächsten europäischen Updates zu DORA, die technischen Regulierungs- und Implementierungsstandards (RTS/ITS), die laufenden ESA-Aufsichts­verfahren gegen kritische IKT-Drittdienstleister – all das wird den Compliance-Aufwand weiter erhöhen. Wer 2026 die Grundlagen schafft, kommt mit den nächsten Wellen besser zurecht.

Fazit

DORA ist seit über einem Jahr anwendbar, aber die Aufsicht beginnt gerade erst, die Anwendung ernsthaft zu prüfen. Wer jetzt noch auf das alte BAIT-Silo setzt, wird sich wundern, wenn die BaFin-Pflichten über das eigene Rahmenwerk hinausgehen.

Sechs Bausteine entscheiden 2026: vollständiges IKT-Inventar, dokumentiertes Drittdienstleister-Management, getesteter Vorfallsprozess, Resilienztests auf der Tagesordnung, verzahnte Geschäftsleitung, dokumentierte Schnittstellen zu NIS2 und BAIT/VAIT. Wer das hat, ist nicht fertig – aber gut aufgestellt. Wer das im August 2026 nicht hat, kann es mit einer Projektphase bis Jahresende schaffen. Wer es Anfang 2027 nicht hat, fängt an, in den Aufsichtsräten unangenehme Fragen zu beantworten.