DORA-Regulierung 2026: Vom Compliance-Papier zum Echtzeit-Nachweis

Was ist DORA — und warum 2026 das entscheidende Jahr ist

Der Digital Operational Resilience Act (DORA, Verordnung EU 2022/2554) ist die EU-Verordnung, die die digitale operative Widerstandsfähigkeit des gesamten Finanzsektors harmonisiert. Anders als eine Richtlinie wirkt eine Verordnung unmittelbar in allen Mitgliedstaaten — es gibt keinen nationalen Umsetzungsspielraum, keine länderspezifischen Verzögerungen und keine Diskussion über die Auslegung des Geltungsbereichs. DORA gilt seit dem 17. Januar 2025 verbindlich.

Der Geltungsbereich ist bewusst breit gefasst. Erfasst sind Banken, Versicherer, Wertpapierfirmen, Zahlungsdienstleister, Krypto-Asset-Dienstleister, Handelsplätze, zentrale Gegenparteien — und, was viele unterschätzen, deren kritische IKT-Drittdienstleister. Ein Cloud-Anbieter, ein Rechenzentrumsbetreiber oder ein spezialisierter Software-Lieferant, der für eine systemrelevante Bank arbeitet, fällt indirekt in den Wirkungsbereich von DORA, weil die beaufsichtigte Finanzentität vertraglich und nachweislich Kontrolle über diese Lieferkette ausüben muss.

Das Jahr 2025 war faktisch ein Übergangsjahr. Die Aufsichtsbehörden nutzten die ersten Monate, um Meldewege, technische Standards und das Register of Information operativ aufzusetzen, statt sofort hart zu sanktionieren. Diese Schonfrist endet. 2026 ist das Jahr, in dem die Aufsicht von der Aufbau- in die Durchsetzungsphase wechselt: vollständige Register-Einreichungen, strukturierte Vorfallmeldungen, threat-led Penetration Testing und vor allem die aktive Prüfung, ob die dokumentierten Kontrollen in der Realität auch wirken.

Die Datenlage ist eindeutig und unangenehm. Laut Erhebungen, die The Next Web unter Berufung auf Analysen von McKinsey und Deloitte zusammenfasst, war zum Anwendungsstichtag nur rund ein Drittel der EU-Finanzinstitute fristgerecht vollständig compliant. SANS und ISACA bestätigen in ihren Praxisanalysen denselben Befund: Der Reifegrad ist breit gestreut, und ein erheblicher Teil des Sektors verwechselt vorhandene Dokumentation mit nachweisbarer Resilienz. Genau diese Lücke wird 2026 teuer.

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

DORA strukturiert operative Resilienz in fünf miteinander verzahnten Pflichtbereichen. Sie sind nicht als Reihenfolge zu verstehen, sondern als gleichzeitig wirksame Anforderungen, die sich gegenseitig stützen. Wer eine Säule isoliert betrachtet, produziert genau jene Insellösungen, die die Aufsicht 2026 als Schwachstelle identifiziert.

Das Register of Information: Der Lackmustest 2026

Das Register of Information (RoI) ist die sichtbarste und am härtesten kontrollierte Einzelpflicht aus DORA. Es ist ein strukturiertes, maschinenlesbares Verzeichnis aller vertraglichen Vereinbarungen über IKT-Dienstleistungen mit Drittparteien — auf Entitäts-, Sub-Konsolidierungs- und Konsolidierungsebene. Es ist kein PDF und keine Word-Tabelle, sondern ein Datensatz nach einem von den europäischen Aufsichtsbehörden vorgegebenen technischen Standard.

Der praktisch relevante Stichtag war der 31. Dezember 2025: Bis zu diesem Datum mussten Finanzunternehmen ihr Register in der vorgeschriebenen Struktur erstellt und für die Einreichung bei der zuständigen nationalen Aufsicht bereitgestellt haben. 2026 ist das erste Jahr, in dem diese Register tatsächlich aggregiert, validiert und auf Inkonsistenzen geprüft werden.

Die Erfahrung aus der Vorbereitung zeigt ein wiederkehrendes Muster: Das Problem ist selten der Wille, sondern die Datenqualität. Vertragsdaten liegen verteilt in Procurement-Systemen, Legal-Ablagen und Fachbereichs-Excel-Listen. Lieferantenidentifikatoren (insbesondere der LEI-Code) fehlen oder sind veraltet. Sub-Outsourcing-Ketten sind nicht durchgängig erfasst. Genau diese Inkonsistenzen sind für eine automatisierte Validierung trivial auffindbar — und werden 2026 als Erstes adressiert.

Sanktionen: Warum 2 Prozent und 1 Million Euro die Logik verändern

DORA gibt den nationalen Aufsichtsbehörden einen scharfen Sanktionsrahmen. Der zentrale Hebel ist die umsatzbezogene Geldbuße: Verstöße können mit Bußgeldern von bis zu 2 % des weltweiten jährlichen Gesamtumsatzes des Unternehmens geahndet werden. Für eine mittelgroße Finanzentität bewegt sich das schnell im zweistelligen Millionenbereich — eine Größenordnung, die jede Diskussion über Remediation-Budgets sofort beendet.

Entscheidender als die Unternehmensbuße ist jedoch die persönliche Haftung. Für natürliche Personen — also Mitglieder des Leitungsorgans und verantwortliche Führungskräfte — sieht der Rahmen Geldbußen von bis zu 1 Mio. € vor. Damit ändert DORA die Anreizlogik fundamental: Operative Resilienz ist keine Frage mehr, die das Leitungsorgan an die IT delegieren kann, ohne selbst im Risiko zu stehen. Die nicht-delegierbare Verantwortung des IKT-Risikomanagement-Rahmens und die persönliche Sanktionierbarkeit greifen hier bewusst ineinander.

Neben Geldbußen verfügen die Aufsichtsbehörden über ein abgestuftes Instrumentarium: öffentliche Bekanntmachung des Verstoßes (mit dem entsprechenden Reputationsschaden), Anordnungen zur Beendigung des Verhaltens, Aufforderungen zur Vorlage von Nachweisen und im Extremfall Einschränkungen der Geschäftstätigkeit. Die öffentliche Bekanntmachung wird von vielen Häusern als das eigentliche Schreckgespenst bewertet, weil sie unmittelbar auf das Vertrauen von Kunden und Gegenparteien wirkt.

DORA, NIS2 und das NIST-CSF-2.0-Assessment einordnen

In der Praxis entsteht regelmäßig Verwirrung über das Verhältnis von DORA zur NIS2-Richtlinie. Beide adressieren Cyber- und Resilienzanforderungen, aber sie sind nicht austauschbar. DORA ist eine sektorspezifische Verordnung mit unmittelbarer Wirkung und detailliertem, technisch standardisiertem Pflichtenkatalog für den Finanzsektor. NIS2 ist eine breite, sektorübergreifende Richtlinie, die in nationales Recht umgesetzt werden muss und einen größeren Kreis kritischer Branchen erfasst.

Für den Finanzsektor gilt der Grundsatz der Spezialität: Wo DORA greift, ist es das maßgebliche, vorrangige Regelwerk für die IKT-Resilienz. SANS und ISACA arbeiten in ihren Whitepapern genau diese Abgrenzung heraus und betonen, dass Finanzunternehmen nicht zwischen den beiden Regimen wählen, sondern DORA als das anwendbare Spezialrecht behandeln müssen. Eine vertiefte Gegenüberstellung der beiden Resilienzregime — wann welche Pflicht greift und wo sich die Anforderungen überlagern — behandeln wir gesondert in unserem DORA-vs-NIS2-Vergleich.

Methodisch lohnt der Brückenschlag zum NIST Cybersecurity Framework 2.0. Dessen sechs Kernfunktionen — insbesondere GOVERN, IDENTIFY, RESPOND und RECOVER — bilden einen großen Teil der DORA-IKT-Anforderungen strukturiert ab. Wie in unserem NIST-CSF-2.0-Assessment-Leitfaden beschrieben, lässt sich ein vorhandenes CSF-Profil als methodisches Fundament nutzen, auf dem die finanzsektorspezifischen DORA-Nachweise gezielt ergänzt werden — statt zwei parallele Compliance-Apparate redundant zu betreiben.

Vom Papier zum Nachweis: Was sich operativ ändern muss

Der zentrale Reifesprung, den 2026 verlangt, ist der Übergang von dokumentierter zu nachgewiesener Resilienz. Eine Richtlinie, die beschreibt, dass Vorfälle innerhalb definierter Fristen gemeldet werden, hat keinen Wert, wenn der Prozess bei einem realen Vorfall die Frist reißt. Die Aufsicht prüft 2026 zunehmend Evidenz: Logs, Tickets, Testprotokolle, Zeitstempel von Meldungen, validierte Register-Datensätze.

Drei strukturelle Verschiebungen sind dafür notwendig — und sie sind allesamt Delivery-Aufgaben, keine reinen Compliance-Themen.

1. 1Vom statischen Dokument zum lebenden Datensatz: Das Register of Information darf keine jährlich manuell gepflegte Tabelle sein. Es muss als datengetriebenes Artefakt geführt werden, das aus den führenden Systemen (Vertragsmanagement, Lieferantenstammdaten, CMDB) gespeist und kontinuierlich validiert wird — inklusive automatischer Plausibilitätsprüfungen auf LEI-Codes, Kritikalitätsklassifizierung und Sub-Outsourcing-Vollständigkeit.
2. 2Vom manuellen Reporting zur instrumentierten Erkennung: Die Vorfall-Meldefristen sind nur einhaltbar, wenn Erkennung und Klassifizierung instrumentiert sind. Das bedeutet automatisierte Schwellenwert-Alarmierung, eine vordefinierte Klassifizierungslogik und einen Eskalationspfad, der ohne Suchen nach Zuständigen funktioniert. Der Meldeprozess muss geübt sein, nicht nur dokumentiert.
3. 3Vom Audit-Event zur Dauerkontrolle: Resilienz-Testing darf kein jährliches Projekt sein, das einen Bericht produziert. Schwachstellenbewertung, Szenario-Tests und die Nachverfolgung von Remediations gehören in den kontinuierlichen Delivery-Zyklus integriert — mit klaren Ownern, Fristen und einer prüfbaren Schließungslogik für jeden Befund.
4. 4Vom Lieferanten-Bauchgefühl zur vertraglichen Durchsetzbarkeit: Kritische IKT-Drittverträge müssen die DORA-Mindestklauseln (Audit-Rechte, Exit-Strategie, Sub-Outsourcing-Transparenz, Service-Level mit Resilienzbezug) tatsächlich enthalten und durchsetzbar sein — nicht als Absichtserklärung, sondern als prüfbare Vertragsrealität.
5. 5Vom IT-Silo zur Leitungsorgan-Evidenz: Das Leitungsorgan muss nachweisen können, dass es informiert entscheidet. Das verlangt eine regelmäßige, dokumentierte Resilienz-Berichterstattung an die Geschäftsleitung — mit klaren Kennzahlen statt technischer Detailberichte, damit die nicht-delegierbare Verantwortung auch belegbar wahrgenommen wird.

Operative Resilienz ist eine Delivery-Aufgabe

Die häufigste strategische Fehleinschätzung im Finanzsektor ist die Behandlung von DORA als reines Rechts- und Compliance-Thema, das in der Legal- oder Risk-Funktion endet. Diese Verortung produziert genau die Papier-Resilienz, die 2026 durchfällt. Die Pflichten von DORA sind in ihrer Substanz Delivery-Pflichten: Sie verlangen funktionierende Prozesse, instrumentierte Systeme, geübte Eskalation und nachverfolgbare Verbesserung.

Konkret bedeutet das: Das Register of Information ist ein Datenintegrationsprodukt mit eigener Qualitätssicherung. Die Vorfall-Meldefähigkeit ist eine operationale Capability mit Service-Level. Resilienz-Testing ist Teil des Engineering-Backlogs, nicht ein externer Jahresreport. Wer DORA so behandelt, verwandelt eine Compliance-Last in eine messbare operative Stärke — und das ist exakt die Perspektive, aus der wir DORA bei Mandanten angehen: nicht als Dokumentationsübung, sondern als prüfbare Delivery-Praxis.

Der pragmatische Einstieg ist eine ehrliche Gap-Bestandsaufnahme entlang der fünf Säulen, gefolgt von einer kritikalitätsbasierten Priorisierung. Nicht jede Lücke ist 2026 gleich dringend — eine fehlende Register-Validierung oder eine reißende Meldefrist hat ein ungleich höheres Sanktionsrisiko als eine optionale Informationsaustausch-Mitgliedschaft. Die Kunst liegt darin, das Sanktionsrisiko und nicht die Vollständigkeit der Dokumentation zur Priorisierungslogik zu machen.

Konkrete nächste Schritte für 2026

Wenn Sie noch keine belastbare DORA-Standortbestimmung haben, ist der folgende Ablauf ein praktikabler Einstieg. Er ist bewusst auf Nachweisfähigkeit und nicht auf Dokumentenproduktion ausgelegt.

1. 1Register-Validierung priorisieren: Prüfen Sie zuerst, ob Ihr Register of Information die vorgeschriebene Struktur erfüllt, vollständige LEI-Codes enthält und Sub-Outsourcing-Ketten lückenlos abbildet. Dies ist der wahrscheinlichste erste Prüfpunkt der Aufsicht 2026.
2. 2Meldeprozess unter Realbedingungen testen: Führen Sie eine Tabletop-Simulation eines schwerwiegenden Vorfalls durch und messen Sie die tatsächliche Zeit bis zur klassifizierten Erstmeldung. Wenn der Prozess in der Übung die Frist reißt, reißt er sie auch im Ernstfall.
3. 3Kritische Drittverträge gegen die DORA-Mindestklauseln prüfen: Identifizieren Sie die kritischen IKT-Dienstleister und gleichen Sie deren Verträge gegen die DORA-Pflichtklauseln ab. Konzentrieren Sie sich auf die kritikalitätshöchsten Anbieter zuerst.
4. 4Leitungsorgan-Berichtslinie etablieren: Stellen Sie sicher, dass es eine regelmäßige, dokumentierte Resilienz-Berichterstattung an die Geschäftsleitung gibt — mit Kennzahlen, die die nicht-delegierbare Verantwortung belegbar machen.
5. 5Methodisches Fundament nutzen, nicht doppeln: Wenn ein NIST-CSF-2.0-Profil existiert, mappen Sie es auf die DORA-Anforderungen und schließen gezielt nur die finanzsektorspezifischen Nachweislücken, statt einen zweiten Compliance-Apparat parallel aufzubauen.