DORA-Compliance und Data Governance: Was jedes Finanzinstitut wissen muss

Was ist DORA und für wen gilt es?

Der Digital Operational Resilience Act (DORA), die Verordnung (EU) 2022/2554, setzt verbindliche Anforderungen an das Management der IKT-Risiken, die Meldung von Vorfällen, Tests der Widerstandsfähigkeit und die Aufsicht über Dritte bei Finanzunternehmen in der Europäischen Union. Er trat im Januar 2023 in Kraft und gilt seit dem 17. Januar 2025 vollständig.

DORA gilt für ein breites Feld von Finanzinstituten: Banken und Kreditinstitute, Wertpapierfirmen, Versicherungen, Zahlungs- und E-Geld-Institute, Anbieter von Krypto-Dienstleistungen, Zentralverwahrer und kritische IKT-Drittdienstleister (CTPPs), darunter große Cloud-Anbieter wie AWS, Microsoft Azure und Google Cloud, die Finanzunternehmen in der EU bedienen.

Durchgesetzt wird die Verordnung von den zuständigen nationalen Behörden (NCAs) in jedem EU-Mitgliedstaat, auf EU-Ebene koordiniert von den Europäischen Aufsichtsbehörden (EBA, ESMA und EIOPA). Wer sie nicht einhält, riskiert verwaltungsrechtliche Sanktionen, aufsichtliche Maßnahmen und Folgen für den Ruf, die kein Compliance-Team dem Vorstand erklären möchte.

Die fünf Säulen von DORA und wo Data Governance jede einzelne berührt

DORA ist um fünf Kernanforderungen herum aufgebaut. Jede davon hat eine unmittelbare Dimension der Data Governance, die in IKT-getriebenen Umsetzungsprogrammen oft unterschätzt wird.

Säule 1: Management der IKT-Risiken

DORA verlangt von Finanzinstituten einen umfassenden Rahmen für das Management der IKT-Risiken, der Identifizierung, Schutz, Erkennung, Reaktion und Wiederherstellung über alle IKT-Systeme abdeckt, die kritische oder wichtige Funktionen tragen.

Die Dimension der Data Governance ist unmittelbar: Sie können das IKT-Risiko eines Systems nicht steuern, das Sie nicht dokumentiert haben. DORA erwartet von Instituten, ein aktuelles Verzeichnis der IKT-Bestände zu führen, Datenflüsse zwischen Systemen zu kartieren, kritische Funktionen und ihre technischen Abhängigkeiten zu bestimmen und festzuhalten, welche Daten wo liegen und wie sie sich durch Dienste Dritter bewegen.

Das ist keine einmalige Übung. DORA verlangt fortlaufende Beobachtung und regelmäßige Überprüfung. Wer sich auf starre Tabellen oder Prüfungen zum Stichtag verlässt, wird aufsichtliche Fragen nicht genau beantworten können, zumal die Nutzung der Cloud und die Anbindung Dritter den Wandel der Technologielandschaft beschleunigen.

Säule 2: Umgang mit IKT-Vorfällen, ihre Einstufung und Meldung

DORA schreibt Abläufe vor, um IKT-Vorfälle zu erkennen, zu bearbeiten, einzustufen und zu melden. Schwerwiegende Vorfälle müssen der zuständigen NCA innerhalb bestimmter Fristen gemeldet werden: eine erste Meldung binnen 4 Stunden nach der Einstufung, ein Zwischenbericht binnen 72 Stunden und ein Abschlussbericht binnen eines Monats.

Diese Fristen zu halten verlangt etwas, das vielen Instituten heute fehlt: die Fähigkeit, rasch zurückzuverfolgen, welche Daten, Systeme und Geschäftsfunktionen ein Vorfall berührt hat. Ohne Data Lineage, also eine dokumentierte Karte, wie Daten von den Quellsystemen über die Verarbeitungspipelines zu den Ergebnissen fließen, ist die Einstufung eines Vorfalls Handarbeit und fehleranfällig.

Denken Sie daran, was passiert, wenn ein Ausfall im Cloud-Speicher eine Pipeline zur Zahlungsverarbeitung trifft. Kann Ihr Team sofort sagen, welche Daten genau nicht erreichbar waren, welche nachgelagerten Berichte und Entscheidungen betroffen waren, welche Kundinnen und Kunden es traf und ob personenbezogene Daten gefährdet waren? Ohne Data Lineage und einen geregelten Datenkatalog dauern diese Antworten Tage statt Stunden, und Tage lässt DORA nicht zu.

Säule 3: Tests der digitalen operationalen Resilienz

DORA verlangt von Finanzinstituten regelmäßige Tests der Widerstandsfähigkeit ihrer IKT-Systeme, darunter bedrohungsgeleitete Penetrationstests (TLPT) alle drei Jahre für bedeutende Institute. Der Zweck ist nicht nur, Schwachstellen zu finden, sondern zu belegen, dass kritische Funktionen aufrechterhalten oder rasch wiederhergestellt werden können.

Tests der Widerstandsfähigkeit bringen nur dann Nutzen, wenn Institute verstehen, was sie da testen. Ein Penetrationstest an einem System, dessen Datenflüsse und Abhängigkeiten nicht dokumentiert sind, liefert Ergebnisse, die sich nicht richtig priorisieren lassen. Ein Wiederherstellungsverfahren für eine Datenpipeline zu testen setzt voraus, dass man weiß, was diese Pipeline tut, welche Daten sie verarbeitet und welche Geschäftsprozesse von ihr abhängen.

Data Governance, genauer ein gepflegtes Bestandsverzeichnis mit dokumentierten Abhängigkeiten und Datenklassifizierungen, ist das, was Tests der Widerstandsfähigkeit von einem Häkchen in der Compliance zu einer echten Risikominderung macht.

Säule 4: Management der IKT-Drittparteienrisiken

DORA stellt genaue Anforderungen an das Management von IKT-Dienstleistern, darunter vertragliche Vorgaben für kritische Anbieter, Ausstiegsstrategien und, für kritische Drittdienstleister (CTPPs), eine unmittelbare Aufsicht durch EU-Behörden.

Die Aufgabe für die Data Governance ist hier beträchtlich. Finanzinstitute müssen wissen: welche Dritten ihre Daten verarbeiten, welche Datenkategorien mit welchem Anbieter geteilt werden, wo die Daten geografisch liegen, welche vertraglichen Schutzvorkehrungen jede Beziehung regeln und ob kritische Funktionen tragfähige Alternativen haben, falls ein Anbieter ausfällt oder sanktioniert wird.

Nach den Leitlinien der EBA müssen Institute ein Informationsregister über alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern führen. Dieses Register ist nicht freiwillig, es unterliegt der aufsichtlichen Prüfung und muss den tatsächlichen Stand der Beziehungen abbilden, nicht eine Näherung aus dem letzten Prüfzyklus.

Säule 5: Austausch von Informationen und Erkenntnissen

DORA legt Finanzinstituten nahe, in manchen Zusammenhängen verlangt es sogar, Erkenntnisse über Bedrohungen zu IKT-Schwachstellen und Vorfällen mit anderen Instituten und der Aufsicht zu teilen. Damit dieser Austausch sicher und wirksam ist, müssen Institute Informationen sorgfältig einstufen und steuern können: eigene Daten von teilbaren Bedrohungsindikatoren unterscheiden, personenbezogene Daten erkennen, die ohne Einwilligung nicht geteilt werden dürfen, und die Rechtsgrundlage jedes Austauschs festhalten.

Metadaten zur Datenklassifizierung sind die Governance-Schicht, die das möglich macht. Ohne sie teilen Institute entweder zu wenig und verschenken den Nutzen gemeinsamer Erkenntnisse, oder zu viel und schaffen damit ein Risiko nach der DSGVO.

Die vier Fähigkeiten der Data Governance, die DORA verlangt

Über alle fünf Säulen von DORA hinweg treten vier Fähigkeiten der Data Governance durchgehend als entscheidend hervor. Unternehmen, die in sie investiert haben, finden die Compliance mit DORA machbar. Wer das nicht getan hat, merkt, dass Investitionen in Technik allein, bessere SIEM-Werkzeuge oder ausgefeiltere Überwachung, ein fehlendes geregeltes Datenfundament nicht ausgleichen.

1. Ein geregeltes Verzeichnis der IKT-Bestände

Die Anforderungen von DORA an das Management der IKT-Risiken beginnen mit der Bestimmung der Bestände. Art. 8 DORA verlangt von Instituten, alle IKT-Bestände zu bestimmen, zu klassifizieren und zu dokumentieren, die kritische oder wichtige Funktionen tragen, darunter Hardware, Software, Daten und externe Dienste.

Dieses Verzeichnis muss fortlaufend gepflegt werden, nicht jährlich aktualisiert. Es muss genau genug sein, um Entscheidungen bei einem Vorfall binnen Stunden zu tragen. Und es muss die Beziehungen zwischen den Beständen erfassen, also welche Systeme welche Pipelines speisen und welche Anwendungen von welchen Datenbanken abhängen, nicht nur ihre bloße Existenz.

Ein Datenkatalog, der IKT-Bestände samt ihren Datenflüssen, fachlichen Verantwortlichen, Stufen der Kritikalität und Abhängigkeiten von Dritten abbildet, ist die praktische Umsetzung dessen, was Art. 8 DORA verlangt.

2. Durchgängige Data Lineage

Data Lineage, also die dokumentierte Spur, wo Daten entstehen, wie sie umgeformt werden und wohin sie fließen, ist die Fähigkeit, die die Meldefristen von DORA erreichbar macht. Ohne sie verlangt die Auswirkungsanalyse bei IKT-Vorfällen händische Nachforschung über mehrere Teams, mehrere Systeme und mehrere Dokumentationsquellen hinweg.

Mit automatisierter Data Lineage wird die Auswirkungsanalyse zu einer Abfrage statt zu einer Ermittlung. Trifft ein Vorfall ein Quellsystem, sieht das Unternehmen sofort, welche nachgelagerten Berichte, Dashboards, aufsichtsrechtlichen Meldungen und Geschäftsentscheidungen betroffen sind, und kann diese Folgen innerhalb des Vier-Stunden-Fensters für die erste Meldung nach DORA genau mitteilen.

Data Lineage stützt auch die Anforderungen von DORA an Tests der Widerstandsfähigkeit. Testszenarien werden realistischer, wenn sie auf dokumentierten Datenflüssen beruhen statt auf vermuteten Abhängigkeiten. Wiederherstellungsverfahren werden verlässlicher, wenn sie alle nachgelagerten Verbraucher eines wiederhergestellten Systems berücksichtigen und nicht nur die sichtbarsten.

3. Metadaten zur Datenklassifizierung und Zugriffskontrolle

DORA verlangt von Instituten, ihre Daten und IKT-Bestände nach Kritikalität zu klassifizieren. Art. 9 DORA verlangt ausdrücklich, Richtlinien zur Datenklassifizierung umzusetzen und zu dokumentieren, wo sensible und kritische Daten liegen.

Diese Klassifizierung dient zugleich mehreren Zwecken der Compliance: Sie stützt die Einstufung der Schwere eines Vorfalls nach DORA, die Compliance mit der DSGVO für personenbezogene Daten, angemessene Vertragsklauseln mit Dritten und die Zugriffskontrollen, die die Schutzanforderungen von DORA vorschreiben.

Metadaten zur Klassifizierung, die nur in Tabellen leben, sind eine Belastung. Eine Klassifizierung, die in einem geregelten Datenkatalog liegt, jedem Datensatz zugeordnet ist, bei Änderungen nachgeführt wird und den Systemen zur Verfügung steht, die Zugriffsrichtlinien durchsetzen, ist das, was die Anforderung von DORA an fortlaufende Beobachtung tatsächlich verlangt.

4. Dokumentierte Data Ownership und Rechenschaft

Die Anforderungen von DORA an die Reaktion auf Vorfälle setzen voraus, dass Finanzinstitute schnell und genau bestimmen können, wer für bestimmte IKT-Systeme und Datenbestände verantwortlich ist. Metadaten zur Verantwortung, also die dokumentierte Zuweisung von Rechenschaft für jeden kritischen Datensatz und jedes kritische System, sind die Governance-Schicht, die das möglich macht.

Verantwortung heißt nicht nur, wer ein System betreut. Für die Compliance mit DORA muss sie sich auf die Daten erstrecken: wer für die Genauigkeit der Daten einer kritischen Pipeline geradesteht, wer einen Vorfall zu bestimmten Datenkategorien ausrufen darf und wer bei einem meldepflichtigen Vorfall mit der zuständigen NCA spricht.

Unternehmen, die die Datenverantwortung klar bestimmt und diese Dokumentation über Wechsel von Personal und Zuständigkeiten hinweg gepflegt haben, beantworten Prüfungen nach DORA und Untersuchungen von Vorfällen deutlich schneller als jene, die Verantwortung als stillschweigendes Organisationswissen behandeln.

Die Parallele zu BCBS 239: Warum Finanzinstitute das schon kennen

Für Banken, die den Grundsätzen von BCBS 239 des Basler Ausschusses unterliegen, dürften die Anforderungen von DORA an die Data Governance vertraut wirken. BCBS 239, im Jahr 2013 verabschiedet, setzte Anforderungen an die Aggregation von Risikodaten und die Risikoberichterstattung, die auf denselben Fundamenten ruhen: vollständige Datenverzeichnisse, durchgängige Lineage, dokumentierte Verantwortung und prüfbare Nachvollziehbarkeit.

Die unbequeme Wahrheit ist, dass die meisten Banken BCBS 239 noch immer nicht vollständig erfüllen. Die Bewertungen des Basler Ausschusses selbst finden durchgehend, dass Fähigkeiten zur Datenaggregation, die Dokumentation der Lineage und die Reife der Data Governance unter dem Standard bleiben, den die Grundsätze setzen, und das mehr als ein Jahrzehnt nach ihrer Verabschiedung.

DORA macht die Compliance mit BCBS 239 nicht weniger dringend. Es macht sie dringender, indem es Anforderungen an die operationale Widerstandsfähigkeit hinzufügt, die auf derselben Infrastruktur der Data Governance aufsetzen. Banken, die ihre Programme zur Data Governance wegen DORA beschleunigen, schließen nebenbei Lücken bei BCBS 239, die Aufseher seit Jahren anmahnen.

DORA und der EU AI Act: eine sich häufende Last

Finanzinstitute, die sich durch DORA arbeiten, können es sich nicht leisten, die Verordnung für sich zu betrachten. Der EU AI Act, dessen Pflichten für KI-Anwendungen mit hohem Risiko im Finanzwesen am 2. August 2026 greifen, stellt Anforderungen, die sich mit denen von DORA an die Data Governance deutlich überschneiden.

KI-Systeme für Kreditbewertung, Betrugserkennung, KYC und Risikomanagement gelten nach dem EU AI Act als Systeme mit hohem Risiko. Für jedes davon müssen Institute die Herkunft der Trainingsdaten, Verfahren zur Prüfung der Datenqualität, die Versionierung der Modelle, Kontrollen gegen Verzerrungen und die Protokollierung für Prüfungen dokumentieren. Diese Anforderungen stehen nicht neben dem IKT-Bestandsverzeichnis und der Lineage nach DORA, sie sind deren Fortsetzung in die Modellebene hinein.

Unternehmen, die ihre Infrastruktur für Data Governance mit beiden Regelwerken im Blick aufbauen, statt die Compliance mit DORA in einem Programm und die mit dem EU AI Act in einem anderen umzusetzen, erleben die überlappenden Anforderungen als Ergänzung statt als Doppelarbeit. Das Fundament aus Metadaten, das die Meldung von Vorfällen nach DORA trägt, ist dasselbe, das die Audit-Trails des EU AI Act trägt.

Wo Dawiso hineinpasst: Data Governance für Finanzinstitute, die DORA erfüllen

Dawiso hilft Finanzinstituten, das Fundament der Data Governance aufzubauen, das DORA verlangt, und zwar nicht als Werkzeug für die Compliance, sondern als die betriebliche Infrastruktur, die Compliance dauerhaft trägt.

Die Plattform deckt jede der vier entscheidenden Fähigkeiten der Data Governance ab, die DORA verlangt:

• Verzeichnis der IKT-Bestände: Der Data Catalog von Dawiso liefert ein zentrales, fortlaufend aktualisiertes Verzeichnis der Datenbestände, Systeme und ihrer Beziehungen, samt der Datenflüsse zu Dritten und der Abhängigkeiten, die Art. 8 DORA zu dokumentieren verlangt.
• Durchgängige Data Lineage: Die Interactive Data Lineage von Dawiso verfolgt Daten automatisch von den Quellsystemen über Umformungen bis zu nachgelagerten Berichten und Entscheidungen. Tritt ein IKT-Vorfall ein, wird die Auswirkungsanalyse zu einer Abfrage statt zu einer mehrtägigen Ermittlung quer durch abgeschottete Dokumentation.
• Metadaten zu Klassifizierung und Zugriff: Das Business Glossary von Dawiso und die Funktionen zur Klassifizierung liefern die dokumentierte, gepflegte Datenklassifizierung, die Art. 9 DORA verlangt, eingebettet in Katalog und Lineage statt getrennt in Tabellen gepflegt.
• Verantwortung und Rechenschaft: Dawiso weist Datenverantwortung auf Ebene des Datensatzes und des Begriffs zu und verfolgt sie, und liefert damit die Kette der Rechenschaft, auf der die Anforderungen von DORA an Reaktion und Meldung beruhen.

Entscheidend ist, dass Dawiso dafür entworfen ist, von den Fachbereichen gepflegt zu werden und nicht nur von Dateningenieuren. Die Compliance mit DORA ist kein einmaliges Vorhaben, sie ist eine dauerhafte betriebliche Anforderung. Eine Data Governance, die für die Pflege spezialisierte technische Kräfte braucht, fällt hinter das Tempo des Wandels in jedem realen Finanzinstitut zurück. Die anwenderfreundliche Oberfläche von Dawiso bedeutet, dass Zuweisungen der Verantwortung, Aktualisierungen der Klassifizierung und Änderungen am Glossar von den Menschen vorgenommen werden können, die den Daten am nächsten stehen, was die Governance-Schulden verringert, die sich dort ansammeln, wo Änderungen über die IT laufen müssen.

Eine praktische Checkliste für Data Governance nach DORA

Für Teams in Compliance und Data Governance, die ihre Bereitschaft für DORA einschätzen, stellen die folgenden Fähigkeiten das Mindestfundament dar, das die Anforderungen von DORA voraussetzen:

• ☐ Vollständiges Register der IKT-Bestände über Systeme, Datenbestände und Dienste Dritter, die kritische oder wichtige Funktionen tragen, fortlaufend gepflegt und nicht zum Stichtag
• ☐ Dokumentierte Datenflüsse zwischen Systemen, auch zu und von IKT-Drittdienstleistern, mit klarer Angabe der Datenkategorien auf jeder Stufe
• ☐ Durchgängige Data Lineage für kritische Geschäftsprozesse, die eine rasche Auswirkungsanalyse erlaubt, wenn Vorfälle Quellsysteme treffen
• ☐ Schema zur Datenklassifizierung, angewandt auf alle kritischen Datenbestände, mit dokumentierten Kriterien, die personenbezogene Daten, sensible Geschäftsdaten und kritische Betriebsdaten unterscheiden
• ☐ Benannte Verantwortliche für alle kritischen Datensätze und Systeme, mit dokumentierten Eskalationswegen für die Reaktion auf Vorfälle und die Kommunikation mit der Aufsicht
• ☐ Register der Dritten, das vertragliche Beziehungen, geteilte Datenkategorien, geografische Speicherorte und den Stand der Ausstiegsstrategie für jeden kritischen IKT-Anbieter abbildet
• ☐ Fähigkeit zur Auswirkungsanalyse bei Vorfällen, also binnen Stunden bestimmen zu können, welche Datenbestände und Geschäftsfunktionen ein IKT-Vorfall berührt
• ☐ Audit-Trail für Entscheidungen der Data Governance: wann Klassifizierungen geändert wurden, wer Übergaben der Verantwortung freigegeben hat und wann die Dokumentation der Lineage zuletzt geprüft wurde

Fazit: DORA ist ein Auftrag an die Data Governance, nicht nur ein IT-Projekt

Die Finanzinstitute, die DORA am besten meistern, sind jene, die erkennen, was die Verordnung tatsächlich verlangt: nicht bessere Überwachungswerkzeuge, nicht umfangreichere Penetrationstests, sondern eine geregelte, dokumentierte, fortlaufend gepflegte Sicht auf ihre Daten- und Technologielandschaft.

Das ist ein Problem der Data Governance. Und es ist genau die Art von Problem, die schwerer statt leichter wird, je länger man sie als IT-Projekt statt als Fähigkeit des Unternehmens angeht.

Die gute Nachricht ist, dass die Infrastruktur der Data Governance, die die Compliance mit DORA dauerhaft trägt, dieselbe ist, die BCBS 239, den EU AI Act, die DSGVO und die von KI gestützten Abläufe der Compliance trägt, die zunehmend neu bestimmen, wie effizienter Finanzbetrieb aussieht. Die Investition summiert sich, statt sich zu doppeln.

Für Finanzinstitute, die die Lücke noch schließen müssen, ist der Ausgangspunkt derselbe wie eh und je: Kennen Sie Ihre Daten, halten Sie fest, wer für sie verantwortlich ist, und verfolgen Sie, wohin sie fließen. DORA hat nicht verändert, wie gute Data Governance aussieht. Es hat nur die Folgen ihres Fehlens sichtbarer gemacht, und unmittelbarer.