Eineinhalb Jahre nach dem Anwendungsstichtag hat rund die Hälfte der betroffenen Finanzunternehmen keine vollständige DORA-Compliance erreicht. Die BaFin beginnt 2026 mit systematischen Prüfungen und erwartet dabei nicht nur ein dokumentiertes IKT-Risikomanagement, sondern nachweislich funktionsfähige Prozesse. Was die Umsetzungspraxis im Finanzsektor dabei zeigt, ist auch für Unternehmen außerhalb relevant: DORA definiert präziser als jede andere aktuelle Regulierung, was operationale Resilienz strukturell erfordert.
Was DORA vom Finanzsektor verlangt
DORA ist keine IT-Verordnung. Das ist der Kernsatz, der in nahezu jeder ernsthaften Analyse auftaucht – und trotzdem in der Umsetzungspraxis regelmäßig ignoriert wird. Der Digital Operational Resilience Act verpflichtet über 22.000 Finanzunternehmen in der EU zu einem einheitlichen DORA ICT-Risikomanagement in fünf Säulen, die gleichzeitig stehen müssen:
ICT-Risikomanagement Umfassendes Framework mit Vorstandsverantwortung, dokumentierter Risikobereitschaft und kontinuierlichem Monitoring aller IKT-Assets und Abhängigkeiten. BAIT und VAIT werden bis Ende 2026 vollständig durch DORA abgelöst.
Incident Management Klassifizierung, Meldepflicht und Berichterstattung – einschließlich der 4-Stunden-Erstmeldung an die BaFin für schwerwiegende IKT-Vorfälle. Dokumentierte Meldekette als Audit-Nachweis.
Resilienztests Jährliche Resilienztests für alle Institute. Systemrelevante Häuser müssen alle drei Jahre Threat-led Penetration Testing (TLPT) durchführen – mit externen Testern nach TIBER-EU-Standard.
Drittparteienrisiko Vollständiges Register aller IKT-Dienstleister mit Kritikalitätsklassifizierung, vertraglichen Mindestklauseln nach Art. 30, Exit-Strategien und laufendem Monitoring. Die offizielle Meldefrist an die BaFin war März 2026. Wer das Register bis heute nur als Excel-Liste führt, gerät bei den jetzt startenden systematischen Prüfungen der Aufsicht unter akuten Rechtfertigungsdruck.
Informationsaustausch Vereinbarungen zum Austausch von Bedrohungsinformationen zwischen Finanzunternehmen – freiwillig, aber regulatorisch anerkannt als Beitrag zur systemischen Resilienz.
Wo die größten Lücken liegen
Das Drittanbieterregister ist die Achillesferse. 46 Prozent der Institute nennen es als ihre größte Compliance-Hürde – nicht weil die Anforderung unklar wäre, sondern weil die operative Komplexität unterschätzt wurde. Jeder IKT-Dienstleister muss erfasst, klassifiziert und auf Kritikalität bewertet werden. Für kritische Anbieter gelten verschärfte Anforderungen: Audit-Rechte, Subunternehmer-Transparenz, Verfügbarkeits-SLAs und ein dokumentierter Exit-Plan.
Seit November 2025 gibt es eine erste offizielle Liste kritischer IKT-Drittdienstleister (CTPPs) auf europäischer Ebene – 19 Unternehmen, darunter die großen Hyperscaler. Finanzunternehmen, die diese Anbieter nutzen, stehen damit unter direkter ESA-Beobachtung: Wie viele Institute hängen am selben kritischen Anbieter? Was passiert beim Ausfall? Die Antwort auf diese Fragen muss nicht nur strategisch vorhanden, sondern dokumentiert und testbar sein.
TLPT – die unterschätzte Anforderung
Threat-led Penetration Testing nach TIBER-EU erfordert spezialisierte externe Tester, einen vorlaufintensiven Scope-Prozess und interne Vorbereitung über Monate. Institute, die erst 2026 mit der Planung beginnen, stoßen auf Kapazitätsengpässe bei externen Testern. Für DORA-pflichtige Institute bedeutet das: TLPT-Rahmenverträge jetzt abschließen, auch wenn das Testing erst 2027 stattfindet.
Was DORA besser macht als NIS-2
NIS-2 ist eine Richtlinie mit nationalem Umsetzungsspielraum – DORA ist eine Verordnung, die unmittelbar gilt. NIS-2 schreibt Maßnahmen vor, DORA schreibt Nachweisbarkeit vor. Der Unterschied ist erheblich: Ein Unternehmen, das eine Backup-Lösung hat, erfüllt NIS-2 möglicherweise bereits. DORA verlangt zusätzlich den dokumentierten Restore-Test, den RTO-Nachweis und den Prüfbericht für den Auditor.
Dieser Unterschied zwischen Maßnahme und nachweisbarer Wirksamkeit ist das strukturelle Kernprinzip, das DORA von früheren Regulierungsansätzen unterscheidet. Es ist dasselbe Prinzip, das im BAM-Objektmodell als Evidence-Feld verankert ist: Nicht die implementierte Kontrolle zählt, sondern der Nachweis ihrer Funktion zu einem bestimmten Zeitpunkt. Der Evidence-Begriff im Compliance-Lexikon beschreibt das im Detail.
Was alle von DORA lernen können
Die fünf DORA-Säulen sind kein Finanzsektor-Spezifikum. Sie sind die Antwort auf eine Frage, die sich jedes Unternehmen mit wesentlicher IKT-Abhängigkeit stellen sollte: Was passiert, wenn ein kritisches System ausfällt, ein Drittanbieter nicht mehr verfügbar ist oder ein Angriff die operative Grundlage trifft?
Unternehmen außerhalb des Finanzsektors – Industrieunternehmen, Dienstleister, Gesundheitsversorger – haben für diese Frage keine regulatorisch erzwungene Antwortstruktur. NIS-2 schreibt Maßnahmen vor, aber keine systematische Drittanbieter-Klassifizierung mit Exit-Strategien. DORA tut das. Wer die DORA-Säulenstruktur freiwillig auf das eigene IKT-Risikomanagement überträgt, hat damit einen Rahmen, der belastbarer ist als die meisten internen IT-Sicherheitskonzepte – und der gleichzeitig NIS-2-Anforderungen vollständig abdeckt.
BAM DORA-Objekte für die strukturierte Umsetzung
Das BAM-Objektmodell bildet alle fünf Säulen als strukturierte Objekte ab – mit Gap-Check, Remediation-Feldern und Evidence-Anforderungen pro Kontrolle. Wer den DORA-Stresstest für das eigene Unternehmen durchführen möchte, findet den Einstieg unter brain-media.de/compliance_stresstest.
DORA Praxisfrage · ICT-Risikomanagement
Ein Finanzunternehmen nutzt für seinen Kernbankbetrieb einen Cloud-Anbieter, der auf der CTPP-Liste der ESAs steht. Was ist die unmittelbar wichtigste DORA-Pflicht?
Enterprise-Setup · DORA ICT-Risikomanagement
Wo stehen Sie in den fünf DORA-Säulen?
20-minütiges Setup-Gespräch – GAP-Analyse gegen alle fünf Säulen, BAM-Objekte als Arbeitsgrundlage, konkrete nächste Schritte.