Ein Jahr Papier reicht der Aufsicht nicht mehr

Die Ordner sind voll. Die Register sind eingereicht. Trotzdem beginnt die schwierigste Phase erst jetzt. Mehr als ein Jahr nach dem DORA-Geltungsbeginn steht bei den meisten Finanzinstituten die Grundstruktur: Register sind übermittelt, Meldeprozesse laufen und das IKT-Risikomanagement ist dokumentiert, doch die eigentliche Bewährungsprobe bei Third-Party-Risk und Resilienz-Testing steht noch aus.

Der Digital Operational Resilience Act, die Verordnung (EU) 2022/2554, gilt seit dem 17. Januar 2025 unmittelbar für Finanzunternehmen. Laut der Aufsichtspraxis gab es dafür keine Schon- und keine Übergangsfrist. Wer die Frist verpasst hat, arbeitet seither strukturell im Rückstand und unter aufsichtlicher Beobachtung.

Warum das erste Jahr kein Abschluss war

Das erste Umsetzungsjahr diente dem Aufbau. Institute haben Zuständigkeiten geordnet, Register befüllt und Prozesse definiert. Diese Arbeit war notwendig, sie ist aber kein Nachweis operativer Belastbarkeit.

Die BaFin behandelt das erste Jahr faktisch als Übergangsphase mit Aufbaucharakter. Die verschärfte Prüfung der Wirksamkeit beginnt danach. Genau hier trennt sich formale Konformität von echter Resilienz.

Der Anspruch der Verordnung ist operationale Resilienz statt reiner Regeltreue. Nicht die Struktur allein zählt, sondern Routine und Belastbarkeit im Tagesgeschäft. Diese Verschiebung entscheidet, wie die Aufsicht die kommenden Jahre bewertet.

Das Register der IKT-Drittdienstleister als erste harte Prüfung

Das Informationsregister dokumentiert sämtliche Verträge mit IKT-Drittdienstleistern und deren Unterauftragnehmer für kritische oder wichtige Funktionen. Es ist das schärfste Instrument der Aufsicht, weil es die Abhängigkeiten eines Instituts offenlegt.

Die erste Einreichung lief nach BaFin-Vorgabe vom 14. bis 28. April 2025 mit Stichtag 31. März 2025. Ab 2026 wiederholt sich die Meldung jährlich im Fenster vom 9. bis 30. März mit Stichtag 31. Dezember des Vorjahres. Die BaFin leitet die Register bis Ende März an die Europäischen Aufsichtsbehörden weiter.

Übermittelt wird ausschließlich als strukturierte xBRL-Datei nach ESA-Taxonomie oder über die Excel-Vorlage der BaFin. Der Versand läuft über das MVP-Portal der BaFin. Wer hier lückenhaft meldet, liefert der Aufsicht eine Landkarte der eigenen Schwachstellen.

Neben der jährlichen Meldung greift eine laufende Anzeigepflicht. Institute informieren die Aufsicht zeitnah über jede geplante vertragliche Vereinbarung, die kritische oder wichtige Funktionen stützt. Das Register ist damit kein Jahresabschluss, sondern ein lebendes Verzeichnis.

Wo stehen Banken bei der DORA Umsetzung wirklich?

Die Grundpflichten sind bei den meisten Häusern erfüllt. Register liegen vor, das Meldewesen ist angeschlossen, Governance-Strukturen sind besetzt. Auf dem Papier ist DORA umgesetzt.

In der Praxis klaffen zwei Lücken: das Management von Drittparteirisiken und der Nachweis, dass die eigenen Prozesse unter Last funktionieren. Beide Themen lassen sich nicht durch Dokumentation lösen. Sie entscheiden über die Bewertung der kommenden Prüfungen.

Der Reifegrad streut dabei stark. Große Häuser mit eigenen Resilienz-Teams sind weiter als kleinere Institute, die DORA neben dem Tagesgeschäft stemmen. Der Mittelstand kämpft besonders mit dem Vertrags- und Drittparteithema, weil ihm die Verhandlungsmacht und die Ressourcen für ein automatisiertes Lieferantenmanagement fehlen.

IKT-Risikomanagement: von der Konzeptexistenz zur Wirksamkeit

DORA verlangt ein Risikomanagement für die gesamte IKT-Landschaft, von der Identifikation kritischer Funktionen bis zur Wiederherstellung nach einem Ausfall. Viele Institute haben dafür Rahmenwerke geschrieben und Verantwortliche benannt.

Der aufsichtliche Blick verschiebt sich jetzt von der Existenz der Konzepte auf deren Wirksamkeit. Entscheidend sind Ergebnisse, abgeleitete Maßnahmen und deren konsequente Umsetzung. Ein sauber dokumentierter Prozess, der im Ernstfall nicht greift, gilt der Aufsicht als Mangel.

Das verlangt eine klare Verbindung zwischen Risikoanalyse und Geschäftsauswirkung. Institute müssen ihre kritischen Funktionen kennen, deren zulässige Ausfallzeiten definieren und die Wiederanlaufpläne belegbar erproben. Erst diese Kette macht aus einem Rahmenwerk ein steuerndes Instrument.

Das Vorfallmeldewesen und die Vier-Stunden-Regel

DORA schreibt ein dreistufiges Meldeverfahren für schwerwiegende IKT-Vorfälle vor. Die Erstmeldung erfolgt spätestens vier Stunden nach der Einstufung als schwerwiegend, längstens 24 Stunden nach Entdeckung des Vorfalls.

Die Zwischenmeldung folgt spätestens 72 Stunden nach der Erstmeldung. Die Abschlussmeldung mit Ursachenanalyse und ergriffenen Maßnahmen ist einen Monat nach der letzten Zwischenmeldung fällig. Als schwerwiegend gilt ein Vorfall unter anderem bei wirtschaftlichen Auswirkungen über 100.000 Euro oder einer Ausfallzeit über zwei Stunden.

Diese Taktung stellt hohe Anforderungen an die interne Erkennung und Eskalation. Wer einen Vorfall erst nach Stunden als schwerwiegend erkennt, hat die Erstmeldefrist bereits verloren.

Der Engpass liegt selten im Meldeformular, sondern in der Klassifizierung. Ihre Fachbereiche müssen die DORA-Schwellenwerte kennen und einen Vorfall unter Zeitdruck korrekt einordnen. Ein eingespielter Eskalationsweg zwischen IT, Risiko und Meldewesen entscheidet darüber, ob die vier Stunden reichen. Diesen Weg trainieren Institute am besten, bevor der Ernstfall ihn erzwingt.

Was die über 600 gemeldeten Vorfälle wirklich zeigen

Laut Berichten aus der Fachpresse hat die BaFin seit Januar 2025 über 600 schwerwiegende IKT-Vorfälle registriert. Die Zahl klingt dramatisch, sie ist aber vor allem Ausdruck von Cluster-Effekten: ein Vorfall bei einem großen Dienstleister, viele betroffene Institute.

Genau darin liegt die eigentliche Botschaft. Die Konzentration auf wenige zentrale Anbieter macht aus einer einzelnen Störung ein sektorweites Ereignis. Das Meldewesen liefert der Aufsicht damit erstmals eine belastbare Sicht auf systemische Abhängigkeiten.

Für einzelne Institute zählt weniger die Gesamtzahl als die eigene Reaktionsfähigkeit. Die Frage lautet nicht, ob ein Vorfall eintritt, sondern ob Sie ihn rechtzeitig als schwerwiegend erkennen und fristgerecht melden. Genau das prüft die Aufsicht in der Rückschau.

Threat-Led Penetration Testing: die unterschätzte Baustelle

Threat-Led Penetration Testing, kurz TLPT, ist der bedrohungsorientierte Penetrationstest unter DORA. Er simuliert reale Angreifer gegen die produktiven Systeme eines Instituts und prüft, ob Erkennung und Reaktion tatsächlich funktionieren.

TLPT trifft nach Artikel 26 der Verordnung nicht alle Häuser. Die BaFin ordnet erweiterte Tests nur für eine kleine Anzahl an Finanzunternehmen per Verpflichtungsbescheid an, ausgewählt nach Systemrelevanz, Finanzstabilität und IKT-Risikoprofil. Betroffene Institute testen in einem mehrjährigen Turnus.

Der Aufwand ist erheblich. Ein solcher Test bindet über Monate Ressourcen und legt offen, ob definierte Eskalationsmechanismen greifen oder nur beschrieben sind. Hier zeigt sich, ob Resilienz Routine ist oder nur Aktenlage.

TIBER-DE und der regulatorische Rahmen für TLPT

Die Methodik für TLPT orientiert sich am TIBER-EU-Rahmenwerk der Europäischen Zentralbank und am TIBER-DE-Prozess der Deutschen Bundesbank. Die technischen Vorgaben regelt die Delegierte Verordnung (EU) 2025/1190.

Die operative Begleitung der Tests liegt bei der Deutschen Bundesbank, die aufsichtliche Anordnung und Validierung bei der BaFin. Institute, die einen Bescheid erwarten, bereiten Testszenarien, interne Teams und die Einbindung von Dienstleistern besser vor der Anordnung vor.

Die Auswahl folgt wirkungsbezogenen Kriterien: der Bedeutung für den Finanzsektor, Finanzstabilitätsbedenken und dem technologischen Reifegrad. Ein Haus, das seine Systemrelevanz kennt, sollte einen TLPT nicht als Überraschung behandeln, sondern als planbaren Bestandteil seiner Teststrategie.

Third-Party-Risk: die Abhängigkeit lässt sich nicht auslagern

Das Management von Drittparteirisiken bleibt die größte offene Baustelle. Laut Fachpresse stammen rund 75 Prozent der kritischen Auslagerungsdienstleister aus Drittstaaten, überwiegend aus den USA. Diese strukturelle Abhängigkeit verschwindet nicht dadurch, dass sie in einem Register steht.

In vielen Häusern fehlen automatisierte Prozesse für das Lieferantenmanagement und eine enge Verzahnung von IT, Einkauf und Operational Risk. Die Folge sind fragmentierte Abläufe, Medienbrüche und keine durchgehende Sicht auf die eigenen Risiken. Wer seine Dienstleister nur in einer Tabelle führt, steuert sie nicht.

Ein Teil dieser Abhängigkeit entsteht neu über den Einsatz von KI-Diensten und deren Vorlieferanten. Wer diese Risiken steuern will, braucht klare KI-Governance und Kontrolle über Agentic-AI-Anwendungen, bevor sie in kritische Prozesse einziehen.

Die Vertrags-Baustelle: oft mehr als tausend Verträge pro Haus

DORA verlangt bestimmte Mindestinhalte in jedem IKT-Vertrag für kritische oder wichtige Funktionen. Nach Einschätzung von Deloitte Legal verwalten Institute dafür häufig mehr als tausend Verträge pro Haus, die geprüft und nachverhandelt werden müssen.

Die BaFin stellt fest, dass Ende 2025 noch nicht alle Verträge an DORA angepasst waren. Wo die Konformität fehlt, erwartet die Aufsicht zumindest einen belastbaren, risikoorientierten Zeitplan. Bloßes Aussitzen ist keine Option, weil die Nachverhandlung mit marktmächtigen Anbietern Zeit kostet.

Die Verhandlungsmacht liegt dabei selten beim Institut. Große Cloud- und Softwareanbieter setzen Standardklauseln, die den DORA-Mindestinhalten nicht ohne Weiteres genügen. Priorisieren Sie deshalb die Verträge für die kritischen Funktionen und führen Sie den Rest in einer geordneten Reihenfolge nach.

Der Aufsichtsfokus der BaFin verschiebt sich

Die BaFin macht deutlich, dass sie das Ziel in operativer Resilienz sieht, nicht in reiner Compliance. Geprüft wird nicht mehr, ob ein Konzept vorliegt, sondern ob es wirkt.

Die BaFin benennt das Risikomanagement von IKT-Drittparteien und das Vorfallmeldewesen als Schwerpunkte mit Nachholbedarf. Institute, die hier nur Struktur ohne belegte Wirksamkeit vorweisen, gehen in die kommenden Prüfungen mit einer Schwachstelle.

DORA und NIS2: klare Abgrenzung, keine Doppelarbeit

DORA ist eine unmittelbar geltende Verordnung, NIS2 eine Richtlinie, deren deutsche Umsetzung seit Dezember 2025 greift. Für Finanzunternehmen gilt DORA als lex specialis und hat Vorrang. Das deutsche NIS2-Umsetzungsgesetz stellt diesen Vorrang für die von DORA erfassten Häuser ausdrücklich klar.

Das entlastet Institute von einer doppelten Regulierung, es entbindet sie aber nicht von der Prüfung möglicher Lücken. Wo NIS2-Themen über den DORA-Rahmen hinausreichen, ist eine bewusste Entscheidung nötig, ob ergänzende Maßnahmen greifen.

Die aufgehobenen Rundschreiben und die Rolle der BAIT

Mit dem Geltungsbeginn hat die BaFin ihre bisherigen IT-Rundschreiben für den DORA-Anwendungsbereich abgelöst. Aufgehoben wurden zum 17. Januar 2025 die KAIT für Kapitalverwaltungsgesellschaften, die VAIT für Versicherer und die ZAIT für Zahlungsdienstleister.

Die BAIT für Banken gilt übergangsweise bis zum 31. Dezember 2026 fort, allerdings nur für Institute, die DORA nicht unmittelbar anwenden. Für alle anderen Häuser tritt der DORA-Rahmen an die Stelle der vertrauten Rundschreiben. Wer seine interne Steuerung noch an der alten Systematik ausrichtet, arbeitet an der geltenden Rechtslage vorbei.

Konzentrationsrisiko und der wachsende Schatten der KI

Die Abhängigkeit von wenigen zentralen Anbietern ist das strukturelle Kernproblem hinter DORA. Sie lässt sich auch unter europäischer Aufsicht nicht auflösen, nur transparenter machen und steuern.

Mit dem breiten Einsatz von KI wächst dieses Risiko weiter, oft an der offiziellen IKT-Governance vorbei. Unkontrollierte Anwendungen im Haus schaffen neue Datenrisiken und Abhängigkeiten. Wer Schatten-KI in Banken und Sparkassen nicht früh sichtbar macht, unterläuft die eigene DORA-Struktur.

Was Vorstände und Bereichsleiter jetzt entscheiden müssen

Die Handlungslinie ist klar. Verlagern Sie den Fokus von der Dokumentation auf den Nachweis der Wirksamkeit. Testen Sie Erkennung und Eskalation, bevor es ein realer Vorfall oder eine Prüfung tut.

Ordnen Sie das Management der Drittparteirisiken neu: automatisierte Prozesse, eine durchgehende Sicht über IT, Einkauf und Operational Risk und ein realistischer Zeitplan für die Vertragsanpassung. Behandeln Sie das Informationsregister als Steuerungsinstrument, nicht als Meldepflicht.

Verankern Sie die Verantwortung im Vorstand, nicht nur in der IT. DORA ist eine Governance-Anforderung, deren Wirksamkeit die Leitungsebene gegenüber der Aufsicht nachweisen muss. Ein jährlicher Testzyklus, ein gepflegtes Register und dokumentierte Lehren aus realen Vorfällen bilden dafür das belastbare Fundament.

DORA ist kein Projekt mit Enddatum, sondern der Dauerbetrieb operativer Belastbarkeit. Die Institute, die das früh verstanden haben, verschaffen sich einen Vorsprung, den die Nachzügler teuer nachholen.

Ihr nächster Schritt mit Sotica

Sie wollen wissen, wo Ihr Haus zwischen formaler Konformität und echter Resilienz steht. In einer Potenzialanalyse ordnen wir Ihren Umsetzungsstand entlang der DORA-Anforderungen ein und zeigen die Lücken, die in der nächsten Prüfung teuer werden.

Sotica ist Ihr Partner für Wandel in der Finanzbranche. Wir verbinden regulatorische Tiefe mit dem Blick des Praktikers und machen aus Anforderungen konkrete nächste Schritte. Vereinbaren Sie eine Potenzialanalyse oder eine KI-Sprechstunde und übersetzen Sie Regulatorik in belastbare Handlungsfähigkeit.