Das DORA-Informationsregister: Warum es in Wahrheit ein Datenqualitätsproblem ist

Teil 5 von 7 unserer DORA-Serie: Das Informationsregister ist keine nachgelagerte Meldeaufgabe, sondern ein Test für die Qualität der Lieferanten-, Vertrags- und Funktionsdaten einer Bank. Die bisherigen Teile erklären DORA im Überblick, den Exit-Plan, die Cloud-Abhängigkeit und eine Exit-Option für Customer-Engagement-Workloads. Dieser Beitrag zeigt, warum die belastbare Antwort auf die Registerpflicht in Data Governance liegt.

Das Register bildet eine Lieferkette ab, keine Dateiablage

Art. 28 Abs. 3 DORA verpflichtet Finanzunternehmen, ein Informationsregister über sämtliche vertraglichen Vereinbarungen zur Nutzung von IKT-Dienstleistungen zu führen und jährlich zu berichten. Die Durchführungsverordnung (EU) 2024/2956 konkretisiert diese Anforderung mit 15 Meldebögen und fest definierten Registerinhalten. Das ist wesentlich mehr als eine zentrale Vertragsliste: Das Register verknüpft Unternehmen, Verträge, Dienstleistungen, Funktionen, Datenstandorte und Lieferketten in einer strukturierten Sicht (DORA, Art. 28; ITS 2024/2956).

Die Logik ist relational. B_02.02 führt vertragsspezifische Angaben, B_05.01 den Anbieter, B_05.02 die IKT-Lieferkette, B_06.01 die Funktion und B_07.01 Bewertungen wie Substituierbarkeit und letztes Audit. Der direkte Dienstleister steht in der Lieferkette auf Rang 1, nachgelagerte Unternehmen auf Rang 2 oder höher. Wer diese Beziehungen nur in verstreuten Tabellen, Beschaffungsakten und E-Mails pflegt, kann zwar einzelne Felder befüllen. Eine konsistente und prüfbare Gesamtansicht entsteht so jedoch nicht (ITS 2024/2956).

Genau deshalb sind die in der ITS genannten Qualitätsdimensionen so hilfreich: Genauigkeit, Vollständigkeit, Konsistenz, Integrität, Einheitlichkeit und Gültigkeit. Sie übersetzen eine Regulierungsanforderung in einen operativen Datenqualitätsauftrag. Die Frage lautet nicht nur: „Ist das Formular abgegeben?“ Sie lautet: „Kann das Institut für jede ausgelagerte IKT-Leistung nachvollziehbar erklären, welcher Vertrag welche Funktion unterstützt, wer in der Kette liefert und welche Abhängigkeit daraus entsteht?“

Der Dry Run zeigt: Das Problem beginnt vor der Meldung

Der ESA-Dry-Run macht die Größenordnung sichtbar. Von 947 analysierten Registern bestanden lediglich 6,5 % alle 116 Datenqualitätsprüfungen; 93,5 % beziehungsweise 886 Register enthielten mindestens einen Fehler. Über 235.000 Fehler wurden in mehr als 9.275.000 Datenpunkten festgestellt. Das ist kein Hinweis auf einzelne Tippfehler, sondern auf systemische Brüche zwischen Quellen, Verantwortlichkeiten und Validierung (ESAs Dry Run Summary Report).

Die Fehlerstruktur weist den Weg zur Abhilfe. Fehlende Pflichtangaben machten 86 % der Fehler aus, ungültige LEIs 6,5 %, ungültige DPM-Werte 4 % sowie Duplikate und ungültige Daten 2,8 %. Besonders häufig fehlten Angaben in B_02.02; auch B_05.01 und B_07.01 waren auffällig. Damit liegen die Schwachstellen gerade dort, wo Vertrag, Anbieteridentität und Risiko- beziehungsweise Substituierbarkeitsbewertung zusammenkommen (ESAs Dry Run Summary Report).

Die Konsequenz für die Steuerung ist klar: Ein Reporting-Team kann fehlende Ursprungseigenschaften nicht dauerhaft am Abgabetag reparieren. Wenn ein Vertragsprozess keinen verbindlichen Datenstandort, keinen standardisierten Leistungstyp oder keine nachvollziehbare Funktionszuordnung erfasst, wird die Lücke im Register wiederkehren. Wenn ein Lieferantenstamm keine geprüfte Kennung führt, wird jede Folgeauswertung unzuverlässig.

Fünf Datenobjekte, die zusammengeführt gehören

Ein belastbares Register braucht ein fachliches Datenmodell, das unabhängig vom finalen CSV- oder Excel-Export funktioniert. In der Praxis bewährt sich ein klarer Eigentümer je Objekt.

Wichtig ist die gemeinsame Schlüsselstrategie. Für juristische Personen verlangt die ITS den 20-stelligen LEI nach ISO 17442 oder die EUID; für Drittlandanbieter ist der LEI vorgesehen. Sind beide Identifikatoren vorhanden, müssen beide geliefert werden. Im Dry Run wurden rund 9.000 ungültige LEIs bei Finanzunternehmen und rund 6.000 bei IKT-Drittdienstleistern festgestellt; Register ohne LEI werden zurückgewiesen (ITS 2024/2956; ESAs Dry Run Summary Report).

Diese Kennungen sind nicht bloß technische Pflichtfelder. Sie verhindern, dass derselbe Dienstleister unter leicht unterschiedlichen Namen mehrfach geführt wird oder dass die Lieferkette an einer unscharfen Entität endet. Gleiches gilt für kontrollierte Wertelisten: Die ITS unterscheidet beispielsweise IaaS, PaaS und SaaS sowie Infrastruktur/Hosting und On-Premise-Software. Ein Freitextfeld „Cloud“ genügt deshalb nicht, wenn später Vergleichbarkeit und Konsolidierung erforderlich sind (ITS 2024/2956).

Vom Stichtagsprojekt zum laufenden Kontrollkreislauf

Das Zielbild ist ein Register, das durch Ereignisse aktualisiert wird, nicht eine jährliche Aufräumaktion. Neue Verträge, Verlängerungen, Subunternehmerwechsel, Standortänderungen, Funktionsänderungen und Audits müssen jeweils einen klaren Daten- und Freigabeschritt auslösen. Dadurch verschiebt sich die Arbeit von manueller Nachpflege zu präventiver Qualitätssicherung.

Ein pragmatischer Kontrollkreislauf besteht aus vier Schritten. Erstens werden Pflichtattribute am Ursprung erfasst und gegen Referenzdaten geprüft. Zweitens werden Vertrags-, Anbieter- und Funktionsdaten über stabile Schlüssel verknüpft. Drittens validiert ein Datenqualitätsmonitor Vollständigkeit, Wertebereiche, Dubletten und Beziehungsregeln vor dem Reporting. Viertens erhalten die fachlich verantwortlichen Stellen eine Ausnahmeliste mit Frist und Nachweis. Das Register wird damit zu einem Steuerungsinstrument für Auslagerungsrisiken, nicht zu einem Archiv.

Die vorhandenen EBA-Leitlinien stützen diese Sicht: Sie verlangen unter anderem Angaben zu personenbezogenen Daten, Ländern und Datenstandorten, Cloud-Service- und Deployment-Modell sowie zur Substituierbarkeit, zu alternativen Anbietern, Zeitkritikalität und Jahresbudget. Das sind Attribute, die nur dann verlässlich sind, wenn sie im laufenden Outsourcing- und Risikomanagement gepflegt werden (EBA/GL/2019/02).

Der nächste Zyklus ist ein Qualitätsfenster

In Deutschland lief die erste Scharfrunde mit Stichtag 31. März 2025; BaFin-beaufsichtigte Unternehmen sollten bis 28. April 2025 über das MVP-Portal einreichen. Ab 2026 ist die Übermittlung an die ESAs jeweils bis 31. März mit Stichtag 31. Dezember des Vorjahres vorgesehen. Für den zweiten Zyklus war ein Einreichungsfenster vom 1. bis 31. März 2026 und eine Nachbesserung bis 30. April 2026 kommuniziert. Entscheidend: Die Pflicht gilt erst als erfüllt, wenn die ESAs die Einreichung akzeptieren (BaFin-Fachartikel; Central Bank of Ireland).

Das sollte Institute dazu bewegen, nicht nur an der Taxonomie zu arbeiten. Sinnvoller ist eine Wiederholungsprobe: Kann die Bank für eine Stichprobe von Verträgen Herkunft, Verantwortlichen, Lieferkette, Standort, Funktionsbezug und Bewertung ohne manuelle Recherche erklären? Die Antwort offenbart die Reife des zugrunde liegenden Datenmanagements zuverlässiger als eine formal gefüllte Datei.

Für Customer-Engagement-Architekturen ist diese Disziplin ebenfalls relevant. Eine CDP- und Data-Governance-Schicht muss beispielsweise Consent, Lineage und PII-Schutz nachvollziehbar handhaben. Acceleraid beschreibt für seine Plattform Echtzeit-Aggregation aus CRM, Core Banking und Kartenverarbeitung sowie Consent Management, Datenlineage, rollenbasierten Zugriff und PII-Schutz. Das ist keine Aussage, dass die Plattform das DORA-Register ersetzt; es zeigt vielmehr, welche Governance-Fähigkeiten an der Datenbasis auch für Registerqualität zählen (Acceleraid Platform).

Die nächste Frage der Serie ist, was geschieht, wenn nicht nur Datenfelder, sondern zugrunde liegende KI-Modelle oder ihre Anbieter konzentriert sind. Darum geht es in Teil 6 über KI-Anbieter als Konzentrationsrisiko. Teil 7 liefert anschließend die notwendige Bewertungslogik für kritische und wichtige Funktionen.

Die DORA-Serie im Überblick

• Teil 1: DORA für Banken: Was die EU-Verordnung regelt und wie sie funktioniert

• Teil 2: Der Exit-Plan nach DORA: Was er enthalten muss und warum er getestet werden muss

• Teil 3: Cloud-Abhängigkeit europäischer Banken: Wie man von AWS, Microsoft und Google notfalls loskommt

• Teil 4: Exit-Option für Customer-Engagement-Workloads: CDP, Personalisierung und Kampagnen DORA-konform absichern

• Teil 5: Das DORA-Informationsregister: Warum es in Wahrheit ein Datenqualitätsproblem ist (dieser Beitrag)

• Teil 6: KI-Anbieter als neues Konzentrationsrisiko: Was DORA für Modell-Abhängigkeiten bedeutet

• Teil 7: Kritisch oder wichtig? Risiko-Level von Core Banking bis CRM, Data Lake und CDP

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.