DORA-Informationsregister erstellen, prüfen und aktuell halten

Einordnung

Was ist das DORA-Informationsregister?

Das DORA-Informationsregister, englisch Register of Information oder RoI, dokumentiert die vertraglichen Vereinbarungen eines DORA-pflichtigen Finanzunternehmens über die Nutzung von IKT-Dienstleistungen. Artikel 28 Absatz 3 verlangt, den Bestand aktuell zu halten. Die standardisierten Vorlagen und Ausfüllhinweise stehen in der Durchführungsverordnung (EU) 2024/2956. [2] [3]

Ein belastbares Register verknüpft Vertrag, Dienstleister, bezogene Leistung und unterstützte Funktion. Es macht außerdem nachvollziehbar, aus welcher Quelle eine Angabe stammt und auf welchen Zeitpunkt sie sich bezieht. Dieser T-NEX-Fachartikel führt diese Arbeit an einem kleinen, vollständig synthetischen Fall durch: von der Neuanlage über eine Vertragsänderung bis zur Berichtigung und erneuten Prüfung.

Für die übergeordneten Pflichten und den Anwendungsbereich führt der DORA-Grundlagenbeitrag weiter. Hier geht es um die konkrete Registerarbeit im deutschen Aufsichtskontext.

Welche Vereinbarungen gehören ins DORA-Informationsregister?

Das Informationsregister erfasst die vertraglichen Vereinbarungen eines DORA-pflichtigen Finanzunternehmens über IKT-Dienstleistungen von IKT-Drittdienstleistern. Es umfasst auch Leistungen, die keine kritische oder wichtige Funktion unterstützen. Die Kritikalität verändert die erforderlichen Angaben und die Betrachtung der Dienstleistungskette; sie entscheidet nicht allein darüber, ob ein direkter IKT-Dienstleister überhaupt erfasst wird. Artikel 28 Absatz 3 DORA verlangt, die entsprechenden Vereinbarungen im Register voneinander zu unterscheiden. [2]

Die Prüfung beginnt mit dem Anwendungsbereich: Das Unternehmen muss unter Artikel 2 DORA fallen; dort stehen auch Ausnahmen. Die bloße Tätigkeit in einer regulierten Branche begründet noch keine Registerpflicht. Für einen Anbieter, der einer Bank Software bereitstellt, entsteht durch diese Geschäftsbeziehung ebenfalls nicht automatisch dieselbe Registerpflicht wie für das Finanzunternehmen. Die Bank benötigt jedoch Informationen ihres Anbieters, um ihr eigenes Register korrekt zu führen. [2]

IKT-Dienstleistungen sind nach Artikel 3 Nummer 21 digitale Dienste und Datendienste, die über IKT-Systeme fortlaufend bereitgestellt werden. Die Definition umfasst auch bestimmte Hardwareleistungen samt technischer Unterstützung; herkömmliche analoge Telefondienste sind ausgenommen. Deshalb sollte die Bestandsaufnahme bei der tatsächlich vereinbarten Leistung beginnen. Weder die Einkaufswarengruppe „IT“ noch das Etikett „Beratung“ beantwortet die Einordnungsfrage abschließend. [2]

Die Kritikalität bezieht sich hier auf die unterstützte Funktion des Finanzunternehmens. Artikel 3 Nummer 22 stellt dafür auf die Folgen einer Störung für Leistung, Kontinuität und regulatorische Pflichterfüllung ab. Diese Einordnung ist von der aufsichtsrechtlichen Einstufung eines Anbieters als kritischer IKT-Drittdienstleister zu unterscheiden. Ein Anbieter muss nicht von den ESAs als kritisch eingestuft sein, damit seine Leistung bei einem Institut eine kritische oder wichtige Funktion unterstützt. [2]

Vier Pflichten, die im Prozess auseinandergehalten werden müssen

Die Trennung verhindert, dass die jährliche Einreichung mit sämtlichen laufenden Anzeigepflichten gleichgesetzt wird. Umgekehrt soll aus der gesetzlichen Jahresinformation über neue Vereinbarungen bei der BaFin keine zusätzliche Doppelmeldung entstehen. [2] [1]

Die laufende Pflege bleibt vom jährlichen Meldestichtag getrennt. Die Durchführungsverordnung verlangt regelmäßige Überprüfungen und die unverzügliche Korrektur erkannter Fehler oder Unstimmigkeiten. Praktisch empfiehlt es sich deshalb, bei einer Änderung zwei Daten festzuhalten: Wann trat der Sachverhalt ein, und wann wurde er im Register erfasst? So lässt sich unterscheiden, ob ein Fehler im gemeldeten Stichtagsbestand korrigiert werden muss oder eine spätere Änderung zum laufenden Bestand gehört. [3]

Das Datenmodell: 15 Vorlagen mit gemeinsamen Referenzen

Die 15 Vorlagen der Durchführungsverordnung (EU) 2024/2956 bilden miteinander verknüpfte Angaben und Beziehungen ab. Sie folgen keinem Schema „ein Vertrag, ein Dienstleister, eine Zeile“. Eine Vereinbarung kann mehrere Dienstleistungen betreffen, mehrere Einheiten können diese Leistungen nutzen, und dieselbe Dienstleistung kann mehrere Funktionen unterstützen. Artikel 4 verlangt einen Wert je Datenelement; treffen mehrere Werte zu, sind zusätzliche Zeilen in der betreffenden Vorlage vorgesehen. [3]

Schaubild als SVG · PNG, 2400 × 1620 Pixel

Beziehungen als Text und Tabelle

Eine vertragliche Vereinbarung regelt den Bezug einer IKT-Leistung. Der direkte IKT-Drittdienstleister ist Vertragspartner und erbringt die Leistung. Die Leistung unterstützt eine Funktion des Instituts. Eine Vereinbarung kann mehrere Leistungen betreffen; Leistungen und Funktionen können mehrfach verknüpft sein. Nutzende Einheiten und einschlägige Lieferketten sind zusätzlich zu betrachten.

Die vier Beziehungen im Schaubild

Ausgangspunkt	Beziehung	Bezug
Vertragliche Vereinbarung	Regelt den Leistungsbezug	IKT-Leistung
IKT-Drittdienstleister	Ist direkter Vertragspartner	Vertragliche Vereinbarung
IKT-Drittdienstleister	Erbringt	IKT-Leistung
IKT-Leistung	Unterstützt	Funktion des Instituts

Maßgeblich sind Artikel 5 und die Ausfüllhinweise in Anhang I. Nicht jede Vorlage oder jedes Feld ist in jeder Konstellation gleichermaßen zu befüllen. Insbesondere B_99.01 ist keine allgemeine Liste von Länder- oder ISO-Codes. Die Vorlage erläutert bestimmte intern verwendete Bewertungsbegriffe. [3]

Wie aus Tabellen ein konsistenter Bestand wird

Entscheidend sind die gemeinsamen Referenzen. Die Vertragsreferenz aus B_02.01 muss in den zugehörigen Leistungs- und Beziehungsangaben denselben Vertrag bezeichnen. Der in einer Kette genannte Anbieter muss zu seinen Stammdaten passen. Eine Funktionsreferenz muss auf die richtige Funktion der betreffenden Einheit zeigen. Der Name einer Anwendung reicht als Funktionsbeschreibung nicht automatisch aus.

Für die Umsetzung bietet sich daher an, Verträge, Dienstleister, Einheiten und Funktionen als eigenständige Objekte zu pflegen und ihre Beziehungen ausdrücklich abzubilden. Das ist eine Umsetzungsempfehlung, keine Vorschrift, eine bestimmte Datenbank oder Softwareklasse einzusetzen. Rechtlich gefordert sind unter anderem Richtigkeit, Vollständigkeit, Konsistenz, Integrität, Einheitlichkeit und Gültigkeit der Registerdaten. Auch die Einzel- und Gruppensichten müssen zusammenpassen. [3]

Identifier: LEI, EUID und interne Referenzen sauber trennen

Ein Register kann lesbar wirken und dennoch an uneinheitlichen Identifikatoren scheitern. Der ausgeschriebene Dienstleistername ersetzt den verlangten Identifikationscode nicht. Ebenso wenig darf eine interne Lieferantennummer ohne Prüfung in ein Feld übernommen werden, das einen LEI oder EUID erwartet. Welche Kennung zulässig ist, hängt vom konkreten Feld und der Art der identifizierten Person ab.

Diese Regeln betreffen die Identifikation der Dienstleister. Sie lassen sich nicht pauschal auf sämtliche Identifikationsfelder des Registers übertragen. Für die Finanzunternehmen, Vertragsreferenzen, Zweigniederlassungen und Funktionen sind die jeweils einschlägigen Feldvorgaben zu beachten. [3]

Für bestehende Mappings ist außerdem die Berichtigung vom 19. September 2025 relevant. Sie korrigiert unter anderem die Typauswahl in B_05.01.0020. Die dort aufgeführten Codes lauten LEI, EUID, CRN, VAT, PNR und NIN. Daraus folgt keine freie Auswahl für jeden Anbieter: Die zulässige Verwendung richtet sich weiterhin nach den Ausfüllhinweisen und der Personenkategorie. Ein altes Mapping aus der ursprünglichen Fassung darf deshalb nicht ungeprüft weiterlaufen. [4]

Ein sinnvoller Kontrollschritt verbindet drei Fragen: Ist der Code für dieses Feld zulässig? Gehört er tatsächlich zur richtigen Vertragspartei? Wird dieselbe Partei in allen Beziehungen konsistent referenziert? Bei einer Unternehmensgruppe ist dabei zwischen der leistenden Gesellschaft und ihrem obersten Mutterunternehmen zu unterscheiden. Beides kann im Register vorkommen, bezeichnet aber unterschiedliche Rollen. Die Bereinigung von Schreibweisen allein löst diese Zuordnungsfrage nicht. [3]

Lieferketten und gruppeninterne Leistungen richtig abbilden

Der direkte IKT-Drittdienstleister erhält in der Dienstleistungskette immer Rang 1. Das gilt auch für einen direkten gruppeninternen Anbieter. Ein Unterauftragnehmer hat einen Rang größer als 1. Der Rang bezeichnet seine Position in einer bestimmten Dienstleistungskette, nicht eine allgemeine Risikoklasse oder eine fortlaufende Lieferantennummer. Mehrere Anbieter können auf derselben Stufe stehen. [3]

Für B_05.02 sind vor allem drei Regeln maßgeblich:

1. Direkte Anbieter werden immer erfasst. Dafür ist unerheblich, ob die bezogene IKT-Dienstleistung eine kritische oder wichtige Funktion unterstützt.
2. Bei kritischen oder wichtigen Funktionen ist die relevante Unterauftragnehmerkette einzubeziehen. Erfasst werden die Unterauftragnehmer, die IKT-Dienstleistungen tatsächlich tragen, welche kritische oder wichtige Funktionen oder wesentliche Teile davon unterstützen. Die Betrachtung endet deshalb nicht automatisch beim ersten Unterauftragnehmer.
3. Für gruppeninterne Anbieter gilt eine zusätzliche Mindestanforderung. Nutzen sie Unterauftragnehmer zur Leistungserbringung, gehört mindestens der erste gruppenexterne Unterauftragnehmer ins Register, auch wenn keine kritische oder wichtige Funktion unterstützt wird.

Diese Eingrenzungen stehen in den Ausfüllhinweisen zu B_05.02 und werden auf der aktuellen BaFin-Seite ausdrücklich wiedergegeben. Eine undifferenzierte Forderung nach jedem beliebigen Zulieferer eines Dienstleisters wäre ebenso unpräzise wie die Beschränkung auf den direkten Vertragspartner. [3] [1]

Die Kette hängt an einer Leistung, nicht nur an einem Lieferanten

In B_05.02 wird die Beziehung über Vertragsreferenz und Art der IKT-Dienstleistung eingeordnet. Zusätzlich muss erkennbar sein, welcher Anbieter die Leistung des jeweiligen Unterauftragnehmers erhält. Eine reine Liste „Anbieter A, B, C“ mit Rangnummern verliert diese Beziehung. Unterstützt derselbe Unterauftragnehmer mehrere empfangende Anbieter, können mehrere Beziehungszeilen erforderlich sein. [3]

Bei gruppeninternen Konstellationen kommt die Vertragsverknüpfung in B_02.03 hinzu. Die Vereinbarung mit dem gruppeninternen Leistungserbringer wird mit dessen Vereinbarung mit seinem unmittelbaren IKT-Dienstleister verknüpft. Ein gemeinsamer Konzernname ersetzt weder diese Vertragsbeziehung noch die Identität der tatsächlich leistenden Gesellschaft. [3]

Für die Datenerhebung empfiehlt sich ein klarer Rückfrageprozess: Welche konkrete Leistung wird weitergegeben? Welche Funktion unterstützt sie? Wer erbringt den relevanten Teil, und aus welcher Anbieterinformation stammt diese Zuordnung? Fehlende Angaben sollten als offene Klärung mit Verantwortlichem und Termin sichtbar bleiben. Ein technisch ausgefülltes Feld schafft noch keinen belastbaren Nachweis über eine Lieferkette.

Ein Registerbeispiel mit drei Verträgen und zwei Funktionen

Ein Vertrag allein erklärt noch nicht, welche Funktion von einem Dienstleister abhängt. Dafür müssen Vertragsangaben, Anbieter, Leistung und Funktionsbewertung zusammenpassen. Das folgende T-NEX-Arbeitsbeispiel macht diese Verbindungen sichtbar und zeigt anschließend, wie Änderungen und Fehler behandelt werden können.

Im Beispiel ist F-001 als kritisch oder wichtig bewertet. F-002 ist es aufgrund der angenommenen Abläufe und Ersatzwege nicht. Diese Einstufungen gehören zum erfundenen Fall. Sie lassen sich nicht pauschal auf Zahlungs- oder Kollaborationsdienste anderer Institute übertragen.

Derselbe Anbieter kann zwei unterschiedliche Rollen haben

Beispielanbieter B hat einen direkten Vertrag V-002 mit dem Finanzunternehmen. Zugleich übernimmt er für Beispielanbieter A einen tragenden Betriebsanteil an V-001. In der Lieferkette zu V-001 steht D-002 deshalb auf Rang 2. In der Lieferkette zu V-002 steht derselbe Anbieter auf Rang 1.

Die Rolle gehört zur Vertrags- und Leistungsbeziehung. Ein einziges Feld „Unterauftragnehmer: ja/nein“ am Anbieter würde diese beiden Konstellationen nicht sauber abbilden. Das Beispiel zeigt genau diese Beziehung; den Umfang einer realen Lieferkette muss das Institut gesondert bestimmen.

Neuanlage: Welche Angaben müssen zusammenkommen?

Für V-003 liefert der IT-Einkauf Vertragsbeginn, Vertragsende und Anbieterangaben. Die Funktionsverantwortung ergänzt den Bezug zu F-002 und die Bewertungsgrundlage. Die Registerkoordination führt beides zusammen. Erst damit lässt sich nachvollziehen, welche Leistung das Institut bezieht und wofür es sie verwendet.

1. Anbieter und Vertrag erfassen. D-003 und V-003 erhalten eindeutige interne Referenzen. Der Quellenverweis führt auf den mitgelieferten Lernbeleg BE-V003.
2. Funktion zuordnen. Die Beziehung V-003 zu F-002 wird separat dokumentiert. Die Einstufung lässt sich über BE-BIA002 nachvollziehen.
3. Angaben gegen Belege prüfen. Der ursprüngliche Datensatz enthält absichtlich 30.06.2027 als Vertragsende. Im Lernbeleg steht 30.09.2027. Beide Angaben sind gültige Datumswerte. Eine reine Formatprüfung findet den Übertragungsfehler daher nicht.

Die erste Prüffrage lautet somit nicht nur „Ist die Zeile vollständig?“, sondern auch „Lässt sich dieser Wert aus dem richtigen Beleg für den richtigen Zeitpunkt herleiten?“. Die mitgelieferten Dateien erlauben genau diesen Abgleich.

Änderung oder Berichtigung: Welcher Stand ist betroffen?

Im Februar 2027 treten im Szenario zwei verschiedene Dinge auf. Der Vertrag V-001 wird verlängert. Außerdem fällt der schon zuvor vorhandene Erfassungsfehler in V-003 auf. Wer beides einfach in eine einzige Tabelle schreibt und den alten Stand ersetzt, verliert den Unterschied zwischen neuer Sachlage und falscher Erfassung.

Änderung: Der Nachtrag zu V-001 wird am 01.02.2027 wirksam. Er verlängert den Vertrag bis 31.12.2028. Der laufende Bestand erhält das neue Enddatum. Für den Stichtag 31.12.2026 bleibt das damals geltende Enddatum 31.12.2027 erhalten.

Berichtigung: Am 10.02.2027 wird festgestellt, dass V-003 schon im Vorjahr bis 30.09.2027 galt. Der 30.06.2027 war ein Übertragungsfehler. Deshalb werden der laufende Bestand und eine gesonderte berichtigte Fassung des Stichtagsbestands angepasst. Die ursprünglich erfasste Fassung bleibt zum Vergleich erhalten.

Das Änderungsjournal hält Wirksamkeitsdatum, Erfassungsdatum, alten Wert, neuen Wert und Beleg auseinander. Ob ein bereits eingereichtes Register erneut eingereicht werden muss und auf welchem Weg, richtet sich nach der aktuellen Aufsichtsanweisung und dem konkreten Rückmeldestatus. Diese Entscheidung nimmt das Arbeitsbeispiel nicht vorweg.

Schaubild als SVG · PNG, 2400 × 1800 Pixel

Die beiden Fälle als Text

Ein Registerstand bezieht sich auf die Verhältnisse an einem bestimmten Stichtag. Wird eine reale Änderung erst danach wirksam, wird der aktuelle Bestand fortgeschrieben. Die frühere Version bleibt nachvollziehbar erhalten.

Wird dagegen später ein Fehler entdeckt, der bereits den Stichtagsbestand betraf, wird dieser Stand berichtigt. Alter und korrigierter Stand bleiben als unterschiedliche Versionen nachvollziehbar. Die Berichtigung dreht eine spätere reale Änderung nicht zurück.

In beiden Fällen werden Wirksamkeit, Bearbeitung, Grund und Version dokumentiert. Ob eine erneute Übermittlung nötig ist und wie sie erfolgt, wird gesondert anhand des geltenden Verfahrens geprüft.

Fünf Fehler erkennen, zuordnen und erneut prüfen

Für den dritten Teil enthält der Download einen absichtlich fehlerhaften Stand. Die folgende Rückmeldung stammt aus dem eigenen Python-Teilprüfer des Arbeitsbeispiels. Die Regelnummern T01 bis T08 sind eigene Bezeichnungen, keine EBA-Fehlercodes.

Nach der Korrektur werden die Teilprüfungen auf einer neuen Fassung erneut ausgeführt. Der Download enthält beide Stände und die tatsächlichen Ergebnisse. Getrennte Ordner und Prüfsummen machen die Fassungen vergleichbar. Eine unveränderbare oder revisionssichere Archivierung ist damit nicht nachgewiesen.

Warum null technische Befunde nicht genügen

Im zusätzlichen Gegenfall wird die Einstufung von F-001 von „ja“ auf „nein“ geändert. „Nein“ ist ein zulässiger Wert im Beispielschema. Auch der Quellenverweis auf BE-BIA001 ist vorhanden. Der Teilprüfer meldet deshalb keinen Fehler.

Die synthetische Funktionsbewertung sagt aber weiterhin, dass F-001 kritisch oder wichtig ist. Der Widerspruch wird erst beim fachlichen Abgleich sichtbar. Damit lässt sich an derselben kleinen Datenbasis zeigen, was technische Prüfungen leisten und wo eine begründete Entscheidung erforderlich bleibt.

Das Beispiel wurde mit einem eigenen, offen mitgelieferten Python-Teilprüfer ausgeführt. Es wurde kein vollständiges Meldepaket erzeugt, kein amtliches Regelpaket angewendet und keine Einreichung an eine Aufsicht vorgenommen.

Schaubild als SVG · PNG, 2400 × 2180 Pixel

Prüfung und Rückkopplung als Text

1. Für den Prüfstand werden Datenstand, Umfang, Quellen sowie Werkzeug- und Regelversion festgehalten.
2. Fachlich zuständige Personen prüfen Quelle, Zuordnung und Begründung. Die technische Prüfung betrachtet Format, Werte und Beziehungen im benannten Regelumfang.
3. Die Ergebnisse beider Prüfstränge werden zusammengeführt. Jeder Befund erhält Ursache, zuständige Rolle und Nachweis. Eine offene fachliche Prüfung bleibt sichtbar.
4. Ist eine Korrektur nötig, werden führende Quelle und Register abgestimmt. Der neue Datenstand wird festgehalten und die betroffenen Prüfungen werden wiederholt.
5. Eine benannte Rolle dokumentiert die interne Freigabeentscheidung, den geprüften Stand und offene Punkte. Die Revision prüft unabhängig und übernimmt dadurch keine operative Freigaberolle.

Ein erfolgreiches technisches Teilergebnis belegt keine vollständige fachliche Richtigkeit. Die Grafik beschreibt einen organisatorischen Ablauf, keine nachgewiesene T-NEX-Produktfunktion.

BaFin-Einreichung: Stichtag, Dateiformat und Rückmeldung

Nach dem am 15. Oktober 2026 abgerufenen BaFin-Stand muss der jährliche Einreichungsprozess spätestens am 31. März vollständig und fehlerfrei durchlaufen sein. Das Register bildet jeweils den Sachstand zum 31. Dezember des Vorjahres ab. Auf den nächsten Jahreszyklus angewandt bedeutet das: Referenzdatum 31. Dezember 2026, Abschluss bis 31. März 2027. Diese Daten ergeben sich aus der allgemeinen BaFin-Vorgabe; ein gesonderter Annahmebeginn für 2027 war in der geprüften Quelle noch nicht genannt. Die BaFin kündigt den Beginn jeweils zum Jahresanfang an. [1]

Für den Einreichungszyklus 2027 sieht die BaFin laut derselben Seite keine Taxonomieänderungen vor. Daraus folgt nicht, dass ein alter Export ohne Prüfung wiederverwendet werden sollte. Vor der Einreichung müssen die aktuellen Vorlagen, Verfahrenshinweise und anwendbaren Validierungsregeln geprüft werden. Testeinreichungen sind jederzeit im gesonderten Fachverfahren „TEST: Digital Operational Resilience Act (DORA)“ möglich. [1]

Welche Datei nimmt die BaFin entgegen?

Das Informationsregister wird ausschließlich über die Melde- und Veröffentlichungsplattform MVP eingereicht. Die BaFin nennt zwei Wege: eine strukturierte xBRL-Datei entsprechend der ESA-Taxonomie, nach Einreichungsanleitung in einem ZIP-Container, oder die aktuelle Excel-Vorlage der BaFin. Eine beliebige CSV-Datei oder eine selbst gestaltete Excel-Liste ist damit nicht gleichzusetzen. Bei Verwendung der BaFin-Vorlage übernimmt die BaFin die Formatkonvertierung; die vorgegebene Struktur darf nicht verändert werden. [5] [6]

Zur organisatorischen Vorbereitung gehören ein MVP-Zugang und die Freischaltung für das richtige Fachverfahren. Der Testzugang ist gesondert zu berücksichtigen. Sinnvoll ist außerdem eine Vertretung für den Abruf der Rückmeldungen: Der Prozess endet nicht mit dem Hochladen der Datei. [5]

Was die Rückmeldungen tatsächlich aussagen

Die zusammenfassende Rückmeldung steht in instance-status.csv, Einzelbefunde in detailed-feedback.csv. Beide gehören in den Bearbeitungsprozess. Eine positive technische Rückmeldung ersetzt dabei keine fachliche Prüfung, ob Funktionen zutreffend eingestuft, Verträge vollständig erfasst und Lieferketten sachlich richtig beschrieben wurden. Die BaFin weist ausdrücklich auf eine nachfolgende Datenqualitätsprüfung der ESAs hin, aus der weitere Korrekturanforderungen entstehen können. [5] [1]

Für die Terminplanung ist eine Reserve nötig. Die aktuelle Webseite nennt eine Validierungsdauer von bis zu 48 Stunden; die ausführliche Anleitung spricht für die ESA-Rückmeldung von mehreren Tagen. Daraus lässt sich keine garantierte Bearbeitungszeit ableiten. Wer erst unmittelbar vor Fristende hochlädt, lässt möglicherweise keine Zeit für die Rückmeldung, Korrektur und erneute Prüfung. [1] [5]

Die Sondertermine der Einreichungsanleitung für 2026 dürfen nicht auf 2027 übertragen werden. Das dort genannte formale Fenster vom 9. bis 30. März 2026 und die Nachbesserungsmöglichkeit bis 24. April 2026 bezogen sich auf den damaligen Zyklus und dessen Voraussetzungen. Für die kommende Planung ist die aktuelle allgemeine BaFin-Regel maßgeblich, ergänzt um noch folgende jahresspezifische Hinweise. [5] [1]

Informationsregister und Auslagerungsregister: gemeinsame Daten, unterschiedliche Prüfung

Das DORA-Informationsregister und das Auslagerungsregister lassen sich nicht über dieselbe Einschlussfrage steuern. DORA knüpft für das Informationsregister an vertragliche Vereinbarungen über IKT-Dienstleistungen an. § 25b Absatz 1 KWG verlangt für die erfassten Institute ein Register sämtlicher wesentlicher und nicht wesentlicher Auslagerungen. Ob eine Leistung eine IKT-Dienstleistung ist und ob ein Sachverhalt als Auslagerung einzuordnen ist, sind deshalb gesonderte Fragen. [2] [9]

Auch die aktualisierten MaRisk müssen präzise gelesen werden. AT 9 in der Fassung des Rundschreibens 06/2026 (BA) nimmt IKT-Dienstleistungen im Sinne von Artikel 3 Nummer 21 DORA, für die Artikel 28 bis 30 DORA gelten, aus den dortigen Anforderungen aus. Daraus folgt keine pauschale Aufhebung des gesetzlichen § 25b KWG. Die Abgrenzung ist anhand der einschlägigen Vorschrift und des konkreten Sachverhalts vorzunehmen. [10]

Für die Datenpflege empfiehlt sich ein gemeinsamer Grundbestand aus Verträgen, Anbietern und verantwortlichen Stellen, ergänzt um getrennte Einordnungen: IKT-Dienstleistung, Unterstützung einer kritischen oder wichtigen Funktion, Auslagerung und gegebenenfalls Wesentlichkeit. Damit bleiben die Gründe für die Aufnahme in das jeweilige Register nachvollziehbar. Eine einmal gesetzte Kennzeichnung „kritisch“ sollte diese verschiedenen Entscheidungen nicht zusammenziehen.

Auch die Anzeigewege bleiben unterscheidbar

Die BaFin stellt aktuell klar, dass sektorale Auslagerungsanzeigen nach KWG, VAG oder KAGB fortbestehen. IKT-Auslagerungen sollen weiterhin über das MVP-Fachverfahren „Anzeige von Auslagerungen“ angezeigt werden. Die Möglichkeit, eine zugleich DORA-meldepflichtige IKT-Dienstleistung im selben Formular kenntlich zu machen, beschreibt die geprüfte Webseite noch als künftig verfügbar. Liegt keine Überschneidung mit sektoralen Anzeigepflichten vor, verweist sie für die betreffende DORA-Anzeige auf ein Excel-Formular per E-Mail und die Hinweise zur gesicherten Kommunikation. Das ist vom vollständigen Informationsregister zu trennen, dessen Einreichung ausschließlich über MVP erfolgt. [1]

Werkzeugauswahl

Excel, Registertool oder vorhandene Plattform?

Die passende Lösung hängt daran, wie Ihr Institut Daten erhält, Änderungen bearbeitet und einen früheren Registerstand wiederherstellt. Ein sauber geführtes Register mit wenigen Beteiligten stellt andere Anforderungen als ein gruppenweiter Bestand mit mehreren Datenquellen. Die Zahl der Verträge allein ist deshalb kein hinreichendes Auswahlkriterium.

Für einen fairen Vergleich erhalten alle Lösungen denselben Ausgangsbestand, dieselbe Änderung und dieselben Fehler. Bewerten Sie eine vorgeführte Funktion anhand ihres Ergebnisses. Eine angekündigte Funktion bleibt bis zum Nachweis offen. Mehrfachbezüge, Rollenprüfungen und eine amtliche Ausgabe gehen dabei über die bewusst kleine Datenbasis des Downloads hinaus. Die folgenden acht Prüffelder führen die vorhandene T-NEX-Tool-Anforderungsmatrix fort.

Diese Aufgaben sind Beschaffungs- und Abnahmekriterien. Die lokalen Teilprüfungen im Fallpaket belegen nur die dort beschriebenen Beispieldaten und Regeln. Sie sind kein Testergebnis einer T-NEX-Anwendung oder eines anderen Produkts.

Welche Aufwände gehören in die Entscheidung?

Betrachten Sie neben Lizenz und Einführung auch die Bereinigung des Bestands, Schnittstellen, fachliche Bewertung, Rollenpflege, Regelupdates, Bearbeitung von Rückmeldungen und eine spätere Übergabe. Ein günstiger Export löst wenig, wenn dieselbe Vertragsänderung weiterhin in drei Systemen von Hand nachgetragen wird. Umgekehrt kann eine umfassende Plattform unnötigen Aufwand erzeugen, wenn allein ein eng umrissenes Registerproblem zu lösen ist.

Halten Sie deshalb vor der Auswahl fest, welche Daten bereits belastbar vorliegen, welche Quelle führt und welche Lücke das Werkzeug konkret schließen muss. Allgemeine Kriterien für diese Entscheidung erläutert der Beitrag GRC-Software auswählen.

KI mit Quellenbezug

Was KI bei Vertragsdaten vorbereiten kann

Eine sinnvolle erste Aufgabe ist, aus freigegebenen Dokumenten Kandidatenwerte für die Registerpflege vorzubereiten. Dazu können Vertragspartner, Datumsangaben und beschriebene Leistungen gehören. Ob ein Wert übernommen werden kann, hängt von der Fundstelle, dem Dokumentstand und seiner fachlichen Bedeutung ab. Die folgende Arbeitsweise ist ein Umsetzungsvorschlag, kein gemessener Produktvergleich.

Für eine Erprobung eignen sich bewusst schwierige Dokumente: widersprüchliche Anlagen, fehlende Seiten, unklare Laufzeiten und mehrere Vertragsparteien. Messen Sie dabei nicht nur richtig vorgeschlagene Werte. Zählen Sie auch unbelegte Vorschläge, übersehene Konflikte und Fälle, in denen das System zu Recht keine eindeutige Antwort liefert. Zugriff, Vertraulichkeit und Datenverarbeitung müssen zum eingesetzten Betriebsmodell passen.

Im Musterfall ist ein korrekt formatiertes, aber aus der falschen Quelle übernommenes Datum technisch unauffällig. Genau hier entscheidet der Quellenabgleich. Die gleiche Grenze gilt für KI-Ausgaben: Ein ausgefülltes Feld ist noch kein belegter Sachverhalt.

Arbeitsunterlage

Was vor der Einreichung feststehen sollte

Die Liste bündelt die Arbeitskontrollen aus diesem Beitrag. Sie ersetzt weder die vollständigen Ausfüllhinweise noch die anwendbaren Prüfregeln.

1. Umfang: Registerführende und einbezogene Einheiten sind bestimmt. Die relevanten IKT-Vereinbarungen sind mit dem Vertragsbestand abgeglichen.
2. Beziehungen: Anbieter, Vereinbarungen, Leistungen, Funktionen und einschlägige Lieferketten sind konsistent verknüpft.
3. Quellen: Fachlich entscheidende Angaben haben eine aktuelle Grundlage. Unklare Einordnungen sind einer verantwortlichen Rolle zugeordnet.
4. Stichtag: Datenstand, spätere Änderungen und rückwirkende Berichtigungen bleiben unterscheidbar. Frühere Versionen sind rekonstruierbar.
5. Prüfung: Technische und fachliche Ergebnisse liegen getrennt vor. Befunde, Korrekturen und Wiederholungsprüfungen sind nachvollziehbar.
6. Ausgabe: Dateiformat und Version passen zum vorgesehenen Einreichungsweg. Eine Konvertierung wurde am ausgegebenen Bestand geprüft.
7. Verantwortung: Interne Entscheidung, Übermittlung und Vertretung für die Rückmeldungen sind geklärt. Die Revision bleibt in ihrer unabhängigen Prüfrolle.
8. Rückmeldung: Portalstatus und inhaltliche Prüfergebnisse werden ausgewertet. Ein möglicher Korrekturlauf ist zeitlich eingeplant.

Sechs konkrete Fragen zum DORA-Informationsregister

Muss ein SaaS-Vertrag ins Register, obwohl er keine kritische Funktion unterstützt?

Wenn die Vereinbarung eine IKT-Dienstleistung im Sinne von DORA betrifft und das Finanzunternehmen der Registerpflicht unterliegt, schließt fehlende Kritikalität die Aufnahme nicht aus. Direkte IKT-Dienstleister sind unabhängig davon zu erfassen. Die konkrete Leistung und die unterstützten Funktionen müssen trotzdem eingeordnet werden; davon hängen weitere Angaben ab. [2]

Unsere IT kommt von einer Konzerngesellschaft. Reicht deren Name?

Nein. Die gruppeninterne Leistung und ihre Vertragsbeziehungen müssen entsprechend den Vorlagen abgebildet werden. Nutzt der interne Anbieter Unterauftragnehmer, ist mindestens der erste Anbieter außerhalb der Gruppe zu erfassen, auch bei einer nicht kritischen Funktion. Bei kritischen oder wichtigen Funktionen ist zusätzlich die weitergehende Abgrenzung der relevanten Unterauftragnehmerkette zu beachten. [3]

Darf ein EU-Dienstleister ohne LEI mit seiner Handelsregisternummer eingetragen werden?

Bei einer juristischen Person in der EU sehen die Vorgaben LEI oder EUID vor, bei Verfügbarkeit beide. Eine nationale Handelsregisternummer ist nicht ohne Weiteres dasselbe wie ein EUID. Die zusätzlichen Codearten in der Vorlage eröffnen keine freie Ersatzwahl für juristische Personen. Fehlt eine benötigte Kennung, sollte der Sachverhalt geklärt und anhand der aktuellen Ausfüll- und Fehlerhinweise bearbeitet werden. [3] [4]

Im MVP steht „Verarbeitung abgeschlossen“. Ist die Einreichung erledigt?

Der Portalstatus allein reicht nicht. Die ESA-Rückmeldedateien müssen geprüft werden. Nach der BaFin-Anleitung ist RES ohne Beanstandungen mit „No findings found“ in instance-status.csv der erfolgreiche Abschluss. Bei NOK oder grundsätzlich bei RES mit Beanstandungen sind Korrektur und erneute Einreichung erforderlich. Spätere Datenqualitätsrückfragen bleiben möglich. [5]

Im Februar fällt ein Fehler im Dezemberbestand auf. Gehört er erst ins nächste Jahresregister?

Ein Fehler im Stichtagsbestand ist von einer erst nach dem Stichtag eingetretenen Änderung zu unterscheiden. Die ITS verlangen, erkannte Fehler und Unstimmigkeiten unverzüglich zu korrigieren. Für einen bereits eingereichten Bestand ist der einschlägige Korrektur- und Wiedereinreichungsprozess zu beachten. Eine neue Vereinbarung im Februar verändert dagegen nicht rückwirkend die Verhältnisse am 31. Dezember; laufende Pflege und etwaige separate Anzeigen bleiben erforderlich. [3] [1]

Müssen wir neben dem Vollregister jährlich noch die Anzahl neuer IKT-Verträge melden?

Nach dem aktuellen BaFin-Verfahren nicht zusätzlich. Die BaFin leitet die entsprechenden Angaben aus den jährlich eingereichten Informationsregistern ab. Davon zu unterscheiden sind die zeitnahen Anzeigen geplanter Vereinbarungen zur Unterstützung kritischer oder wichtiger Funktionen sowie der Fall, dass eine Funktion kritisch oder wichtig wird. Diese werden durch die Jahresabgabe nicht ersetzt. [1]

T-NEX Redaktion

Verantwortung und weiterführende Beiträge

Autoren dieses Beitrags sind Andreas Unruh und Christoph Gembruch. Die Redaktionsgrundsätze von T-NEX erläutern den Umgang mit Quellen, fachlicher Prüfung und Aktualisierungen.

Nachlesen und einordnen

Primärquellen und Arbeitsgrundlagen

Rechts- und Verfahrensaussagen stützen sich auf die folgenden amtlichen Quellen. Die Erstfassung des Beitrags stammt vom 17. Juli 2026; diese inhaltliche Überarbeitung vom 15. Oktober 2026. Abrufstand der Quellen ist der 15. Oktober 2026. Ein Dokumentdatum und das Datum seines Abrufs sind unterschiedliche Angaben. Die Podcast-Perspektiven sind an ihrer jeweiligen Textstelle gesondert verlinkt.

1. Informationsregister und AnzeigepflichtenAmtliche Verfahrens- oder Fachquelle · Abruf 15.10.2026
2. Verordnung (EU) 2022/2554 (DORA), insbesondere Artikel 28 Absatz 3Rechtsgrundlage · Dokumentstand 2022-12-27 · Abruf 15.10.2026
3. Durchführungsverordnung (EU)2024/2956Rechtsgrundlage · Dokumentstand 2024-12-02 · Abruf 15.10.2026
4. Berichtigung der Durchführungsverordnung(EU)2024/2956, OJ L2025/90725Rechtsgrundlage · Dokumentstand 2025-09-19 · Abruf 15.10.2026
5. DORA Informationsregister – Hinweise für die Einreichung über das BaFin MVP PortalAmtliche Verfahrens- oder Fachquelle · Dokumentstand 2026-03-04 · Abruf 15.10.2026
6. Ausfüllhinweise für die Excel-Vorlage des InformationsregistersAmtliche Verfahrens- oder Fachquelle · Dokumentstand 2026-03 · Abruf 15.10.2026
7. Reporting framework 4.0Amtliche Verfahrens- oder Fachquelle · Abruf 15.10.2026
8. Preparations for reporting of DORA registers of informationAmtliche Verfahrens- oder Fachquelle · Abruf 15.10.2026
9. §25b KWG – AuslagerungAmtliche Verfahrens- oder Fachquelle · Abruf 15.10.2026
10. BaFin RS06/2026(BA), MaRisk und ÜbersendungsschreibenAmtliche Verfahrens- oder Fachquelle · Dokumentstand 2026-06-30 · Abruf 15.10.2026