Worum es geht
Art. 28 Abs. 3 DORA verlangt von jedem Finanzunternehmen ein Register aller Vereinbarungen über die Nutzung von IKT-Dienstleistungen durch IKT-Drittdienstleister. Die Durchführungsverordnung (EU) 2024/2956 legt fest, wie dieses Register aussieht: als Satz verbundener Meldebögen, die auf gemeinsamen Kennungen aufbauen.
Einmal jährlich wird es an die Aufsicht übermittelt. Für Unternehmen unter Aufsicht der BaFin läuft das über die Melde- und Veröffentlichungsplattform (MVP), im Fachverfahren Digital Operational Resilience Act (DORA). Die maßgebliche Seite dazu: Informationsregister und Anzeigepflichten bei der BaFin; dort wird zu Jahresbeginn auch der Einreichungszeitraum veröffentlicht.
Tabelle seitlich wischbar
| Was | Wie |
|---|---|
| Stichtag der Daten | 31. Dezember des Vorjahres. Der Stand an diesem Tag wird gemeldet, nicht der Stand am Tag der Einreichung. |
| Frist | Die BaFin verlangt, den Einreichungsprozess bis spätestens zum 31. März vollständig und fehlerfrei zu durchlaufen. Maßgeblich ist damit nicht der Tag der Übertragung, sondern der Tag, an dem die Validierung besteht. |
| Weg | Ausschließlich über das MVP-Fachverfahren DORA. Daneben steht ein Testverfahren zur Verfügung, mit dem man die Datei vorab prüfen lassen kann. |
| Format | Strukturierte Datei im xBRL-Format nach der ESA-Taxonomie oder die Excel-Vorlage der BaFin. |
| Wann gilt es als eingereicht | Erst wenn die Übermittlung die Validierungsregeln der ESAs besteht. Eine abgegebene, aber fehlerhafte Datei erfüllt die Pflicht nicht. |
| Bei Fehlern | Es gibt ein Fehlerprotokoll. Die Fehler sind kurzfristig zu beheben und das Register erneut einzureichen. |
Der Satz, den man sich merken sollte Eingereicht ist nicht angenommen. Wer am letzten Tag vor der Frist überträgt und dann ein Fehlerprotokoll bekommt, hat keine Zeit mehr zum Korrigieren. Planen Sie die erste Übertragung so früh, dass mindestens zwei Korrekturläufe hineinpassen, und nutzen Sie vorher das Testverfahren.
Der Aufbau: welcher Bogen was aufnimmt
Die Meldebögen sind über Kennungen miteinander verbunden. Wer das Prinzip einmal verstanden hat, sieht auch, warum die meisten Validierungsfehler Verknüpfungsfehler sind.
Tabelle seitlich wischbar
| Bogen | Inhalt |
|---|---|
| B_01.01 B_01.02 B_01.03 |
Das meldende Unternehmen und seine Gruppe. Wer meldet, in welcher Funktion, für welchen Konsolidierungskreis. Hier stehen die eigenen Stammdaten samt Kennung. |
| B_02.01 B_02.02 B_02.03 |
Die Vereinbarungen. Jeder Vertrag mit Referenznummer, Art der Vereinbarung, Start- und Enddatum, Kündigungsfristen, anwendbarem Recht und Vertragswert. Die Referenznummer ist der Schlüssel, auf den alle anderen Bögen verweisen. |
| B_03.01 B_03.02 B_03.03 |
Die Vertragsparteien und ihre Rolle: wer ist Dienstleister, wer Unterauftragnehmer, in welcher Kette. |
| B_04.01 | Zuordnung der Dienstleistung zur Unternehmensfunktion. Hier entscheidet sich, ob ein Vertrag eine kritische oder wichtige Funktion stützt. |
| B_05.01 B_05.02 |
Die IKT-Drittdienstleister selbst. Name, Kennung (LEI oder eine andere zugelassene Codeart), Land, Art der erbrachten Dienstleistung nach Anhang III (S01 bis S19), Konzernzugehörigkeit. |
| B_06.01 | Die Funktionen des Hauses mit Kennung, Beschreibung und Einstufung als kritisch oder wichtig, samt Begründung und Datum der letzten Bewertung. |
| B_07.01 | Die Bewertung der IKT-Dienstleistungen, die kritische oder wichtige Funktionen stützen: Substituierbarkeit, Wiederherstellungszeiten, Alternativen, Ausstiegsplan. |
Das Prinzip B_06.01 trägt die Funktionen, B_05.01 die Anbieter, B_02.01 die Verträge; B_04.01 verknüpft sie. Alle Einstufungen und Bewertungen hängen an dieser Verknüpfung. Deshalb kann man das Register nicht sinnvoll befüllen, bevor die Funktionen des Hauses bestimmt sind: Ohne B_06.01 ist B_04.01 geraten, und mit B_04.01 fällt auch B_07.01.
Der Weg, Schritt für Schritt
-
Im Oktober: Bestandsabgleich, nicht Datenerhebung
Der Fehler ist, im Januar mit der Erhebung anzufangen. Wer im Oktober abgleicht, hat noch Zeit, fehlende Angaben beim Dienstleister zu erfragen. Und Dienstleister antworten nicht in drei Tagen.
Konkret abgleichen: Kreditorenbuchhaltung gegen Vertragsakte gegen Register. Jede Zahlung an einen IT-Lieferanten, die keinen Registereintrag hat, ist eine Frage. Beispiel 1 zeigt, was dabei typischerweise auftaucht.
-
Die Kennungen besorgen: das ist der lange Weg
Für jeden Dienstleister braucht das Register eine Kennung. Vorgesehen ist der LEI; wo es keinen gibt, eine andere zugelassene Codeart. Kleine Anbieter haben keinen LEI und verstehen die Frage zunächst nicht.
Rechnen Sie mit mehreren Wochen. Das ist der Posten, der jedes Jahr unterschätzt wird und der nicht abkürzbar ist, weil die Angabe von außen kommen muss.
-
Die Funktionen bestätigen, nicht neu erfinden
B_06.01 verlangt zu jeder Funktion die Einstufung und das Datum der letzten Bewertung. Wenn dieses Datum zwei Jahre alt ist, fragt der Prüfer, ob zwischendurch nichts passiert ist. Ein kurzer, dokumentierter Review vor dem Stichtag löst das.
-
Stichtag 31. Dezember: den Stand einfrieren
Legen Sie fest, dass Änderungen nach dem 31. Dezember nicht mehr in diese Meldung einfließen. Ohne diesen Schnitt läuft Ihnen der Datenstand während der Erstellung weg, und Sie melden eine Mischung aus zwei Zeitpunkten.
-
Im Januar: Testverfahren nutzen
Die Validierungsregeln der ESAs prüfen mehr als Pflichtfelder: Sie prüfen die Verknüpfungen zwischen den Bögen und die Zulässigkeit von Werten. Das findet man nicht durch Draufsehen. Eine Probeübertragung im Testverfahren ist der einzige verlässliche Weg.
-
Früh einreichen, nicht im März
Erste Übertragung so früh wie möglich, damit zwei Korrekturläufe hineinpassen. Das Fehlerprotokoll durchgehen, korrigieren, erneut übertragen, bis die Validierung besteht.
-
Danach: den Stand archivieren
Legen Sie die eingereichte Datei samt Übertragungsbestätigung und Fehlerprotokoll revisionsfest ab. Im nächsten Jahr will jemand wissen, was gemeldet wurde, und in einer Prüfung ist die Frage „was stand im Register zum 31.12.“ eine, die man beantworten können muss.
Die fünf Stellen, an denen es typischerweise scheitert
Nach meiner Erfahrung aus Umsetzungen und Prüfungen, nicht nach der Fehlerstatistik der Aufsicht, die es öffentlich nicht gibt.
1 · Fehlende oder falsche Kennungen
Kein LEI vorhanden, falsche Codeart gewählt, oder eine Kennung, die formal gültig aussieht und zu einem anderen Rechtsträger gehört, etwa zur deutschen Tochter statt zur Vertragspartei im Ausland.
2 · Verträge ohne Funktionszuordnung
B_02.01 gefüllt, B_04.01 lückenhaft. Dann hängt der Vertrag an keiner Funktion, die Einstufung fehlt, und die Bewertung in B_07.01 lässt sich nicht bilden.
3 · Unterauftragnehmer, die niemand kennt
Die Kette ist im Vertrag zugelassen, aber nie abgefragt worden. Beispiel 3 geht vier Ebenen tief. Dann steht in B_03 ein Dienstleister ohne die Ebenen darunter; bei kritischen Funktionen ist genau das der Punkt, an dem eine Prüfung nachhakt.
4 · Datumsangaben, die sich widersprechen
Vertragsbeginn nach dem Stichtag, Ende vor dem Beginn, Kündigungsfrist länger als die Restlaufzeit. Die Validierung findet das zuverlässig, nur eben erst bei der Übertragung.
5 · Der Stand, der nicht der Stichtag ist
Im Februar gemeldet, was im Februar gilt. Ein Vertrag, der im Januar gekündigt wurde, fehlt dann, obwohl er am 31. Dezember bestand. Formal falsch, und in der Rückschau schwer zu erklären.
Und einer, der keinen Fehler auslöst
Die Einstufung ohne Begründung. Die Validierung nimmt sie an, ein Prüfer nicht. Das ist der Unterschied zwischen einer bestandenen Meldung und einem belastbaren Register.
Vorlagen zu dieser Anleitung
Die Erhebungsliste und die Abfrage an den Dienstleister stehen auf der Vorlagenseite zum Herunterladen, ohne Formular, ohne E-Mail-Adresse.
Stand: 28. September 2026 ·
Grundlagen: Verordnung (EU) 2022/2554, Artikel 28; Durchführungsverordnung
(EU) 2024/2956 samt Anhängen; Veröffentlichungen der BaFin zu Informationsregister und
Anzeigepflichten. Alle Rechtsquellen im Überblick: Rechtsquellen.
Die Frist zum 31. März gibt die BaFin auf dieser Seite vor; für den
Einreichungszyklus 2027 sind dort keine Änderungen der Taxonomie angekündigt. Prüfen Sie
beides nach, bevor Sie Ihre Planung darauf aufbauen. Diese Anleitung ist ein fachlicher
Hinweis und keine Rechtsberatung.