Das DORA-Informationsregister — ein Pflicht-Inventar mit Abgabetermin
Artikel 28 Abs. 3 DORA verpflichtet Finanzunternehmen, ein Register aller vertraglichen Vereinbarungen mit IKT-Drittdienstleistern zu führen — und es der Aufsicht auf Verlangen und mindestens jährlich vorzulegen. Die Durchführungsverordnung (EU) 2024/2956 legt die Vorlagen fest. Warum das Register in Wahrheit ein verknüpftes Landschaftsmodell ist und woran Excel-Ansätze scheitern.
DORA hat viele Facetten — Resilienztests, Vorfallsmeldungen, Bedrohungsanalysen. Die unscheinbarste Pflicht ist womöglich die mit der größten Dauerwirkung: das Informationsregister nach Art. 28 Abs. 3 der Verordnung (EU) 2022/2554. Finanzunternehmen müssen ein Register aller vertraglichen Vereinbarungen über IKT-Dienstleistungen von Drittanbietern führen — laufend, vollständig, und unterschieden danach, ob der jeweilige Dienst kritische oder wichtige Funktionen unterstützt.
Das Register ist relational — Excel ist es nicht
Wer die Durchführungsverordnung (EU) 2024/2956 aufschlägt, findet keine einzelne Tabelle, sondern ein Geflecht: Vorlagen zu Verträgen, zu Dienstleistern (mit LEI), zu den bezogenen IKT-Diensten, zu den unterstützten Funktionen und ihrer Kritikalität — untereinander über Schlüssel verbunden. Das ist der Aufbau einer Datenbank, nicht einer Liste.
Genau hier scheitern die pragmatischen Erstlösungen. Die Vertragsliste des Einkaufs kennt Laufzeiten und Summen, aber nicht die Funktionen. Die Anwendungliste der IT kennt Systeme, aber nicht die Verträge. Das Business weiß, welche Prozesse kritisch sind, führt darüber aber gar nichts. Das Register verlangt die Kette: Vertrag → Dienst → Anwendung → Funktion → Kritikalität. Jede Stelle, an der diese Kette in einem anderen Silo liegt, ist eine Stelle, an der das Register bei der nächsten Abgabe von Hand zusammengeklebt werden muss — mit allen Übertragungsfehlern, die dazugehören.
Jährlich abgeben, laufend führen
Die Einreichung an die Aufsicht — in Deutschland über die BaFin — ist mindestens jährlich fällig, und das Register ist zusätzlich auf Verlangen vorzulegen. Der zweite Halbsatz ist der wichtigere: Er verbietet faktisch das Modell „drei Wochen vor Abgabe wird aufgeräumt". Wenn die Aufsicht nach einem Vorfall bei einem großen Cloud-Anbieter wissen will, welche Institute betroffen sind, fragt sie nicht zum Jahresultimo.
Laufende Führung heißt: Jede Vertragsänderung, jeder neue Dienst, jede Verschiebung in der Kritikalität einer Funktion muss den Weg ins Register finden — zeitnah und nachvollziehbar. Das ist ein Pflegeprozess, kein Dokument. Und Pflegeprozesse funktionieren dann, wenn die Angaben dort erfasst werden, wo sie ohnehin geführt werden: am Vertrag, an der Anwendung, an der Fähigkeit. Ein Register, das als Kopie neben der Landschaft steht, veraltet ab dem Tag seiner Erstellung — dasselbe Muster, das auch das Verzeichnis der Verarbeitungstätigkeiten chronisch unbrauchbar macht.
Der Konzentrations-Blick verlangt Aggregation
Art. 29 DORA verlangt, das Konzentrationsrisiko im Blick zu behalten: Wie abhängig ist das Haus von einem einzelnen Anbieter? Diese Frage lässt sich nur beantworten, wenn das Register aggregierbar ist — wenn sich also je Dienstleister zusammenzählen lässt, welche Dienste, Anwendungen und Funktionen an ihm hängen. In einer verknüpften Landschaft ist das eine Abfrage. In einer Sammlung von Excel-Blättern ist es ein Projekt.
Dazu kommt die Zeitdimension: Automatische Vertragsverlängerungen und Kündigungsfristen entscheiden darüber, ob eine erkannte Konzentration überhaupt kurzfristig auflösbar wäre. Ein Register, das Laufzeiten und Fristen mitführt, macht aus der Meldepflicht ein Steuerungsinstrument.
Dieselbe Pflege, noch einmal verwertet
Für Häuser, die zugleich unter NIS2 bzw. das BSIG 2025 fallen oder es mit dessen Lieferketten-Anforderungen zu tun haben, lohnt der Blick auf die Überschneidung: Die Datenbasis ist weitgehend identisch. Anwendungen, Anbieter, Verträge, Funktionen, Kritikalität — wer diese Kette einmal sauber führt, bedient daraus das DORA-Register, den NIS2-Nachweis und nebenbei die Frage des Vorstands, was eigentlich passiert, wenn Anbieter X morgen ausfällt. Dreimal Bericht, einmal Bestand.
Häufige Fragen
Wer muss ein DORA-Informationsregister führen?
Praktisch alle beaufsichtigten Finanzunternehmen im Anwendungsbereich der Verordnung (EU) 2022/2554 — von Banken und Versicherern über Wertpapierinstitute bis zu Zahlungsdienstleistern. Art. 28 Abs. 3 DORA verlangt ein Register aller vertraglichen Vereinbarungen über die Nutzung von IKT-Dienstleistungen von Drittanbietern, unterschieden danach, ob kritische oder wichtige Funktionen unterstützt werden.
Was legt die Durchführungsverordnung (EU) 2024/2956 fest?
Die einheitlichen Vorlagen (Templates) für das Register: verknüpfte Tabellen unter anderem zu Verträgen, Dienstleistern, den bezogenen IKT-Diensten, den unterstützten Funktionen und deren Kritikalität, inklusive Identifikatoren wie der LEI des Dienstleisters. Die Struktur ist relational angelegt — die Tabellen referenzieren einander über Schlüssel.
Wie oft muss das Register an die Aufsicht?
Es ist laufend zu führen, der Aufsicht auf Verlangen vorzulegen und mindestens jährlich einzureichen; in Deutschland sammelt die BaFin die Register ein und leitet sie an die europäischen Aufsichtsbehörden weiter. Ein Register, das nur einmal im Jahr vor der Abgabe „aufgeräumt" wird, verfehlt die laufende Führungspflicht.
Reicht eine Vertragsliste aus dem Einkauf?
Nein. Das Register verlangt die Verknüpfung: Welcher Vertrag liefert welchen IKT-Dienst, welcher Dienst unterstützt welche Funktion, und ist diese Funktion kritisch oder wichtig? Eine reine Vertragsliste kennt die rechte Seite dieser Kette nicht — die Zuordnung zu Funktionen und deren Kritikalität ist genau der Teil, der ein Landschaftsmodell erfordert.
Primärquellen
Verträge, Dienste, Funktionen — verknüpft statt gelistet
blueprAInt hält die Rohstruktur des Informationsregisters laufend gepflegt — statt sie jedes Jahr vor der Abgabe zu rekonstruieren.
- Die Kette ist das Datenmodell: Vertrag → Anwendung → Geschäftsfähigkeit ist in blueprAInt verknüpft gespeichert, nicht über drei Excel-Blätter geklebt — genau die relationale Struktur, die die Vorlagen der ITS verlangen.
- Laufend statt jährlich: Jede Vertragsänderung landet sofort am Objekt, feldgenau historisiert. „Auf Verlangen vorlegen" ist damit ein Export, keine Drei-Wochen-Aktion.
- Konzentrationsrisiko als Abfrage: Je Dienstleister aggregiert der Bestand, welche Dienste, Anwendungen und Funktionen an ihm hängen — die Art.-29-Frage beantwortet ein Blick, kein Projekt.