Guide
DORA-Informationsregister: Wie prüfst du die Datenqualität?
Verträge, Dienstleister und Funktionen im DORA-Informationsregister plausibel verknüpfen: Prüfschritte, typische Fehler und ein Beispiel zum Lieferantenwechsel.
Ein DORA-Informationsregister kann technisch verarbeitet werden und trotzdem falsche Zusammenhänge enthalten. Ein Dienstleister steht doppelt darin, eine Vertragsreferenz führt ins Leere oder ein Platzhalter ersetzt die tatsächliche Konzernmutter. Deshalb braucht die Datenqualität eine eigene Prüfung vor der Abgabe.
Die Central Bank of Ireland beschreibt für 2026 zusätzliche inhaltliche Prüfungen der Registerdaten durch die EBA. Als Fehlerbeispiele nennt sie unter anderem unbrauchbare Identifikationswerte und generische Anbieterbezeichnungen. Die dort beschriebenen irischen Einreichungsfristen sind keine Fristen für deutsche Unternehmen. Central Bank of Ireland
Die Grundlagen und den Aufbau behandelt unser Leitfaden zum DORA-Informationsregister. Hier geht es gezielt um die Prüfung und Korrektur eines vorhandenen Datenstands.
Prüfe in drei getrennten Durchgängen
Beginnt mit dem für eure Einreichung geltenden Schema und den aktuellen Vorgaben der zuständigen Aufsicht. Friert den zu prüfenden Datenstand ein, damit Korrekturen und Ergebnisse zugeordnet werden können.
| Prüfung | Leitfrage | Typischer Fehler |
|---|---|---|
| Technisch | Entspricht die Datei dem vorgesehenen Format? | Falsche Struktur oder ungültiger Datentyp |
| Beziehungen | Stimmen die Referenzen zwischen den Tabellen? | Vertrag verweist auf unbekannten Dienstleister |
| Fachlich | Beschreiben die Angaben die tatsächliche Leistung? | Alte Gesellschaft oder falsche Funktion zugeordnet |
Diese Arbeitshilfe ersetzt keinen offiziellen Validierungskatalog. Sie verhindert, dass ein erfolgreicher Upload mit einer fachlichen Freigabe verwechselt wird.
Gleiche das Register mit den Ausgangsunterlagen ab
Eine Lieferantenliste ist ein Eingang, aber nicht automatisch das vollständige Register. Vergleicht den Bestand mit Verträgen, Leistungsbeschreibungen und den intern verantworteten Funktionen. Klärt, wo dieselbe Firma unter mehreren Schreibweisen vorkommt und wo ähnlich benannte Firmen tatsächlich verschiedene Rechtsträger sind.
Kennungen sollten eine nachvollziehbare Quelle haben. Schreibt bei Unsicherheiten nicht einfach „unbekannt“ in ein Feld, das einen definierten Wert verlangt. Klärt die Information oder behandelt den offenen Punkt nach den einschlägigen Vorgaben.
Der Leitfaden zum Lieferantenrisikomanagement hilft, die fachliche Verantwortung hinter einem Eintrag zu bestimmen. Ein Einkaufskontakt kann die Vertragsdaten liefern; die Bedeutung der Leistung für einen Geschäftsprozess muss häufig eine andere Person beurteilen.
Verfolge einen Eintrag durch alle Beziehungen
Wählt je kritischem Fall eine vollständige Kette: vertragliche Vereinbarung, direkter Dienstleister, Leistung, nutzende Einheit und unterstützte Funktion. Prüft die weiteren erforderlichen Angaben anhand des geltenden Registers.
Dabei geht es nicht darum, eine frei erfundene Hierarchie einzuführen. Ihr prüft, ob die im vorgesehenen Datenmodell erfassten Verweise inhaltlich zusammenpassen. Eine gültige Kennung kann auf den falschen Datensatz zeigen.
Beispiel: Der Vertragspartner ändert sich
Fiktiver Fall: Ein Finanzdienstleister wechselt seinen Hosting-Vertragspartner. Die technische Umgebung bleibt zunächst gleich. Im Register wird nur der Firmenname überschrieben; Vertragsreferenzen und zugeordnete Leistungen bleiben ungeprüft.
Das Team hält den Wechsel stattdessen als nachvollziehbaren Vorgang fest: Welche Vereinbarung endete? Welche begann? Welcher Rechtsträger erbringt welche Leistung? Welche Funktionen sind betroffen? Danach werden alle betroffenen Registerangaben anhand dieser Unterlagen geprüft.
Die Historie der Entscheidung bleibt erhalten. Ob und wie beendete Vereinbarungen im konkreten Meldestand enthalten sein müssen, wird anhand der gültigen Vorgaben geklärt. Ein bloßes Löschen alter Zeilen ist dafür keine ausreichende Methode.
Führe Fehler bis zur fachlichen Abnahme nach
Ein brauchbares Fehlerprotokoll enthält Datensatzreferenz, betroffene Angabe, Befund, Quelle, verantwortliche Person und Korrekturstatus. Trennt „geändert“ von „geprüft“. Nach einer Korrektur müssen gegebenenfalls auch abhängige Tabellen erneut validiert werden.
Für wiederkehrende Fehler braucht ihr eine Änderung an der Erfassung. Wenn neue Verträge regelmäßig ohne eindeutige Zuordnung eintreffen, löst die nächste Tabellenbereinigung das Grundproblem nicht. Verankert die benötigten Angaben im Prozess für Beschaffung und Änderungen.
Fehlerprotokoll zum Übernehmen
| Datensatz / Feld | Regelquelle und Stand | Befund | Verantwortlich | Korrektur | Ergebnis der erneuten Prüfung |
|---|---|---|---|---|---|
| Referenz eintragen | Geltende Vorgabe verlinken | Fehler konkret beschreiben | Person benennen | Änderung dokumentieren | Geprüft, offen oder erneut zu bearbeiten |
Bezieht bei Vertragsänderungen auch die DORA-Drittparteienrisiken ein. Die Datenprüfung und die Risikobeurteilung ergänzen sich, ersetzen einander aber nicht.
Was Kopexa dazu beitragen kann
In Kopexa könnt ihr Verantwortlichkeiten, Maßnahmen und die dazugehörigen Nachweise zusammenführen. Das hilft, offene Prüfungen und Belege nachvollziehbar zu bearbeiten. Die Eignung eines konkreten Registerexports für eure Aufsicht und Schemaversion muss gesondert geprüft werden; daraus folgt keine automatische regulatorische Abnahme.
Nutzt für einen Test einen bereinigten Vertragswechsel und prüft, ob alle beteiligten Personen ihren Beitrag liefern können. Ein guter Datenstand bleibt nur dann gut, wenn Änderungen im laufenden Betrieb ankommen.
Wie ihr die Aktualität von Belegen beurteilt, zeigt der Beitrag zu aktuellen ISMS-Nachweisen. Für Entscheidungen über verbleibende Lücken eignet sich eine klare Vorlage im Management-Review.
Kurz beantwortet
Häufige Fragen
Noch eine Frage offen? Hier findest du die Antworten zum Nachlesen.
Ist ein technisch akzeptierter Upload bereits ein korrektes Register?
Nein. Technische Verarbeitung und fachliche Datenqualität sind unterschiedliche Prüfungen. Plausibilität, Vollständigkeit und Zuordnungen müssen zusätzlich geprüft werden.
Was prüfe ich bei einem Lieferantenwechsel?
Welche Vertragsbeziehung endet oder beginnt, welche Leistungen und Funktionen betroffen sind und welche Kennungen und Verknüpfungen sich ändern. Der konkrete Meldestand richtet sich nach den geltenden Vorgaben.
Quellen
- Reporting Registers of Information — Central Bank of Ireland [Abgerufen am ]