Das DORA-Informationsregister: die häufigsten Fehler

Warum die meisten Register an denselben drei Stellen scheitern – LEI-Qualität, Auslagerungsketten und die Verknüpfung zu kritischen Funktionen – und wie Sie das vermeiden.

Das Informationsregister nach Art. 28 Abs. 3 DORA ist auf den ersten Blick eine Fleißaufgabe: eine Liste aller vertraglichen Vereinbarungen über IKT-Dienstleistungen, in einem durch die Durchführungsverordnung (EU) 2024/2956 vorgegebenen Format, jährlich an die BaFin zu übermitteln.

Auf den zweiten Blick ist es die Stelle, an der die Aufsicht sieht, ob ein Institut seine IKT-Landschaft wirklich versteht. Denn das Register verlangt keine Liste von Verträgen. Es verlangt eine widerspruchsfreie Verknüpfung von Dienstleistern, Verträgen, Funktionen und Risikobewertungen über mehrere Tabellen hinweg.

Drei Fehlerbilder tauchen dabei immer wieder auf.

Fehler 1: Der LEI wird als Formalie behandelt

Jeder IKT-Drittdienstleister ist über einen Legal Entity Identifier zu identifizieren. Klingt trivial, ist es nicht.

Das Problem liegt in der Granularität. Verträge werden im Alltag mit „dem Anbieter" geschlossen, das Register verlangt aber die konkrete Rechtseinheit. Ein Vertrag mit der irischen Tochter eines US-Konzerns hat einen anderen LEI als der Rahmenvertrag mit der deutschen GmbH. Wer den Konzern-LEI der Muttergesellschaft einträgt, produziert einen Datensatz, der bei der Plausibilisierung auffällt.

Dazu kommt die Pflege: LEIs laufen ab. Ein Register mit einem Anteil abgelaufener LEIs signalisiert, dass die Daten seit der letzten Meldung nicht angefasst wurden.

Was hilft: Ziehen Sie den LEI beim Vertragsabschluss, nicht bei der Meldung. Nehmen Sie ihn in die Beschaffungscheckliste auf und prüfen Sie den Status im Jahresturnus gegen die GLEIF-Datenbank. Für Dienstleister ohne LEI hält das Format alternative Kennungen bereit – aber nur dort, wo sie zulässig sind.

Fehler 2: Auslagerungsketten werden abgeschnitten

Das Register erfasst nicht nur Ihre direkten Vertragspartner. Es erfasst die Kette der Unterauftragnehmer, die IKT-Dienstleistungen zur Unterstützung einer kritischen oder wichtigen Funktion erbringen – mit Rangfolge.

Hier entsteht der größte Aufwand und der häufigste blinde Fleck. Ihr SaaS-Anbieter betreibt seine Plattform bei einem Hyperscaler, nutzt einen spezialisierten Dienstleister für den Support und einen weiteren für das Monitoring. Rang 1, Rang 2, Rang 3. Ohne diese Information ist Ihr Konzentrationsrisiko nicht bewertbar – und genau darauf zielt die Aufsicht.

Institute, die hier nur den direkten Vertragspartner melden, unterschätzen ihr Risiko systematisch. Vier verschiedene Anbieter können am Ende auf derselben Cloud-Region liegen.

Was hilft: Verankern Sie die Auskunftspflicht über Unterauftragnehmer vertraglich, mit einer Aktualisierungspflicht bei Änderungen. Fragen Sie die Kette einmal jährlich strukturiert ab, mit einer Vorlage, die genau die Felder abbildet, die das Register verlangt. Und akzeptieren Sie keine Antwort, die auf einer Website-Unterseite endet.

Fehler 3: Kritische und wichtige Funktionen sind nicht sauber definiert

Fast jede Tabelle des Registers hängt an der Frage, ob eine Dienstleistung eine kritische oder wichtige Funktion unterstützt. Von dieser Einordnung hängen Ausstiegsstrategien, Auditrechte, vertragliche Mindestinhalte nach Art. 30 Abs. 3 DORA und der Umfang der Kettenerfassung ab.

In der Praxis ist die Funktionsliste oft aus zwei Quellen zusammengesetzt, die nie abgeglichen wurden: einer alten Auslagerungsübersicht aus der MaRisk-Welt und einer BIA aus dem Business Continuity Management. Das Ergebnis sind Funktionen, die im Register kritisch sind, in der BIA aber nicht auftauchen – oder umgekehrt.

Das fällt spätestens auf, wenn die Aufsicht das Register gegen den Notfallplan hält.

Was hilft: Eine einzige Funktionsliste als führende Quelle, abgeleitet aus der Business-Impact-Analyse, freigegeben von der Geschäftsleitung, referenziert von Register, Notfallplanung, Auslagerungsmanagement und Testkonzept. Wenn Sie an dieser Stelle aufräumen, lösen sich die meisten Inkonsistenzen im Register von selbst.

Die stille vierte Baustelle: das Register als Jahresprojekt

Der eigentliche Konstruktionsfehler ist organisatorisch. Viele Institute behandeln das Register als Meldung – einmal im Jahr, unter Zeitdruck, aus verteilten Excel-Dateien zusammengesetzt.

DORA meint es anders. Art. 28 verlangt ein aktuell gehaltenes Register, das auf Einzel-, teilkonsolidierter und konsolidierter Ebene geführt wird. Es ist ein Steuerungsinstrument, das bei jedem neuen Vertrag, jeder Vertragsänderung und jeder Beendigung fortgeschrieben wird.

Der Unterschied ist im Ergebnis sichtbar. Ein fortlaufend gepflegtes Register kostet in der Meldephase Stunden. Ein einmal jährlich rekonstruiertes Register kostet Wochen – und enthält trotzdem Fehler.

Was hilft: Hängen Sie die Registerpflege an den Beschaffungsprozess. Kein IKT-Vertrag wird unterschrieben, ohne dass die Registerfelder befüllt sind. Das ist der einzige Mechanismus, der ohne Disziplinappelle funktioniert.

Vor der Abgabe: die kurze Plausibilitätsprüfung

Bevor Sie melden, lohnt ein Durchgang entlang von fünf Fragen:

Hat jeder Vertrag in der Vertragstabelle einen zugeordneten Dienstleister, und existiert dieser Dienstleister auch in der Dienstleistertabelle?
Ist jede Dienstleistung, die als kritisch oder wichtig markiert ist, einer Funktion aus der freigegebenen Funktionsliste zugeordnet?
Sind alle LEIs formal gültig und aktiv?
Ist für jede kritische oder wichtige Funktion eine Auslagerungskette hinterlegt, oder ist die Einstufigkeit begründet?
Stimmen die Angaben zu Land der Leistungserbringung und Datenspeicherung mit dem überein, was im Vertrag steht?

Wer diese fünf Fragen sauber beantworten kann, hat kein perfektes Register – aber eines, das einer Prüfung standhält. Und das ist der Maßstab.