Bildquelle: extern
Am DORA-Register scheitert selten das Template, sondern die Eigentümerschaft über Verträge, Funktionen und Unterauftragsketten
Viele Häuser behandeln das DORA-Register noch immer wie eine Reporting-Aufgabe für Compliance oder Meldewesen. Dann beginnt die Arbeit oft mit Feldern, Dateiformaten und Abgabefristen. Für die operative Realität ist das zu spät gedacht. Das eigentliche Problem entsteht vorher: Wer weiß im Unternehmen überhaupt belastbar, welche ICT-Dienstleistungen wo genutzt werden, welche Funktionen daran hängen, welche Verträge maßgeblich sind und welche Unterauftragsketten dahinterlaufen?
Genau dort scheitern viele Programme nicht am Willen, sondern an der Verteilung von Wissen. Einkauf kennt Vertragsparteien, Fachbereiche kennen den Einsatzzweck, Architektur kennt Abhängigkeiten, Security kennt Kontrolllücken und der Betrieb kennt die Störungen. Wenn diese Sichtweisen nicht zusammengeführt werden, entsteht zwar eine Datei, aber noch kein belastbares Register. Dann wird DORA zum Tabellenprojekt, obwohl die Verordnung eigentlich eine Führungsaufgabe sichtbar macht.
Das Register ist Teil des ICT-Risikomodells, nicht nur eine Abgabe
Der Text der Verordnung ist an dieser Stelle klarer, als viele Umsetzungsprogramme es intern spiegeln. In Artikel 28 verankert DORA das Drittparteirisiko ausdrücklich als Bestandteil des ICT-Rahmens. Finanzunternehmen müssen auf Einzel-, Teilkonzern- und Konzernebene ein Register über alle vertraglichen Vereinbarungen zu ICT-Services führen und aktuell halten. Zusätzlich muss unterschieden werden, welche Leistungen kritische oder wichtige Funktionen betreffen und welche nicht.
Damit verschiebt sich die operative Frage sofort. Wer das Register nur als jährliche Meldung versteht, organisiert es meist als späten Export. Wer denselben Artikel ernst nimmt, muss es näher an Risiko, Betrieb und Beschaffung aufbauen. Denn dieselben Informationen werden gebraucht, um neue Verträge zu bewerten, Konzentrationsrisiken zu erkennen, kritische Funktionen sauber zu markieren, Exit-Strategien vorzubereiten und der Aufsicht auf Anfrage belastbare Ausschnitte liefern zu können.
Das ist auch der Grund, warum reines Nachpflegen aus Vertragsarchiven selten reicht. Ein Vertrag sagt häufig, wer der Vertragspartner ist und wie der Service heißt. Für DORA reicht das nicht. Entscheidend ist, welche Geschäftsfunktion oder welches Betriebsmodell an dem Service hängt, welche Daten oder Plattformen betroffen sind, wo Leistungen erbracht werden, welche Subunternehmer beteiligt sind und wie sich das Ganze bei Ausfall oder Kündigung tatsächlich auswirkt.
Eigentümerschaft schlägt Fleiß
Die meisten Datenlücken im Register sind keine Schreibfehler, sondern Zuständigkeitslücken. Irgendjemand muss fachlich verantworten, welcher Service eingekauft wurde. Jemand anderes muss bewerten, ob damit eine kritische oder wichtige Funktion unterstützt wird. Wieder jemand anderes muss die technische Abhängigkeit, den Speicherort, die Datennutzung oder die operative Rückfallfähigkeit beschreiben. Fehlt diese klare Eigentümerschaft, beginnt das bekannte Pingpong zwischen Einkauf, Vendor Management, IT, Fachbereich und Compliance.
Genau deshalb ist ein gutes DORA-Register kein reines Datenmodell, sondern ein Betriebsmodell mit festen Rollen. Sinnvoll ist meist eine Dreiteilung. Erstens braucht es einen vertraglichen Owner für die wirtschaftliche und formale Beziehung. Zweitens einen Service- oder Funktions-Owner für Kritikalität, Nutzung und fachlichen Zweck. Drittens einen technischen Owner für Architektur, Datenflüsse, Standorte, Wiederanlauf und Subunternehmerpfade. Ohne diese Dreiteilung landet zu viel implizites Wissen in Mails, Ausschreibungen oder persönlichen Notizen.
Dieser Punkt ist wichtiger als viele Tool-Diskussionen. Ein schwaches Tool mit klaren Ownern produziert oft schneller belastbare Daten als ein starkes Tool ohne klare Verantwortung. Umgekehrt skaliert auch das beste Registersystem nicht, wenn niemand verbindlich sagen kann, welche Funktion an einem Provider hängt oder ob ein nachgelagerter Dienstleister geschäftskritische Leistungen berührt.
Unterauftragsketten machen aus Verträgen Betriebsrisiko
Artikel 29 und 30 verschärfen den Blick zusätzlich. DORA verlangt vor Vertragsabschluss die Prüfung von Drittparteirisiken, möglicher Konzentration und der Frage, ob ein Anbieter leicht ersetzbar ist. Für kritische oder wichtige Funktionen wird außerdem relevant, ob Subcontracting erlaubt ist, wo Leistungen und Daten verarbeitet werden, welche Informationspflichten bestehen, wie Audits laufen und wie ein Exit praktisch vorbereitet wird.
Gerade lange Unterauftragsketten werden intern oft unterschätzt. Ein Hauptvertrag kann sauber aussehen, während wesentliche Betriebsanteile längst bei weiteren Providern liegen: Hosting, Support, Backup, Observability, Messaging, Identität oder regionale Delivery-Komponenten. DORA fragt hier nicht aus Neugier nach. Die Aufsicht will verstehen, ob ein Institut die ausgelagerte Leistung tatsächlich noch überwachen kann und ob kritische Funktionen am Ende an wenigen schwer ersetzbaren Knoten hängen.
Für die Praxis heißt das: Das Register muss mehr leisten als Lieferantenlisten. Es muss sichtbar machen, welche Vertragsbeziehung nur administrativ ist und welche operative Tragweite hat. Wer nur den Hauptanbieter erfasst, aber Unterauftrag, Verarbeitungsorte oder Rückholpfade nicht sauber modelliert, unterschätzt genau jene Risiken, die DORA im Drittparteimanagement adressieren will.
Die ersten Engpässe liegen meist bei Kritikalität und Vertragsgranularität
Die EBA hat die Vorbereitungsseite für die Registers-of-Information-Berichterstattung seit dem Wirksamwerden von DORA am 17. Januar 2025 deutlich ausgebaut. Dort sind nicht nur die offiziellen Templates und technischen Pakete gebündelt, sondern auch Hinweise zu Validierungen, Datenqualität und häufigen Problemen. Bereits der Dry Run mit fast 1.000 Finanzunternehmen zeigte laut ESAs, dass die Datenqualität nicht hoffnungslos ist, aber zusätzliche Anstrengung nötig bleibt, damit die Register für Aufsicht und CTPP-Benennung wirklich brauchbar werden.
Das ist ein wichtiger Befund, weil er die übliche Ausrede entkräftet, es gehe primär um ein kompliziertes Format. Natürlich spielen Taxonomie, Validierungen und CSV-Strukturen eine Rolle. Der schwierigere Teil liegt aber fast immer in der inhaltlichen Vorarbeit. Kritische Funktionen werden unterschiedlich bewertet, ein Vertrag deckt mehrere Services ab, derselbe Provider taucht unter verschiedenen Gesellschaften auf oder regionale Leistungserbringung wurde nie systematisch nachgezogen. Solche Probleme lassen sich nicht im letzten Importlauf heilen.
Deshalb sollten Programme früh an zwei Stellen härten. Erstens an einer wiederholbaren Klassifikation für kritische oder wichtige Funktionen. Zweitens an einer Regel, auf welcher Granularität Verträge, Services und Provider im Register geführt werden. Wer diese beiden Punkte offen lässt, erzeugt zwangsläufig Daten, die zwar formal befüllt, aber fachlich nicht vergleichbar sind.
Ein brauchbarer Aufbau beginnt nicht bei der Meldestrecke
Pragmatisch bewährt sich ein vierstufiger Aufbau. Zuerst wird das Provideruniversum grob geschnitten: welche Verträge, Services und Gesellschaften gehören überhaupt in den Scope. Danach folgt die Zuordnung zu Funktionen, Eigentümern und Kritikalität. Drittens werden für kritische oder wichtige Funktionen die vertieften DORA-Felder konsequent ergänzt: Standorte, Audit- und Informationsrechte, Exit-Annahmen, Subcontracting und Datenrückführung. Erst im vierten Schritt lohnt sich die Härtung für Format, Validierungen und Abgabewege.
Das klingt banal, verhindert aber ein verbreitetes Anti-Pattern. Viele Teams beginnen bei den Pflichtfeldern des Templates und merken erst später, dass die Organisation auf Kernfragen keine gemeinsame Antwort hat. Dann werden Daten im Nachhinein „passend gemacht“, statt systematisch erhoben. Für die laufende Aufsicht ist das riskant, weil das Register nicht nur einmalig stimmen muss, sondern bei Vertragsänderungen, neuen Services und geänderter Kritikalität weiter belastbar bleiben soll.
Ein gutes Register-Operating-Model arbeitet deshalb mit klaren Triggern: neuer ICT-Vertrag, wesentliche Vertragsänderung, geänderter Datenstandort, neues Subcontracting, neue kritische Funktion, Exit-Plan-Anpassung, Provider-Incident mit Neubewertung. Erst diese Trigger machen aus einem Projekt ein dauerhaft steuerbares Objekt.
Fazit
Am DORA-Register scheitert selten das Template. Schwieriger ist die Eigentümerschaft über Verträge, Funktionen und Unterauftragsketten. Artikel 28 bis 30 machen deutlich, dass das Register kein isoliertes Meldeartefakt ist, sondern in Risiko-Management, Drittparteisteuerung, Auditierbarkeit und Exit-Fähigkeit eingreift. Wer nur die Datei baut, aber die Rollen und Trigger nicht, produziert Papierstabilität statt operativer Resilienz.
Für IT-Leitungen, Vendor Manager, Compliance und Service-Owner liegt der Hebel deshalb nicht zuerst im Tool, sondern im Betriebsmodell. Erst wenn klar ist, wer welche Aussage zum Provider, zur Funktion, zum Vertragsinhalt und zur Unterauftragskette verbindlich verantwortet, wird das DORA-Register von einer Meldepflicht zu einer tatsächlich brauchbaren Steuerungsfläche.
