Bildquelle: extern
Viele DORA-Register scheitern an getrennten Lieferanten-, Vertrags- und Notfalldaten
Viele Finanzunternehmen haben inzwischen verstanden, dass DORA kein reines Compliance-Projekt für die Rechtsabteilung ist. Spätestens bei den Registers of Information zeigt sich sehr praktisch, ob Einkauf, Provider-Management, Architektur, Security, BCM und Betrieb wirklich dieselben Lieferanten in derselben Struktur sehen. Genau dort entstehen aktuell viele Brüche: Lieferanten stehen im Vendor-Tool, Verträge im Einkauf, Notfallkontakte in Excel, Exit-Szenarien in Präsentationen und kritische Services in einer CMDB, die mit alldem nur lose verbunden ist.
Das klingt organisatorisch bekannt, wird unter DORA aber operativ riskant. Denn die Aufsicht will nicht bloß wissen, dass es Drittanbieter gibt. Sie will nachvollziehen können, welche ICT-Dienstleister welche kritischen oder wichtigen Funktionen stützen, auf welcher Vertragsbasis das geschieht, wie Abhängigkeiten strukturiert sind und ob die Daten belastbar genug sind, um Risiko, Aufsicht und gegebenenfalls die Einstufung kritischer Anbieter sauber zu unterstützen.
Die European Banking Authority weist auf ihrer DORA-Vorbereitungsseite ausdrücklich darauf hin, dass die Register auf Ebene einzelner Unternehmen, Teilkonzerne und Konzerne verfügbar sein müssen. Die Registers of Information dienen laut EBA nicht nur der internen Überwachung von ICT-Drittparteirisiken, sondern auch den zuständigen Behörden zur Aufsicht und den europäischen Aufsehern zur Benennung kritischer ICT-Drittanbieter. Wer hier nur eine Lieferantenliste zusammenkopiert, baut also kein tragfähiges Steuerungsinstrument, sondern produziert bestenfalls ein brüchiges Meldeartefakt.
Ein DORA-Register ist keine bessere Lieferantenliste
Genau an dieser Stelle liegt ein verbreitetes Missverständnis. In vielen Organisationen wird das Register gedanklich als Beschaffungsinventar behandelt: Anbietername, Vertragsnummer, vielleicht noch Laufzeit und Ansprechpartner. Für DORA reicht das nicht. Das Register muss die vertraglichen ICT-Beziehungen so beschreiben, dass Risiko- und Aufsichtssicht anschlussfähig werden. Dazu gehört unter anderem, welche Services bezogen werden, welche Funktionen sie stützen, auf welcher Gruppierungsebene sie hängen und wie sie in eine kritische oder wichtige Betriebsrealität hineinwirken.
Praktisch bedeutet das: Ein Hyperscaler, ein Core-Banking-Dienstleister, ein Managed-SOC-Anbieter und ein SaaS-Provider dürfen nicht nur als vier Einkaufsobjekte auftauchen. Die Organisation muss zeigen können, welche konkreten ICT-Services dahinterstehen, welche fachlichen oder betrieblichen Funktionen davon abhängen, welche Unterbeauftragungen relevant sind und ob dieselbe Anbieterbeziehung mehrfach, widersprüchlich oder lückenhaft über verschiedene Datenquellen verteilt ist.
Spätestens wenn mehrere Gesellschaften, Landesorganisationen oder Geschäftsbereiche denselben Anbieter unterschiedlich benennen, kippt die Belastbarkeit. Dann entstehen Dopplungen, fehlende Hierarchien und unklare Aggregationen. Genau deshalb ist das Register keine Reporting-Folie am Ende des Prozesses, sondern ein Datendisziplin-Thema im Provider-Management.
Die eigentliche Schwachstelle ist oft die Lieferantenidentität
Die Guidance der Central Bank of Ireland macht den nächsten praktischen Schmerzpunkt sichtbar: Für die Einreichung müssen Finanzunternehmen strukturierte, technisch validierbare Daten liefern. Genannt werden unter anderem gültige LEI-Codes für meldende Institute sowie ein gültiger LEI oder eine EU-ID für ICT-Drittanbieter, damit Dateien Validierungen bestehen. Allein daran scheitern in der Praxis schon überraschend viele Datensätze.
Warum? Weil Lieferantenidentitäten über Jahre historisch gewachsen sind. Im Einkauf steht der juristische Vertragspartner, im Architekturportfolio der Produktname, im Betrieb der Service-Label, im Notfallhandbuch eine alte Supportfirma und im Konzern vielleicht noch eine übergeordnete Holding. Solange diese Identitäten nicht sauber aufgelöst werden, ist jedes Register anfällig für Inkonsistenzen. Dann sieht die Aufsicht im Zweifel denselben Provider mehrfach oder kann Abhängigkeiten nicht korrekt verdichten.
Für IT-Management und Sourcing-Verantwortliche folgt daraus eine klare Priorität: Erstens braucht jeder relevante ICT-Drittanbieter einen gepflegten Masterdatensatz. Zweitens müssen juristische Entität, Providergruppe, bezogene Services und technische Kontaktpunkte sauber verknüpft sein. Drittens darf die Registerlogik nicht an freitextige Feldpflege delegiert werden. Wer Anbieterbezeichnungen manuell variieren lässt, produziert fast zwangsläufig Datenqualitätsfehler.
Getrennte Vertrags- und Servicedaten machen Risiken unsichtbar
Noch kritischer wird es, wenn Vertragsdaten und Betriebsrealität auseinanderlaufen. Ein Vertrag kann zentral abgeschlossen sein, während mehrere Plattformen, Länder oder Produktlinien davon abhängen. Wird im Register nur der Rahmenvertrag sichtbar, aber nicht der Bezug zu den tatsächlich gestützten ICT-Services und kritischen Funktionen, fehlt der operative Kern des Risikos.
Genau deshalb sollten Unternehmen DORA nicht ausschließlich aus Vertragsmanagementsicht betrachten. Relevanter ist die Brücke zwischen Vertrag, Service, Funktion und Betriebsverantwortung. Wenn etwa ein Cloud-Provider sowohl Entwicklungsplattformen als auch produktive Kundenprozesse, Backup-Workloads und IAM-nahe Funktionen stützt, reicht ein allgemeiner Supplier-Eintrag nicht aus. Dann muss erkennbar sein, welche Bereiche wie tief betroffen wären, wenn Vertrag, Leistung, Region oder Unterauftragnehmer ausfallen oder sich ändern.
Für CMDB- und Service-Portfolio-Teams ist das eine unangenehme, aber wichtige Botschaft: Solange Verträge, Services und kritische Funktionen getrennt modelliert werden, bleiben Exit-Risiken, Konzentrationsrisiken und Meldewege teilweise unsichtbar. Das Register wird dann formal befüllt, aber fachlich stumpf.
Notfallkontakte und Exit-Szenarien gehören nicht in Randtabellen
Viele Häuser behandeln Notfallkontakte und Exit-Informationen noch immer als operative Zusatzdokumente außerhalb der eigentlichen Lieferantensteuerung. Unter DORA ist genau diese Trennung gefährlich. Wenn eine kritische ICT-Beziehung betroffen ist, müssen Incident-Kommunikation, Eskalationswege, vertragliche Hebel und Exit-Fähigkeit zusammen gedacht werden.
Das ist keine akademische Forderung. Ein Register wird im Ernstfall erst dann wertvoll, wenn ein Team schnell beantworten kann: Wen erreichen wir beim Anbieter? Für welche Services gilt der Kontakt wirklich? Welche internen Owner tragen die Beziehung? Welche Vertragsbestandteile regeln Unterstützung, Informationspflichten, Tests, Übergänge oder Beendigungen? Und was ist der realistische Ausweichpfad, wenn der Dienst ausfällt oder regulatorisch neu bewertet wird?
Wer diese Informationen getrennt pflegt, verliert Zeit an den falschen Stellen. Einkauf kennt die Klauseln, der Betrieb kennt die Störung, BCM kennt das Notfallbild und Architektur kennt die Substitutionshürden, aber niemand hat die Gesamtverbindung. Genau deshalb sollten Notfallkontakte, Exit-Annahmen und Servicekritikalität nicht als Beiblatt neben dem Register liegen, sondern aus demselben Steuerungsmodell referenzierbar sein.
Datenqualität ist inzwischen selbst ein Aufsichtsthema
Dass diese Probleme nicht theoretisch sind, zeigt die aktuelle Aufsichtspraxis. Die Central Bank of Ireland hat für die 2026er Einreichung ausdrücklich auf zusätzliche Data-Quality-Prüfungen nach der März-Abgabe hingewiesen. Genannte Beispiele reichen von ungültigen Identifikationscodes für Ultimate Parents bis zu generischen Platzhalterwerten wie „not applicable“ beim Namen eines ICT-Drittanbieters. Das ist ein klares Signal: Nicht nur die Datei muss technisch hochladbar sein, auch ihr Inhalt soll inhaltlich plausibel und auswertbar sein.
Die EBA geht noch einen Schritt weiter, wenn sie erklärt, dass die Registers of Information als Grundlage für die Aufsicht über ICT-Drittparteirisiken und für die Benennung kritischer ICT-Drittanbieter dienen. Die europäischen Aufsichtsbehörden haben bereits eine erste Liste designierter kritischer ICT-Drittanbieter veröffentlicht und dabei ausdrücklich auf Daten aus den Registers of Information verwiesen. Wer also heute schwache Registerdaten liefert, riskiert nicht nur Rückfragen im Reporting, sondern beschädigt die Grundlage, auf der Abhängigkeiten europaweit bewertet werden.
Für IT-Organisationen heißt das: Datenqualität ist nicht länger ein Backoffice-Thema. Sie gehört in die operative Governance. Plausibilitätsprüfungen, Pflichtfeldlogiken, eindeutige Identifikatoren und saubere Verantwortlichkeiten sind kein Luxus, sondern der Unterschied zwischen steuerbarer Providerlandschaft und hektischem Nacharbeiten vor der nächsten Einreichung.
Was IT- und Sourcing-Teams jetzt konkret tun sollten
- Lieferantenidentitäten bereinigen: Juristische Entität, Providergruppe, Produktname und Servicebezug dürfen nicht unverbunden nebeneinanderstehen.
- Vertrag und Service verknüpfen: Jeder relevante ICT-Vertrag sollte klar auf die gestützten Services, Funktionen und internen Owner abbildbar sein.
- Notfall- und Eskalationsdaten integrieren: Kontakte, Meldewege und Verantwortliche gehören in dieselbe Steuerungslogik wie Vertrags- und Leistungsdaten.
- Exit-Fähigkeit realistisch modellieren: Nicht nur „Exit möglich“ dokumentieren, sondern Substitutionshürden, Datenrückführung und Übergabepfade sichtbar machen.
- Datenqualität vor der Meldung prüfen: Keine generischen Platzhalter, keine widersprüchlichen Anbieterbezeichnungen, keine unvalidierten Identifikationscodes.
- Owner benennen: Provider-Management, Einkauf, Risk, BCM und Betrieb brauchen klare Zuständigkeiten statt geteilter Unverbindlichkeit.
Fazit
Viele DORA-Register scheitern nicht an der Verordnung selbst, sondern an alten Datengrenzen in den Organisationen. Solange Lieferanten-, Vertrags-, Notfall- und Exitinformationen in getrennten Silos gepflegt werden, bleibt das Register ein zusammenkopiertes Artefakt statt eines belastbaren Lagebilds.
Für CIOs, Sourcing-Leads, Resilienzverantwortliche und Service-Manager ist die Aufgabe damit klar umrissen: Nicht noch ein separates DORA-Tabellenwerk bauen, sondern die bestehende Providersteuerung so umbauen, dass Vertrag, Service, Kritikalität, Kontakt und Ausstieg aufeinander verweisen. Erst dann wird aus Meldepflicht echte Resilienzsteuerung.
