Das DORA-Informationsregister

Artikel 28 Absatz 3 DORA, Verordnung (EU) 2022/2554, verlangt von jedem Finanzunternehmen ein Informationsregister über alle vertraglichen Vereinbarungen zur Nutzung von IKT-Dienstleistungen durch IKT-Drittdienstleister, auf Unternehmensebene und, soweit zutreffend, teilkonsolidiert und konsolidiert.

Das Format wählt das Haus nicht selbst. Die Durchführungsverordnung (EU) 2024/2956 setzt die Meldevorlagen, 15 an der Zahl, jede mit einem Code wie B_01.01 für das meldende Unternehmen, B_02.01 für die Vereinbarungen und B_05.01 für die Dienstleister. Sie sind relational: Ein Vertrag verweist über den Schlüssel auf Dienstleister und Funktion, ein fehlender Schlüssel zerlegt also jede Zeile, die darauf zeigt.

Jenseits von Namen und Daten tragen vier Feldgruppen den Aufsichtsgehalt. Die Funktionsfelder nennen die gestützte Geschäftsfunktion und ob sie kritisch oder wichtig ist. Die Dienstleistungsfelder nennen die IKT-Dienstleistungsart aus einer festen Taxonomie sowie die Länder der Datenspeicherung und -verarbeitung. Die Vertragsfelder tragen Beginn und Ende, Kündigungsfrist, anwendbares Recht und den jährlichen Aufwand.

Die vierte Gruppe ist die Bewertung. Das Register hält fest, ob der Dienstleister ersetzbar ist und wie schwer ein Wechsel fiele, ob ein Ausstiegsplan existiert, wann zuletzt geprüft wurde und ob Alternativen benannt sind. Das sind vertretbare Urteile, und genau diese Felder vergleicht ein Prüfer mit dem, was der Fachbereich über den Dienstleister sagt.

Alle. Das Register erfasst jede vertragliche Vereinbarung über die Nutzung von IKT-Dienstleistungen, nicht nur die Träger kritischer oder wichtiger Funktionen, und daran scheitert die Übertragung eines bestehenden Auslagerungsregisters zuerst.

Die Kritikalitätsbewertung ändert die Tiefe. Für eine Dienstleistung, die eine kritische oder wichtige Funktion stützt, verlangt das Register die Unterauftragskette, die Ersetzbarkeitsbewertung und die Ausstiegsregelungen; sonst bleibt der Eintrag kürzer. Nach Artikel 28 bewertet das Haus die Kritikalität selbst, und nach Artikel 30 hat der Vertrag einer kritischen Funktion Pflichtinhalte, siehe IKT-Drittparteienrisikomanagement.

Für eine Dienstleistung, die eine kritische oder wichtige Funktion stützt, muss das Register die Kette der IKT-Unterauftragnehmer zeigen, die sie tatsächlich stützt, mit dem Rang jedes Glieds. Ein Cloud-Anbieter auf fremder Infrastruktur, ein Softwarehaus beim Hyperscaler, ein Verarbeiter mit Support-Desk im Ausland: jeder ist eine Zeile mit Schlüssel und Land.

Diesen Teil kann kein Haus aus eigenen Unterlagen füllen, denn die Angaben liegen beim Dienstleister und kommen spät oder nie. Die Europäischen Aufsichtsbehörden berichteten über den Probelauf vor der ersten Erhebung und fanden die wiederkehrenden Mängel genau hier: Schlüssel, relationale Integrität der Vorlagen und Unterauftragsdaten. Eine Kette, die beim ersten Dienstleister endet, ist der häufigste Grund für eine Rückweisung.

Dienstleister werden über ihren Legal Entity Identifier geführt. Die Meldeweisung macht die LEI zum Schlüssel zwischen Dienstleisterzeile und jeder Vertragszeile, wer keine hat, lässt sich also nicht auf dem Normalweg eintragen. Kleine Anbieter, öffentliche Stellen und Supporteinheiten außerhalb der EU sind die üblichen Fälle, und wer auf die LEI des Dienstleisters wartet, verpasst das Fenster.

Vorgesehen sind daneben der European Unique Identifier für in der EU registrierte Gesellschaften und einige weitere Schlüsselarten, und der praktische Weg klärt die Schlüsselfrage je Dienstleister Monate vor der Meldung. Ein für die Datei erfundener Schlüssel ist schlechter als ein späterer, denn er verweist auf nichts und lässt den Dienstleister jedes Jahr neu erscheinen.

In Deutschland geht das Register an die BaFin. Die BaFin erhebt es einmal jährlich über ihre Meldeplattform MVP, mit Vertragsdaten zum 31. Dezember des Vorjahres, und die Datei muss die Prüfungen der BaFin fehlerfrei bis zur genannten Frist passieren. Eine abgewiesene Datei kommt mit Fehlerprotokoll zurück und geht erneut hinein, weshalb Häuser die Prüfregeln als Teil des Datenmodells behandeln und nicht als Formalie.

Die BaFin leitet die Register an die Europäischen Aufsichtsbehörden weiter, die daraus die kritischen IKT-Drittdienstleister für den gesamten EU-Finanzsektor benennen. Das Register eines Hauses wirkt damit über die eigene Aufsicht hinaus: Es ist eine der Eingaben, die entscheiden, welche Dienstleister eine eigene EU-Überwachung erhalten.

Das Register ist der Datensatz, auf dem die Konzentrationsanalyse läuft. Artikel 29 DORA verlangt, beim Abschluss eines Vertrags über eine kritische oder wichtige Funktion zu bewerten, ob die Vereinbarung die Konzentration erhöht, auch über Unterauftragsverhältnisse, und ob ein Dienstleister ersetzbar ist.

Auf Unternehmensebene lautet die Frage, wie viel des kritischen Bestands auf einem Namen ruht. Sektorweit stellen die Behörden dieselbe Frage über alle Register zusammen, und so wird ein Dienstleister, den niemand für systemisch hielt, zum benannten kritischen Anbieter. Cybersicherheit im deutschen Finanzwesen und was DORA ist zeigen das Umfeld.

Das DORA-Informationsregister ist ein strukturierter Nachweis jeder vertraglichen Vereinbarung eines Finanzunternehmens über die Nutzung von IKT-Dienstleistungen, geführt nach Artikel 28 Absatz 3 der Verordnung (EU) 2022/2554 und einmal jährlich an die nationale Aufsicht gemeldet. Das Format setzt die Durchführungsverordnung (EU) 2024/2956 in 15 relationalen Vorlagen zu Unternehmen, Dienstleistern, Verträgen, gestützten Funktionen und Unterauftragsketten.

Nein. Ein Auslagerungsregister nach deutschem Recht erfasst ausgelagerte Aktivitäten nach Wesentlichkeit; das Informationsregister erfasst alle IKT-Dienstleistungsverträge unabhängig von der Kritikalität und hat ein festes EU-Datenmodell. Die Anzeigepflichten für Auslagerungen blieben ebenfalls, ein deutsches Institut führt also beides, und die BaFin will IKT-Auslagerungen weiter über ihr Anzeigeverfahren hören. Auslagerung und Cloud in deutschen Banken behandelt diese Seite.

Weil die Datei eine Prüfregel verletzt, nicht weil die Aufsicht einem Urteil widerspricht. Wiederkehrend sind ein fehlender oder ungültiger Dienstleisterschlüssel, eine Vertragszeile mit Verweis auf eine nicht existierende Einheit oder Funktion, eine Unterauftragskette, die beim ersten Dienstleister endet, eine IKT-Dienstleistungsart außerhalb der Taxonomie und widersprüchliche Kritikalitätskennzeichen zwischen Funktion und stützendem Vertrag.

Eine Funktion verantwortet Datei und Frist, meist das IKT-Risiko oder der Auslagerungsbeauftragte, während die Inhalte aus der Beschaffung für die Verträge, der IT für die Dienstleistungen und dem Recht für anwendbares Recht und Fristen kommen. Die Geschäftsleitung trägt unter DORA die Verantwortung für IKT-Risiken und damit für das Register. Ein einmal jährlich aus vier nicht abgestimmten Quellen zusammengesetztes Register erzeugt das Fehlerprotokoll.