Praxisorientierte Einordnung zu DORA-Register of Information: Datenqualität und Verantwortlichkeiten organisieren: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für DORA aufbauen.
Das DORA-Informationsregister ist kein erweitertes Lieferantenverzeichnis. Es bildet sämtliche vertraglichen Vereinbarungen über IKT-Dienstleistungen ab und verbindet Finanzunternehmen, Funktionen, Verträge, Dienste, Anbieter, Unterauftragnehmer und Leistungsstandorte in einem strukturierten Datenmodell. Aufsichtsbehörden nutzen diese Informationen sowohl zur Prüfung des Drittparteienrisikomanagements als auch zur Identifizierung kritischer IKT-Drittdienstleister.
Die Durchführungsverordnung (EU) 2024/2956 legt verbindliche Vorlagen, Datenformate und Beziehungen fest. Sie verlangt genaue und konsistente Informationen, regelmäßige Überprüfung und unverzügliche Korrektur erkannter Fehler. Datenqualität ist daher ein dauerhafter Governance-Prozess und keine jährliche Excel-Bereinigung vor der Einreichung.
Die rechtliche Funktion des Registers
Artikel 28 Absatz 3 DORA verpflichtet Finanzunternehmen, ein Register aller vertraglichen Vereinbarungen über die Nutzung von IKT-Dienstleistungen zu führen. Auf Unternehmensebene sowie gegebenenfalls auf teilkonsolidierter und konsolidierter Ebene sind strukturierte Informationen bereitzuhalten.
Das Register unterstützt Risikoüberwachung, Aufsicht, Konzentrationsanalyse und die europäische Benennung kritischer Anbieter. Deshalb muss es sowohl vollständig als auch maschinenlesbar sein. Ein parallel geführtes Vertragsarchiv kann Quelle sein, erfüllt aber das DORA-Datenmodell nicht automatisch.
Welche Vertragsbeziehungen in den Scope gehören
Erfasst werden alle IKT-Dienstleistungen direkter externer und gruppeninterner IKT-Dienstleister. Der Scope ist nicht auf Auslagerungen oder kritische Funktionen begrenzt. Auch kleinere SaaS-, Daten-, Netzwerk-, Support- oder Infrastrukturleistungen können registerpflichtig sein.
Unterauftragnehmer werden erfasst, wenn sie IKT-Dienste, die kritische oder wichtige Funktionen oder wesentliche Teile davon unterstützen, tatsächlich unterlegen. Die Lieferkette muss daher über den direkten Vertragspartner hinaus transparent sein. Rang und Beziehung werden korrekt abgebildet.
Die Vorlagen als relationales Datenmodell verstehen
Die ITS-Vorlagen bestehen aus mehreren Tabellen mit definierten Spalten und unbegrenzt vielen Zeilen. Eine Zeile kann nicht beliebig mehrere Werte enthalten; bei mehreren gültigen Werten ist eine zusätzliche Zeile nach Anleitung erforderlich. Identifikatoren verbinden die Tabellen.
Damit ähnelt das Register einer relationalen Datenbank mehr als einer Checkliste. Eindeutige Schlüssel, referenzielle Integrität und kontrollierte Wertelisten sind entscheidend. Manuelle Kopien zwischen Tabellen erzeugen schnell verwaiste oder widersprüchliche Beziehungen.
Die wichtigsten Objektgruppen
Das Datenmodell umfasst die registerführende Finanzentität, gruppenzugehörige Gesellschaften und Zweigniederlassungen. Es enthält allgemeine Vertragsdaten, IKT-Dienstleistungen, unterstützte Funktionen, Anbieter, Unterauftragnehmer, Leistungsstandorte und Bewertungen zu Kritikalität und Ersetzbarkeit.
Jedes Objekt besitzt eigene Verantwortliche und Quellsysteme. Legal kennt Vertragsparteien und Laufzeiten, Einkauf Bestellungen und Lieferanten, Fachbereiche Funktionen, IT die Dienste und Architektur, Risikomanagement die Kritikalität. Das Register muss diese Perspektiven konsistent zusammenführen.
Entity-Level, teilkonsolidiert und konsolidiert
Einzelunternehmen führen ein Register auf Unternehmensebene. Gruppen berücksichtigen zusätzlich die relevante sektorale EU-Gesetzgebung bei der Bestimmung des Konsolidierungskreises. Teilkonsolidierte und konsolidierte Register umfassen die relevanten Finanzunternehmen und gruppeninternen IKT-Dienstleister.
Die Gruppensteuerung definiert verbindliche Identifikatoren und Datenregeln, ohne die Verantwortung der lokalen Einheit zu verwischen. Lokale Verträge und Funktionen müssen korrekt zugeordnet bleiben. Konsolidierung ist kein einfaches Aneinanderhängen von Dateien.
Verantwortung beim Leitungsorgan und in der ersten Linie
Das Leitungsorgan verantwortet den DORA-Rahmen und damit auch die wirksame Drittparteiensteuerung. Operativ benötigt jedes Datenobjekt einen fachlichen Eigentümer. Die zentrale Registerfunktion koordiniert Standards, Validierung und Einreichung, erzeugt aber nicht allein alle Inhalte.
Fachbereiche bestätigen Funktionen und Kritikalität, Einkauf und Legal Verträge, IT Servicekatalog und Architektur, Vendor Management Anbieterketten und Risk die Bewertungen. Eine RACI-Matrix regelt Erfassung, Genehmigung, Änderung und Fehlerbehebung.
Quelle 1: Vertragsmanagement
Vertragsnummer, Art, Beginn, Ende, Kündigungsfrist, Rechtswahl und Vertragspartner stammen idealerweise aus einem strukturierten Vertragsmanagement. Rahmenvertrag, Einzelabruf, Bestellung und Leistungsbeschreibung müssen als zusammengehöriges Arrangement modelliert werden.
Ein häufiger Fehler ist die Erfassung nur des Rahmenvertrags. Dadurch fehlen konkrete Dienste, Gesellschaften und Laufzeiten. Umgekehrt dürfen mehrere Bestellungen nicht fälschlich als unabhängige Anbieterbeziehungen erscheinen, wenn sie Teil derselben Vertragsstruktur sind.
Quelle 2: Kreditoren und Einkauf
Kreditorenlisten sind ein wichtiger Vollständigkeitsabgleich. Sie zeigen bezahlte Anbieter, die in Vertrags- oder IT-Systemen fehlen. Allerdings enthalten sie Reseller, einmalige Käufe und Konzernabrechnungen, die fachlich aufgelöst werden müssen.
Der Abgleich verwendet Lieferanten-ID, Name, LEI oder EUID, Steuerdaten und Vertragsreferenz. Abweichungen werden kategorisiert: registerpflichtig und fehlend, korrekt ausgeschlossen, Dublette oder Klärungsfall. So wird Vollständigkeit messbar.
Quelle 3: Servicekatalog und Architektur
Das Register verlangt IKT-Dienste und ihre Beziehung zu Funktionen. Ein aktueller Servicekatalog beschreibt Leistungsinhalt, Eigentümer, technische Komponenten und Dienstleister. Architektur- und Cloudinventare zeigen, welche externen Leistungen tatsächlich verwendet werden.
Wenn der Einkauf „Cloud-Plattform“ erfasst, das Fachgeschäft aber Datenbank, Identität, Analyse und Backup als getrennte Services nutzt, braucht das Register eine sachgerechte Granularität. Sie muss regulatorische Bewertung und operative Steuerung ermöglichen.
Quelle 4: Funktions- und BIA-Daten
Kritische oder wichtige Funktionen werden aus einer genehmigten Methodik abgeleitet. Business-Impact-Analyse, Prozessregister und Dienstleistungsportfolio liefern die Grundlage. Funktions-ID und Bezeichnung müssen über Register, BIA, Kontinuitätsplan und Testprogramm konsistent sein.
Eine nachträgliche pauschale Kennzeichnung aller Dienste als kritisch verbessert die Sicherheit nicht. Sie verwässert Prioritäten und erzeugt falsche Aufsichtsdaten. Jede Zuordnung erhält eine fachliche Begründung und Genehmigung.
Identifikatoren richtig verwalten
Die Vorlagen nutzen definierte Identifikatoren wie LEI für Finanzunternehmen und geeignete Kennungen für Anbieter. Die Ausfüllanleitung und geschlossenen Wertelisten bestimmen Format und zulässige Werte. Freitextvarianten desselben Unternehmens erzeugen Dubletten.
Ein Golden-Source-Verzeichnis führt Rechtsname, Kennung, Land, Konzernbeziehung und Gültigkeit. Änderungen durch Fusion, Umfirmierung oder Wechsel des Vertragspartners werden historisiert. Validierungen prüfen Länge, Format und Referenzen.
Unterauftragnehmerketten erfassen
Der direkte Anbieter muss Transparenz über jene Unterauftragnehmer liefern, die kritische oder wichtige Funktionen tatsächlich unterstützen. Das Finanzunternehmen benötigt Rang, Dienstbezug, Standort und Identität. Unterschiedliche Lieferketten pro Service werden getrennt modelliert.
Verträge enthalten Informations- und Änderungsrechte. Vendor Management verfolgt geplante Änderungen und aktualisiert Register sowie Risikoanalyse. „Cloudanbieter unbekannt“ oder eine generische Kategorie genügt nicht, wenn ein konkreter Unterauftragnehmer wesentlich ist.
Leistungsstandorte und Datenbezug
Standorte der IKT-Dienstleistung und Datenverarbeitung beeinflussen Risiko, Aufsicht, Kontinuität und Exit. Regionale Cloudbegriffe müssen in die vom Template verlangten Länder- oder Standortangaben übersetzt werden. Primär- und Ausweichstandorte werden konsistent behandelt.
Ein Standortwechsel ist ein relevantes Änderungsereignis. Der Anbieterprozess stellt sicher, dass Legal, Datenschutz, Informationssicherheit und Registerfunktion informiert werden. Die Aktualisierung erfolgt nicht erst zur nächsten Jahresmeldung.
Datenqualitätsdimensionen definieren
Vollständigkeit fragt, ob alle Verträge und Pflichtfelder vorhanden sind. Richtigkeit prüft, ob Werte der realen Beziehung entsprechen. Konsistenz bewertet Widerspruchsfreiheit zwischen Tabellen und Ebenen. Aktualität misst Zeit zwischen Änderung und Registerpflege. Eindeutigkeit verhindert Dubletten.
Für jede Dimension werden Regeln und Schwellen festgelegt. Beispiele sind Anteil fehlender LEI, Verträge ohne IKT-Service, kritische Funktionen ohne Anbieterbeziehung, ungültige Länderwerte und abgelaufene Verträge mit laufender Zahlung.
Technische und fachliche Validierungen kombinieren
Technische Prüfungen kontrollieren Datentyp, Pflichtfeld, Werteliste, Schlüsselkonsistenz und Dateiformat. Die EBA veröffentlicht Data Point Model, Taxonomie, Validierungsregeln, Beispielpakete und Erklärungen zu Datenqualitätsrückmeldungen.
Fachliche Prüfungen erkennen logisch mögliche, aber falsche Werte: eine kritische Kernbankfunktion ohne IKT-Dienst, ein Cloudvertrag ohne Leistungsstandort oder ein bereits beendeter Vertrag mit aktivem Service. Beide Prüfebenen sind notwendig.
Änderungsereignisse in den Prozess integrieren
Neue Beschaffung, Vertragsänderung, Verlängerung, Kündigung, neue Funktion, Reorganisation, Anbieterwechsel, Unterauftragnehmer- oder Standortänderung lösen Registerupdates aus. Der Workflow startet möglichst im Quellprozess und nicht über eine spätere E-Mail-Abfrage.
Jedes Ereignis besitzt Frist, Datenverantwortlichen und Freigabe. Schnittstellen oder regelmäßige Datenläufe reduzieren manuelle Fehler. Änderungen werden protokolliert, damit Prüfer Herkunft und Zeitpunkt nachvollziehen können.
Kontrollen vor der Einreichung
Ein Freeze-Datum definiert den Berichtsbestand, ohne die operative Pflege auszusetzen. Danach folgen technische Validierung, fachliche Plausibilisierung, Abstimmung zwischen Einzel- und Gruppenebene sowie Managementfreigabe. Fehlerlisten werden versioniert bearbeitet.
Die BaFin stellt Hinweise für die nationale Einreichung bereit. Formate, Portal, Fristen und technische Anforderungen werden für jedes Berichtsjahr aktuell geprüft. Vorjahresanweisungen werden nicht ungeprüft wiederverwendet.
Rückmeldungen systematisch verarbeiten
Aufsichts- oder ESA-Validierungen können technische und fachliche Fehler melden. Das Unternehmen ordnet jeden Fehler einer Ursache zu: falsche Quelle, Mapping, Prozesslücke oder Einzelpflege. Korrekturen werden im Golden Source und nicht nur in der Versanddatei vorgenommen.
Wiederholungsfehler fließen in Kennzahlen und Kontrollverbesserung ein. Eine Datenqualitätsrunde nach Einreichung bewertet Muster, Verantwortlichkeiten und Automatisierungspotenzial. So sinkt der Aufwand im nächsten Zyklus.
Das Register für Risikosteuerung nutzen
Die strukturierten Beziehungen ermöglichen Analysen zu Anbieter-, Technologie-, Standort- und Unterauftragnehmerkonzentration. Funktionen ohne Exit-Alternative, mehrere Marken mit gleichem Cloud-Backend und gruppenweite Einzelfehler werden sichtbar.
Dashboards verbinden Kritikalität, Vertragsende, offene Findings, Vorfälle und Exit-Teststatus. Damit wird das Register zu einem operativen Steuerungsinstrument. Die Aufsichtsmeldung ist dann ein kontrollierter Auszug aus einem lebenden Datenbestand.
Ein Zielbetriebsmodell in sieben Schritten
- Verbindliches Datenmodell und Registerscope festlegen.
- Objekte und Felder fachlichen Eigentümern sowie Quellsystemen zuordnen.
- Golden Sources, Identifikatoren und Wertelisten etablieren.
- Änderungsereignisse in Einkauf, Vertrag, IT und Fachbereich integrieren.
- Technische und fachliche Validierungsregeln automatisieren.
- Einreichung, Freigabe und Fehlerkorrektur dokumentieren.
- Registerdaten für Konzentration, Exit und Managementberichte nutzen.
Typische Fehler aus der Praxis
Häufig wird nur eine Lieferantenliste importiert, ohne IKT-Dienste und Funktionen zu modellieren. Andere Register enthalten ausschließlich externe Anbieter und vergessen gruppeninterne Services. Ebenso problematisch sind uneinheitliche Funktionsnamen, fehlende Unterauftragnehmer und manuelle Freitextwerte.
Eine weitere Schwäche ist die jährliche Projektorganisation. Zwischen Einreichungen entstehen neue SaaS-Dienste, Vertragsänderungen und Reorganisationen. Ohne Ereignisprozess ist das Register am Tag nach der Meldung bereits veraltet.
Fazit: Datenverantwortung ist wichtiger als das Dateiformat
Die Registervorlagen sind technisch anspruchsvoll, doch die eigentliche Herausforderung ist fachliche Governance über Organisationsgrenzen hinweg. Nur klare Eigentümer, verlässliche Quellen, Änderungsprozesse und Validierungen erzeugen genaue, konsistente und aktuelle Informationen.
BlackMount unterstützt beim Aufbau des DORA-Informationsregisters, bei Datenmodell, Quellmapping, Validierung und operativem Zielprozess. Das Register wird dabei zugleich für Aufsicht und wirksame Drittparteiensteuerung nutzbar gemacht.
