DORA-Informationsregister: die 15 offiziellen Meldebögen erklärt

Eines vorweg, ganz offen: Es gibt kein einziges Dokument der EBA, der ESMA oder der EIOPA, das Ihnen an einer Stelle alles Wesentliche zum DORA-Informationsregister vermittelt. Die Anforderungen verteilen sich auf den Verordnungstext von DORA, die gemeinsamen technischen Standards, den technischen Durchführungsstandard zu den Informationsregistern, die Dokumentation der xBRL-Taxonomie, die Portalvorgaben der jeweiligen nationalen Aufsichtsbehörde und eine Reihe von Q&As, die die ESAs auf Fragen aus der Branche veröffentlicht haben, von denen einige klarstellen, was die ursprünglichen Texte tatsächlich offengelassen hatten.

Dieser Leitfaden ist das Dokument, das ich mir gewünscht hätte, als Compliance-Teams mit ihren ersten Einreichungen begannen. Er führt alles zusammen: was das Informationsregister tatsächlich ist, wer es einreichen muss, welche Daten in jeden seiner 15 offiziellen Meldebögen gehören, wie die Meldebögen zusammenhängen, wie der Einreichungsprozess von Anfang bis Ende aussieht und wie die laufende Pflege nach der ersten Einreichung aussieht.

Wenn Sie zu Ende gelesen haben, besitzen Sie ein vollständiges Modell des Informationsregisters im Kopf, das über das Ausfüllen eines Meldebogens hinausgeht: Sie verstehen, warum jedes Feld existiert, was die Aufsicht erkennen möchte und wo die Fallen für Teams liegen, die dies zum ersten Mal durcharbeiten.

Was ist das DORA-Informationsregister?

Das Informationsregister (Register of Information, RoI) ist eine der zentralen operativen Anforderungen des Digital Operational Resilience Act. Es ist in Artikel 28 Absatz 3 DORA verankert, mit detaillierten technischen Vorgaben in den technischen Durchführungsstandards (ITS) zu den Informationsregistern, die EBA, ESMA und EIOPA gemeinsam veröffentlicht haben.

Im Kern ist das Informationsregister eine umfassende, strukturierte Aufzeichnung jedes IKT-Drittdienstleisters, auf den sich Ihre Organisation stützt, samt einer präzisen Zuordnung dessen, was diese Dienstleister tun, welche Verträge die Beziehung regeln und welche Ihrer internen Geschäftsfunktionen von ihren Leistungen abhängen. Die Aufsicht nutzt diese Daten vor allem für zwei Zwecke: um die Risikokonzentration im Finanzsystem zu verstehen (wenn ein Cloud-Anbieter ausfällt, welche Institute sind betroffen und wie stark?) und um die operative Resilienz und das Drittparteienrisiko-Management einzelner Institute zu beurteilen.

Ebenso wichtig ist die Abgrenzung. Das Informationsregister umfasst Folgendes nicht:

• Ein Lieferantenrisikoregister - es erfasst weder Risikowerte noch Risikoeinstufungen oder Maßnahmen zur Risikominderung je Dienstleister. Das ist eine eigene DORA-Pflicht.
• Ein Vertragsmanagementsystem - es erfasst bestimmte strukturierte Datenfelder zu Verträgen und dient dabei als Datenbestand statt als Ablage für die Vertragsdokumente selbst.
• Ein Compliance-Kontrollrahmenwerk - es verfolgt nicht, ob Sie die erforderlichen IKT-Sicherheitskontrollen umgesetzt haben. Das leistet Ihr Rahmenwerk für das IKT-Risikomanagement nach den Artikeln 5 bis 15.
• Ein einmaliges Prüfungsartefakt - es ist ein lebendes Register, das laufend zu pflegen und bei jeder wesentlichen Änderung innerhalb definierter Fristen zu aktualisieren ist.

Wer muss einreichen - und auf welcher Ebene?

Artikel 28 Absatz 3 DORA verpflichtet alle Finanzunternehmen im Anwendungsbereich der Verordnung, ein Informationsregister zu führen und einzureichen. Die vollständige Liste der erfassten Unternehmen steht in Artikel 2 Absatz 1 und umfasst unter anderem:

Kleinstunternehmen, nach EU-Recht definiert als Unternehmen mit weniger als 10 Beschäftigten und einem Jahresumsatz unter 2 Millionen Euro, profitieren in DORA durchgängig von Verhältnismäßigkeitsregeln. Wie sich die Verhältnismäßigkeit auf das Informationsregister auswirkt, hängt von Ihrem Unternehmenstyp ab. Prüfen Sie daher die Verhältnismäßigkeitsleitlinien der ESAs und die Vorgaben Ihrer nationalen Aufsichtsbehörde für Ihren konkreten Fall, bevor Sie über den Umfang Ihrer Einreichung entscheiden.

Einzel-, teilkonsolidierte und konsolidierte Einreichungen

Für Finanzgruppen sieht der technische Durchführungsstandard drei mögliche Einreichungsebenen vor. Zu verstehen, welche für Ihre Struktur gilt, ist vor dem Aufbau des Registers unverzichtbar, denn die Antwort bestimmt den Umfang der zu erhebenden Daten und wie die Unternehmen der Gruppe im Datenmodell zueinander stehen.

Gruppen müssen unter Umständen alle drei Ebenen gleichzeitig erzeugen: Einzeleinreichungen jedes Unternehmens, teilkonsolidierte Einreichungen der Teilgruppenmütter und eine konsolidierte Einreichung des obersten EU-Mutterunternehmens. Jede Einreichung muss ein in sich schlüssiges, konsistentes Datenpaket sein, das die Validierung eigenständig besteht.

Das Datenmodell: die 15 Meldebögen erklärt

Das Datenmodell des Informationsregisters ist der Kern der Anforderung und zugleich der Teil, den die meisten Leitfäden und Vorlagen am schlechtesten erklären. Es richtig zu verstehen, also über den Inhalt jedes Meldebogens hinaus auch die Beziehungen zwischen ihnen, trennt Teams, die das Register beim ersten Mal korrekt aufbauen, von Teams, die Monate in einer Schleife aus Wiedereinreichungen verbringen.

Verbringen Sie einen Tag mit dem Modell, bevor Sie ein einziges Feld erheben. Es ist ein kleines, erlernbares Schema, und sobald Sie die Beziehungen an einem Whiteboard zeichnen können, wird der Rest des Registers zur Dateneingabe. Teams, die diesen Schritt überspringen, sammeln die Daten, die sie zufällig haben, statt der Daten, die die Meldebögen verlangen, und sammeln dann erneut.

Verbringen Sie einen Tag mit dem Modell, bevor Sie ein einziges Feld erheben. Es ist ein kleines, erlernbares Schema, und sobald Sie die Beziehungen an einem Whiteboard zeichnen können, wird der Rest des Registers zur Dateneingabe. Teams, die diesen Schritt überspringen, sammeln die Daten, die sie zufällig haben, statt der Daten, die die Meldebögen verlangen, und sammeln dann erneut.

Das Rückgrat des Datenmodells sind die vertraglichen Vereinbarungen, die Sie mit IKT-Drittdienstleistern halten. Jede Vereinbarung trägt eine eindeutige Referenznummer, und diese Referenznummer ist der Schlüssel, der die übrigen Meldebögen zusammenhält. Um dieses Rückgrat herum erfassen Sie, wer jede Vereinbarung unterzeichnet hat, welche Ihrer Unternehmen die Dienstleistungen nutzen, welche Dienstleister dahinterstehen und wie deren Lieferketten aussehen, welche Funktionen die Dienstleistungen unterstützen und welche Bewertungen Sie für Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen vorgenommen haben.

Das Register besteht aus 15 offiziellen Meldebögen nach der Durchführungsverordnung (EU) 2024/2956 der Kommission. Ihre Codes reichen von B_01.01 bis B_99.01 und sind in Gruppen nach der Zahl hinter dem B_ geordnet: 01 (Unternehmen und Anwendungsbereich), 02 (vertragliche Vereinbarungen), 03 (Unterzeichner), 04 (Unternehmen, die Dienstleistungen nutzen), 05 (Dienstleister und Lieferkette), 06 (Funktionen), 07 (Bewertungen) und 99 (Definitionen).

Wie die Meldebögen zusammenhängen

Die Referenznummer jeder vertraglichen Vereinbarung (B_02.01) ist der Primärschlüssel, der das Register zusammenhält. Die spezifischen Angaben zu dieser Vereinbarung (B_02.02) hängen an derselben Referenznummer, ebenso die Unterzeichnerdatensätze (B_03.01 für Ihre Seite, B_03.02 für die Dienstleisterseite und B_03.03 für gruppeninterne Dienstleister) und der Nachweis, welche Unternehmen die Dienstleistungen nutzen (B_04.01). Jede Dienstleistung wird von einem in B_05.01 identifizierten Dienstleister erbracht, und die Kette der Unterauftragnehmer dahinter steht in B_05.02. Die Funktionen Ihrer Organisation sind in B_06.01 katalogisiert, und die Bewertungen für Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen stehen in B_07.01. B_01.01 identifiziert das Unternehmen, das das Register führt, B_01.02 und B_01.03 beschreiben Gruppenumfang und Zweigniederlassungen, und B_99.01 enthält die Definitionen, auf die Sie sich stützen.

Jede Referenz in dieser Kette muss sich auflösen. Ein einziger gebrochener Link, etwa eine Vereinbarung in B_02.02, deren Referenznummer in B_02.01 fehlt, oder eine Bewertung in B_07.01, die auf einen in B_05.01 fehlenden Dienstleister verweist, lässt die gesamte Einreichung in der Validierung scheitern.

Kernbegriffe: Kritikalität, Weiterverlagerung und Funktionen

Drei Begriffe im Datenmodell des Informationsregisters verdienen besondere Aufmerksamkeit, weil Teams sie am häufigsten falsch handhaben und weil Fehler hier über die Einreichung hinaus auch Ihre eigentliche Compliance-Aufstellung betreffen.

Kritische oder wichtige Funktionen (CIFs)

Der Begriff der "kritischen oder wichtigen Funktion" ist in DORA in Artikel 3 Nummer 22 definiert und knüpft unmittelbar an die EBA-Leitlinien zu Auslagerungen an. Eine Funktion ist kritisch oder wichtig, wenn ihre Störung die finanzielle Leistungsfähigkeit des Unternehmens oder die Solidität beziehungsweise Kontinuität seiner Dienstleistungen und Tätigkeiten erheblich beeinträchtigen würde.

In der Praxis bedeutet das, dass Ihre Organisation jede Geschäftsfunktion förmlich anhand dieser Kriterien bewerten und die Bewertung dokumentieren muss. Das Informationsregister hält das Ergebnis dieser Bewertungen im Funktionsmeldebogen (B_06.01) fest. Häufige Fehler sind: das Kritikalitätsmerkmal zu eng anzuwenden (die Zahl qualifizierender Funktionen zu unterschätzen und damit die IKT-Abhängigkeit zu klein darzustellen), es zu weit anzuwenden (Funktionen überzuklassifizieren und damit unnötigen Meldeumfang zu erzeugen) oder die Bewertungsmethodik hinter jeder Einstufung ohne Dokumentation zu lassen, nach der die Aufsicht fragen wird.

Ketten der Weiterverlagerung

Artikel 28 Absatz 2 verpflichtet Finanzunternehmen, Weiterverlagerungen zu identifizieren und zu dokumentieren, also Konstellationen, in denen Ihr direkter IKT-Dienstleister einen Teil der Leistung an eine andere Partei weitervergibt. Der Lieferketten-Meldebogen (B_05.02) bildet das ab und erfasst den Rang der Unterauftragsvergabe hinter jeder Dienstleistung. In der Praxis heißt das: Sie müssen nicht nur Ihre Dienstleister kennen, sondern auch deren Dienstleister, zumindest bei Vereinbarungen zur Unterstützung kritischer oder wichtiger Funktionen.

Das ist einer der am dünnsten befüllten Teile erster Einreichungen, aus naheliegendem Grund: Für Daten zur Weiterverlagerung müssen Ihre direkten Dienstleister Informationen über ihre Lieferketten offenlegen, die sie womöglich ungern teilen. Ihr Hebel ist vertraglich: Artikel 30 Absatz 2 Buchstabe a verlangt, dass die Vereinbarung angibt, ob die Weitervergabe einer IKT-Dienstleistung zur Unterstützung einer kritischen oder wichtigen Funktion zulässig ist und, falls ja, unter welchen Bedingungen; die Delegierte Verordnung (EU) 2025/532 der Kommission legt fest, was diese Bedingungen abdecken müssen. Artikel 30 Absatz 2 Buchstabe h, der dafür bisweilen angeführt wird, betrifft Kündigungsrechte und Kündigungsfristen statt der Offenlegung von Lieferketten. Die Ausübung dieses Rechts kostet dennoch Zeit und führt gelegentlich zu Streit. Es ist dringend ratsam, diese Datenerhebung früh zu beginnen, idealerweise sechs Monate vor Ihrer ersten Einreichung.

Setzen Sie auch intern die Erwartungen richtig. Das Register ist einfach, bis Sie an die Weiterverlagerung kommen, ab da wird es von einem Datenproblem zu einem Problem der Beziehungspflege. Große Dienstleister antworten mit einem Standardpaket und einer langen Warteschlange. Kleine Dienstleister kennen ihre eigenen Viertparteien oft zu wenig, um überhaupt antworten zu können. Kalkulieren Sie Monate des Nachfassens statt Tage der Dateneingabe ein und verankern Sie die Offenlegungspflicht in jedem Vertrag, den Sie zwischenzeitlich verlängern.

Setzen Sie auch intern die Erwartungen richtig. Das Register ist einfach, bis Sie an die Weiterverlagerung kommen, ab da wird es von einem Datenproblem zu einem Problem der Beziehungspflege. Große Dienstleister antworten mit einem Standardpaket und einer langen Warteschlange. Kleine Dienstleister kennen ihre eigenen Viertparteien oft zu wenig, um überhaupt antworten zu können. Kalkulieren Sie Monate des Nachfassens statt Tage der Dateneingabe ein und verankern Sie die Offenlegungspflicht in jedem Vertrag, den Sie zwischenzeitlich verlängern.

Die Kette Dienstleister - Vertrag - Dienstleistung - Funktion

Das wichtigste strukturelle Prinzip des Informationsregisters ist, dass jede IKT-Vereinbarung vom Dienstleister bis zur internen Funktion nachvollziehbar sein muss. Das entspricht dem eigentlichen analytischen Ziel der Aufsicht: für jede Geschäftsfunktion genau zu verstehen, von welchen externen Parteien Sie abhängen und über welche vertraglichen Beziehungen. Bricht diese Kette irgendwo in Ihren Daten, verfehlt das Register seinen Zweck, selbst wenn es die technische Validierung besteht.

Der Einreichungsprozess

Format

Das Informationsregister ist im xBRL-CSV-Format einzureichen, einem strukturierten, maschinenlesbaren Format nach dem Standard von XBRL International, das die ESAs für DORA profiliert haben. Ihre Einreichung ist ein ZIP-Archiv mit je einer CSV-Datei pro Tabelle des Datenmodells. Jede CSV-Datei muss der XBRL-Taxonomie entsprechen, die die ESAs veröffentlichen und aktualisieren. Die Taxonomie definiert Feldnamen, Datentypen, kontrollierte Wertelisten und die Beziehungsbedingungen zwischen den Tabellen.

Eine Einreichung in Excel, als PDF oder in einem anderen Format ist nicht vorgesehen. Die Portale der nationalen Aufsichtsbehörden akzeptieren ausschließlich das xBRL-CSV-ZIP. Das ist eine der praktisch folgenreichsten Anforderungen von DORA: Organisationen, die ihr Register in Excel führen, müssen einen Konvertierungs- und Validierungsprozess durchlaufen, der beim Export ein erhebliches Fehlerrisiko mit sich bringt.

Termine und Fristen

Die jährliche Einreichungsfrist unterscheidet sich je nach Aufsichtsbehörde. Die meisten haben Fristen im ersten Quartal des Kalenderjahres gesetzt, mit dem 31. Dezember des Vorjahres als Stichtag. Ihr Register muss also den Stand Ihrer IKT-Vereinbarungen zum 31. Dezember abbilden. Prüfen Sie die technischen Vorgaben Ihrer Aufsichtsbehörde für die genaue Frist, die für Ihren Unternehmenstyp und Ihre Rechtsordnung gilt.

Die zentrale operative Konsequenz: Sie können das Register nicht im Januar für eine Frist im März aufbauen, wenn Ihre Datenerhebungsprozesse noch nicht laufen. Allein die Daten zur Weiterverlagerung können Monate in Anspruch nehmen. Organisationen, die das Informationsregister als Jahresendaufgabe behandeln, reichen regelmäßig unvollständige Daten ein oder bitten um Fristverlängerung.

Eine Frist im ersten Quartal bei einem Stichtag zum 31. Dezember klingt großzügig, bis man die Schritte zählt: erheben, abgleichen, die Fachbereiche die Kritikalität bestätigen lassen, das Paket bauen, an der Validierung scheitern, korrigieren, erneut einreichen. Die knappe Ressource ist die Aufmerksamkeit anderer Menschen, und zum Jahreswechsel haben sie davon am wenigsten übrig.

Eine Frist im ersten Quartal bei einem Stichtag zum 31. Dezember klingt großzügig, bis man die Schritte zählt: erheben, abgleichen, die Fachbereiche die Kritikalität bestätigen lassen, das Paket bauen, an der Validierung scheitern, korrigieren, erneut einreichen. Die knappe Ressource ist die Aufmerksamkeit anderer Menschen, und zum Jahreswechsel haben sie davon am wenigsten übrig.

Das Portal der Aufsichtsbehörde

Jede nationale Aufsichtsbehörde eines EU-Mitgliedstaats betreibt ihr eigenes Einreichungsportal. Das Portal verlangt eine Registrierung, und Einreichungen erfolgen durch autorisierte Nutzer, deren Identität an das meldende Unternehmen gebunden ist. Bei der Einreichung durchläuft das Portal seine Validierungssequenz - Paketprüfung, Taxonomiekonformität, referenzielle Integrität, kontrollierte Werte und fachliche Regeln - und gibt entweder eine Empfangsbestätigung oder eine Rückmeldungsdatei mit Fehlercodes für jeden Fehlschlag zurück.

Pflegepflichten über das ganze Jahr

Dieser Aspekt überrascht Compliance-Teams am meisten, vor allem jene, die Compliance vor allem als stichtagsbezogene Tätigkeit im Rhythmus von Prüfzyklen kennen. Das Informationsregister ist ein lebendes Register mit laufenden Pflegepflichten, das über die jährliche Erstellung hinausreicht.

Die Lösung ist organisatorisch statt technisch, und sie ist die wertvollste Entscheidung der gesamten Übung: Machen Sie das Register zu einem verpflichtenden Schritt beim Vertragsabschluss. Wenn der Einkauf einen neuen IKT-Vertrag erst schließen kann, sobald die Registerfelder gefüllt sind, wird aus der Pflege statt eines Projekts eine Gewohnheit. Jeder andere Ansatz hängt daran, dass sich jemand erinnert.

Die Lösung ist organisatorisch statt technisch, und sie ist die wertvollste Entscheidung der gesamten Übung: Machen Sie das Register zu einem verpflichtenden Schritt beim Vertragsabschluss. Wenn der Einkauf einen neuen IKT-Vertrag erst schließen kann, sobald die Registerfelder gefüllt sind, wird aus der Pflege statt eines Projekts eine Gewohnheit. Jeder andere Ansatz hängt daran, dass sich jemand erinnert.

Artikel 28 Absatz 3 verpflichtet Finanzunternehmen, ihre Aufsichtsbehörde bei wesentlichen Änderungen an IKT-Vereinbarungen zu informieren. Der technische Durchführungsstandard legt Fristen für die Aktualisierung des Registers nach wesentlichen Änderungen fest, und "wesentlich" ist weiter gefasst, als viele Compliance-Teams zunächst annehmen. Die folgenden Ereignisse erfordern jeweils eine Aktualisierung des Registers:

Praktisch bedeutet das, dass das Informationsregister eine Person oder Funktion als Eigentümer braucht, die ganzjährig in das Vertragslebenszyklus- und Einkaufsmanagement der Organisation eingebunden ist. Ein Compliance-Team, das das Register nur einmal im Jahr anfasst, stellt regelmäßig fest, dass es zum Einreichungszeitpunkt die Realität nicht mehr abbildet und dass das Aufholen in den Wochen vor der Frist hektisch, fehleranfällig und oft unvollständig verläuft.

Häufige Fehler beim ersten Mal

Teams, die ihr erstes Informationsregister aufbauen, laufen durchweg in dieselben strukturellen Fehler. Hier sind die folgenreichsten und wie Sie sie vermeiden.

Wenn Sie nur einen davon angehen, dann den ersten. Die Wahl Ihres führenden Systems treffen Sie einmal, nebenbei, in Woche eins, und leben dann das ganze Programm damit.

Wenn Sie nur einen davon angehen, dann den ersten. Die Wahl Ihres führenden Systems treffen Sie einmal, nebenbei, in Woche eins, und leben dann das ganze Programm damit.

Werkzeuge und Vorgehensweisen

Es gibt drei grundsätzliche Wege, das Informationsregister aufzubauen und zu pflegen. Jeder hat ein anderes Risikoprofil, und die richtige Wahl hängt von Größe und Komplexität Ihres Registers ab.

Sobald Sie ein kleines, einfaches Register hinter sich lassen, wird die Argumentation für eine spezialisierte Plattform schnell zwingend. Die für das Informationsregister wichtigsten Eigenschaften sind: erzwungene referenzielle Integrität zwischen den Tabellen, automatisierte GLEIF-LEI-Prüfung, harte Vorgaben für Felder mit kontrollierten Werten, ein xBRL-CSV-Export, der vor dem Paketieren die aktuellen EBA-Validierungsregeln ausführt, und eine Nachverfolgung der unterjährigen Änderungen. Das sind die Fähigkeiten, die ein zur Einreichung gebautes Register von einem Register unterscheiden, das vollständig wirkt, bis das Portal der Aufsichtsbehörde etwas anderes meldet.

Sie verwalten mehr als einen Rechtsträger? Sehen Sie, wie Venvera Compliance-Software für Unternehmensgruppen abbildet: Richtlinien einmal auf Konzernebene verfassen und jede Tochtergesellschaft sie mit eigenen Nachweisen belegen lassen.

Häufig gestellte Fragen