Was muss im DORA-Informationsregister (Register of Information) stehen?

Das Informationsregister ist die strukturierte Bestandsaufnahme aller vertraglichen Vereinbarungen eines Finanzunternehmens über die Nutzung von IKT-Diensten. Die Rechtsgrundlage steht in Artikel 28 Absatz 3 der Verordnung (EU) 2022/2554 (DORA). Welche Datenfelder konkret zu erfassen sind, legt der technische Durchführungsstandard fest: die Durchführungsverordnung (EU) 2024/2956 der Kommission vom 29. November 2024, erlassen auf Basis von Artikel 28 Absatz 9 DORA. Dieser Beitrag ordnet ein, welche Inhalte das Register umfassen muss, wie die ITS-Templates aufgebaut sind und welche Fristen für Finanzunternehmen unter Aufsicht der BaFin gelten.

Rechtsgrundlage: Art. 28 Abs. 3 DORA

Artikel 28 gehört zu Kapitel V Abschnitt I von DORA und regelt die allgemeinen Grundsätze für das Management des Risikos durch IKT-Drittdienstleister. Absatz 3 verpflichtet Finanzunternehmen, ein Informationsregister zu führen und laufend zu aktualisieren, das sämtliche vertraglichen Vereinbarungen über die Nutzung von IKT-Diensten abbildet. Den Wortlaut der Verordnung können Sie in der konsolidierten Fassung auf EUR-Lex nachlesen.

Der Pflichtenkreis umfasst drei Ebenen: das einzelne Unternehmen, die teilkonsolidierte und die konsolidierte Ebene. Für Gruppen bedeutet das, dass neben den Einzelregistern auch konsolidierte Sichten zu erstellen sind. Maßgeblich ist dabei nicht nur, welche externen Anbieter genutzt werden, sondern auch, welche Funktionen diese unterstützen und ob es sich dabei um kritische oder wichtige Funktionen handelt.

Eine zentrale Unterscheidung des Absatzes 3 betrifft genau diese Funktionen. Das Register muss erkennbar machen, welche vertraglichen Vereinbarungen IKT-Dienste zur Unterstützung kritischer oder wichtiger Funktionen abdecken und welche Vereinbarungen das nicht tun. Diese Trennung ist nicht bloß formal: Sie steuert, welche zusätzlichen Sorgfaltspflichten greifen, und sie liefert den Aufsichtsbehörden die Datenbasis, um Abhängigkeiten im Finanzsektor zu bewerten.

Zweck des Registers

Das Informationsregister erfüllt aus aufsichtlicher Sicht zwei Funktionen. Zum einen ist es ein internes Steuerungsinstrument: Erst die vollständige Übersicht über alle IKT-Dienstleister erlaubt es, Konzentrationen und geografische Abhängigkeiten zu erkennen. Wenn etwa mehrere kritische Funktionen an einem einzigen Cloud-Anbieter hängen, wird dieses Klumpenrisiko im Register sichtbar.

Zum anderen dient das Register der europäischen Aufsicht als Datengrundlage. Die BaFin beschreibt in ihrem Fachartikel vom 15. Januar 2025, dass die Daten genutzt werden, um kritische IKT-Drittdienstleister zu bestimmen. Das sind Anbieter, von denen ein bedeutender Teil des europäischen Finanzsektors abhängig ist. Solche Anbieter werden dem Überwachungsregime der Europäischen Aufsichtsbehörden unterstellt. Das Register ist damit das Bindeglied zwischen der dezentralen Dokumentation in den einzelnen Häusern und der zentralen Risikoanalyse auf EU-Ebene.

Welche Inhalte die ITS-Templates vorgeben

Die inhaltliche Ausgestaltung überlässt DORA nicht den Unternehmen, sondern standardisiert sie über die Durchführungsverordnung (EU) 2024/2956. Diese wurde am 29. November 2024 erlassen und im Amtsblatt der Europäischen Union veröffentlicht; den Volltext finden Sie auf EUR-Lex. Die Verordnung legt die Standardvorlagen fest, in denen die Informationen einheitlich zu erfassen sind. Erst diese Standardisierung macht die Register zwischen Tausenden Finanzunternehmen vergleichbar und maschinell auswertbar.

Die Vorlagen sind in mehrere zusammenhängende Tabellen gegliedert, die jeweils eine Dimension des Drittparteienrisikos abbilden. Inhaltlich lassen sich die erfassten Angaben in folgende Blöcke einordnen:

Die Verordnung verlangt also nicht nur eine Liste von Lieferanten, sondern eine relationale Abbildung: Jeder Vertrag verweist auf einen Dienstleister, jeder Dienst auf eine Funktion, und die Lieferkette wird über Unterauftragnehmer abgebildet. Die Tabellen sind über gemeinsame Schlüssel miteinander verknüpft, sodass sich Abhängigkeiten über mehrere Ebenen hinweg nachvollziehen lassen.

Identifikatoren: LEI und EUID

Ein praktisch bedeutsames Detail betrifft die Identifikation der Drittdienstleister. Rechtsträger sind über eine gültige und aktive Legal Entity Identifier (LEI) zu erfassen oder über die European Unique Identifier (EUID) nach Artikel 16 der Richtlinie (EU) 2017/1132; soweit beide Identifikatoren verfügbar sind, sind beide anzugeben. Diese Vorgabe ist anspruchsvoll, weil sie eine vorgelagerte Stammdatenpflege erfordert. Fehlt einem Dienstleister mit Sitz in der EU eine LEI, kann er über die EUID identifiziert werden; eine fiktive Dummy-LEI lässt die BaFin nicht zu. Handeln natürliche Personen als Dienstleister, kommen laut BaFin Handelsregisternummer, Umsatzsteuer-Identifikationsnummer, Reisepass- oder Personalausweisnummer als Kennung in Betracht. Die Verfügbarkeit der Identifikatoren früh zu prüfen, vermeidet Lücken beim Zusammenstellen des Registers.

Wie die Standardvorlagen entstanden sind

Die heute geltenden Vorlagen sind das Ergebnis eines mehrstufigen Verfahrens. Die Europäischen Aufsichtsbehörden (EBA, ESMA und EIOPA) entwickelten den Entwurf des technischen Durchführungsstandards und übermittelten ihn am 17. Januar 2024 an die Europäische Kommission. Vorausgegangen war eine öffentliche Konsultation. Die Kommission nahm den Entwurf jedoch nicht unverändert an, sondern lehnte ihn am 3. September 2024 ab. Streitpunkt war die zunächst zwingende Verwendung der LEI zur Identifikation von IKT-Drittdienstleistern.

Die Aufsichtsbehörden reagierten mit einer Stellungnahme vom 15. Oktober 2024. Darin hielten sie die zusätzliche EUID für unnötig komplex und warnten vor Mehraufwand und schlechterer Datenqualität; für den Fall, dass die Kommission an der EUID festhält, beschrieben sie die dann nötigen Anpassungen des Entwurfs. Durchgesetzt hat sich die Lösung der Kommission: Nach Art. 3 Abs. 5 der Durchführungsverordnung (EU) 2024/2956 sind IKT-Drittdienstleister über die LEI oder die EUID zu identifizieren, und wer über beide verfügt, muss beide angeben. Einen Vorrang der LEI sieht die Verordnung nicht vor. Die Durchführungsverordnung (EU) 2024/2956 wurde am 29. November 2024 erlassen und am 2. Dezember 2024 im Amtsblatt veröffentlicht. Den Hintergrund dazu dokumentieren die Aufsichtsbehörden in ihrer gemeinsamen Mitteilung. Für die Praxis bedeutet das: Die zunächst befürchtete LEI-Pflicht ohne Alternative ist nicht Gesetz geworden, die Identifikator-Anforderung bleibt aber anspruchsvoll.

Lieferketten und Unterauftragnehmer

Ein Schwerpunkt der Vorlagen liegt auf der Transparenz über die gesamte Leistungskette. Es genügt nicht, den direkten Vertragspartner zu erfassen. Die Standardvorlagen verlangen Angaben zu den Unterauftragnehmern, die einen IKT-Dienst tatsächlich erbringen. Damit wird die häufige Konstellation abgebildet, in der ein Finanzunternehmen mit Anbieter A kontrahiert, dieser aber Teile der Leistung an Anbieter B auslagert, der seinerseits eine Cloud-Infrastruktur eines dritten Anbieters nutzt.

Die rechtliche Verankerung der Subdienstleister-Anforderungen ergibt sich aus Artikel 28 und 30 DORA sowie aus einem eigenen technischen Standard zum Subcontracting, den die Aufsichtsbehörden gesondert ausgearbeitet haben. Für das Informationsregister ist entscheidend, dass die Kette bis zu der Stelle nachvollziehbar bleibt, an der ein zur Unterstützung kritischer oder wichtiger Funktionen genutzter Dienst erbracht wird. Wo diese Tiefe in den eigenen Vertragsunterlagen nicht abgebildet ist, entsteht ein praktischer Erhebungsaufwand, der nicht unterschätzt werden sollte.

Aufbau in der Praxis

Der Weg zu einem prüffähigen Register lässt sich grob in mehrere Schritte gliedern. Die folgende Reihenfolge ist ein Vorschlag, keine rechtlich vorgeschriebene Abfolge:

1. Vertragsinventur: Alle Verträge über IKT-Dienste zusammentragen, einschließlich konzerninterner Vereinbarungen und solcher, die nur Teilleistungen betreffen.
2. Funktionsklassifizierung: Für jede unterstützte Funktion festlegen, ob sie kritisch oder wichtig ist, und die Bewertung dokumentieren.
3. Identifikatoren beschaffen: Für jeden Rechtsträger LEI und, soweit verfügbar, EUID erheben; fehlende Identifikatoren rechtzeitig adressieren.
4. Lieferkette abbilden: Unterauftragnehmer ermitteln, die kritische oder wichtige Funktionen mittragen.
5. Befüllung und Validierung: Daten in die Standardvorlagen überführen und gegen die Validierungsregeln der Aufsichtsbehörden prüfen.

Die Schritte zwei und vier erfordern fachliche Bewertungen und Informationen, die über die reinen Vertragsdokumente hinausgehen. Eine saubere Funktionsklassifizierung zahlt sich über das Register hinaus aus, weil sie auch für andere DORA-Pflichten herangezogen wird, etwa für die vertraglichen Mindestinhalte nach Artikel 30.

Format und Validierung

Die BaFin erwartet die Einreichung grundsätzlich als strukturierte Datei, die der Taxonomie der Europäischen Aufsichtsbehörden entspricht. Alternativ akzeptiert sie eine speziell strukturierte Excel-Vorlage, sofern die vorgegebene Struktur eingehalten und die Validierungsregeln der ESAs beachtet werden. Die Vorgaben erläutert die BaFin in ihrem Fachartikel vom 15. Januar 2025; technische Einzelfragen beantwortet sie in ihren FAQ, etwa zur Identifikation von IKT-Drittdienstleistern über LEI und EUID.

Fristen und Einreichung

Finanzunternehmen unter Aufsicht der BaFin reichten ihr Informationsregister erstmals bis spätestens 28. April 2025 ein. Diese Erstvorlage hat die BaFin in ihrem Fachartikel vom 15. Januar 2025 angekündigt. Über den einmaligen Ersttermin hinaus sieht der Mechanismus eine wiederkehrende, jährliche Bereitstellung vor. Die zuständige Behörde kann das vollständige Register zudem auf Anfrage anfordern.

Zu beachten ist, dass das Informationsregister nicht mit den ergänzenden Anzeigepflichten zu verwechseln ist, die Artikel 28 ebenfalls vorsieht. Geplante vertragliche Vereinbarungen über IKT-Dienste zur Unterstützung kritischer oder wichtiger Funktionen sind der Aufsicht gesondert anzuzeigen. Register und Anzeigepflicht greifen ineinander, sind rechtlich aber verschiedene Instrumente. Wer beide Pflichten sauber trennt, vermeidet Doppelarbeit und stellt sicher, dass die Aufsicht die jeweils erwarteten Daten im richtigen Format erhält.

Einordnung für mittelständische IT-Verantwortliche

Für IT-Leitungen im Mittelstand stellt sich zunächst die Frage der Betroffenheit. DORA gilt für die in Artikel 2 aufgezählten Finanzunternehmen, von Kreditinstituten über Zahlungsdienstleister bis zu bestimmten Versicherern und Wertpapierfirmen. Wer in diesen Anwendungsbereich fällt, muss das Register unabhängig von der Unternehmensgröße führen; Erleichterungen für kleinere Einheiten betreffen andere Teile des Rahmenwerks, nicht die grundsätzliche Registerpflicht aus Artikel 28 Absatz 3.

Der praktische Aufwand entsteht weniger durch die Datenmenge als durch die geforderte Datenqualität. Verträge müssen zentral auffindbar, Funktionen sauber als kritisch oder wichtig klassifiziert und Dienstleister eindeutig identifiziert sein. Üblicherweise wird empfohlen, die Funktionsklassifizierung als ersten Schritt anzugehen, weil sie die Abgrenzung im gesamten Register steuert. Wo die Einstufung einer Funktion fachlich unklar ist, sollte die Bewertung dokumentiert werden, um sie gegenüber der Aufsicht nachvollziehbar zu machen.

Wie genau die Betroffenheit und die kritischen Funktionen im Einzelfall zu beurteilen sind, hängt vom konkreten Geschäftsmodell ab und lässt sich nicht pauschal beantworten. Der kostenlose DORA-Check ordnet die Betroffenheit im Einzelfall ein.

Häufige Fragen

Müssen auch konzerninterne IKT-Dienste ins Register?

Ja. Artikel 28 Absatz 3 DORA stellt auf alle vertraglichen Vereinbarungen über die Nutzung von IKT-Diensten ab. Die Standardvorlagen der DVO (EU) 2024/2956 erfassen Dienste direkter Drittdienstleister ebenso wie die zugehörige Kette von Unterauftragnehmern. Eine pauschale Ausnahme allein wegen konzerninterner Erbringung sieht die Regelung nicht vor.

Was unterscheidet kritische von wichtigen Funktionen?

Die Begriffe knüpfen an die Definition aus DORA an. Entscheidend ist, ob eine Störung der Funktion die finanzielle Leistungsfähigkeit, die Solidität oder die Fortführung der Geschäftstätigkeit erheblich beeinträchtigen würde. Das Register muss Vereinbarungen, die solche Funktionen unterstützen, ausdrücklich von den übrigen unterscheiden. Bei Unschärfen in der Einstufung ist eine dokumentierte Bewertung sinnvoll.

Reicht eine selbst gebaute Excel-Tabelle aus?

Die BaFin akzeptiert eine speziell strukturierte Excel-Vorlage als Alternative zur Taxonomie-konformen Datei, verlangt aber die Einhaltung der vorgegebenen Struktur und der Validierungsregeln der Europäischen Aufsichtsbehörden. Eine frei gestaltete Tabelle ohne diese Struktur erfüllt die Anforderungen nicht. Maßgeblich ist die formale Konformität, nicht die optische Vollständigkeit.

Wie oft ist das Register zu melden?

Das Register ist fortlaufend zu aktualisieren und der zuständigen Behörde auf Anfrage bereitzustellen. Für Finanzunternehmen unter BaFin-Aufsicht war die erste Einreichung bis zum 28. April 2025 vorgesehen; die Bereitstellung erfolgt darüber hinaus in einem wiederkehrenden, jährlichen Rhythmus. Die jeweils aktuellen Modalitäten veröffentlicht die BaFin in ihrem Themenbereich.

Warum war die LEI-Pflicht zunächst umstritten?

Die Kommission lehnte den ersten Entwurf des technischen Standards im September 2024 ab, weil sie die ausschließliche LEI-Pflicht für zu eng hielt und eine Wahlmöglichkeit zwischen LEI und EUID forderte. Die Aufsichtsbehörden hielten die zusätzliche EUID für unnötig komplex, die Kommission setzte sich jedoch durch: Nach Art. 3 Abs. 5 der Durchführungsverordnung (EU) 2024/2956 sind IKT-Drittdienstleister über die LEI oder die EUID zu identifizieren; liegen beide vor, sind beide anzugeben.