Bildquelle: Bildquelle: Foto von Pixabay auf Pexels – https://www.pexels.com/photo/gray-high-rise-building-462216/
Für DORA reicht kein Lieferantenregister. Verträge, Services und kritische Funktionen müssen zusammenlaufen
Viele Finanzunternehmen und ihre IT-Organisationen merken gerade, dass DORA in der Praxis nicht an einem fehlenden Policiesatz scheitert, sondern an widersprüchlichen Listen. Der Einkauf kennt Lieferanten und Vertragslaufzeiten. Die CMDB kennt technische Systeme. Das Service-Management kennt Betriebsverantwortliche und Eskalationswege. Die Fachbereiche wissen, welche Prozesse wirklich kritisch sind. Sobald diese vier Sichtweisen nicht sauber zusammenfinden, wird das Register zu ICT-Drittparteien schnell zu einer formalen Fleißarbeit statt zu einem belastbaren Steuerungsinstrument.
Genau hier setzt DORA deutlich härter an, als viele Teams zunächst vermuten. Die EBA beschreibt das Register of Information ausdrücklich als umfassende Übersicht über vertragliche Vereinbarungen mit ICT-Drittanbietern auf Unternehmens-, Teilkonsolidierungs- und Konsolidierungsebene. Dieses Register dient nicht nur der internen Ordnung, sondern der Aufsicht und der Bewertung von Drittparteirisiken. Anders gesagt: Es geht nicht darum, irgendeine Tabelle abzugeben, sondern darum, ein Bild liefern zu können, das bei Rückfragen standhält.
Für IT-Management, Provider-Steuerung und Service-Owner ist das eine wichtige Verschiebung. Ein DORA-Register ist keine verlängerte Excel-Liste aus dem Einkauf. Es ist ein Betriebsartefakt, das nur dann trägt, wenn Vertrag, Service, Kritikalität, Verantwortlichkeit und Ausstiegspfad dieselbe Realität beschreiben.
Ein Lieferant allein ist noch keine steuerbare ICT-Auslagerung
Der erste praktische Fehler liegt in der Einheit, die überhaupt gepflegt wird. Viele Organisationen starten mit einer Lieferantenliste auf Rechtsträger-Ebene. Das ist verständlich, aber für DORA oft zu grob. Ein einzelner Anbieter kann mehrere Leistungen liefern, die operativ völlig unterschiedlich zu bewerten sind: ein Standard-SaaS für interne Zusammenarbeit, ein Managed Service mit privilegiertem Zugriff oder eine Plattform, die direkt an einer kritischen Funktion hängt.
Gerade deshalb ist die servicebezogene Sicht so wichtig. Der praktische DORA-Alltag beginnt nicht bei der Frage „Mit wem haben wir einen Vertrag?“, sondern bei der Frage „Welche konkrete ICT-Leistung stützt welchen Geschäftsprozess und unter welchen Abhängigkeiten?“. Erst wenn diese Zuordnung sauber ist, lassen sich Kritikalität, Kontrollbedarf, Audit-Rechte und Exit-Risiken vernünftig bewerten.
Wer nur den Lieferanten verwaltet, bekommt schnell Scheingenauigkeit. Dann steht ein großer Name korrekt im Register, aber niemand kann auf Anhieb erklären, welche Anwendungen, Nutzergruppen oder Betriebsprozesse tatsächlich daran hängen. Genau diese Lücke fällt später bei Prüfungen oder im Incident besonders unangenehm auf.
Das Register wird erst belastbar, wenn Service-Katalog und Vertragswelt dieselbe Sprache sprechen
In vielen Häusern beschreiben verschiedene Teams dieselbe Leistung mit unterschiedlichen Begriffen. Im Vertrag steht vielleicht „Hosting und Support“, im Service-Katalog „Geschäftsanwendung X“, in der CMDB mehrere Plattformobjekte und im Risikoreview ein allgemeiner Cloud-Eintrag. Solange diese Begriffe nicht auf eine gemeinsame Service-Taxonomie abgebildet werden, bleibt das Register formal vorhanden, aber operativ schwer nutzbar.
Praxisnah heißt das: Für jede relevante ICT-Drittleistung sollte erkennbar sein, welcher Service gemeint ist, welche technische Plattform dahintersteht, welcher Vertrag sie absichert und wer intern dafür die Verantwortung trägt. Genau an dieser Stelle wird aus Compliance-Arbeit ein Führungsinstrument. Erst dann kann ein Team nachvollziehen, ob mehrere kritische Funktionen unbemerkt am selben Provider hängen, ob ein Vertragswechsel mehrere Services gleichzeitig berührt oder ob ein Incident auf einen einzelnen Dienst begrenzt bleibt.
Die praktische Arbeit ist dabei unspektakulär, aber entscheidend. Stammdaten aus Einkauf, Vertragsablage, Service-Katalog, IAM-, SSO- oder Security-Tools und Ownership-Listen müssen nicht perfekt identisch sein, aber sie müssen auf dieselben Kernelemente zeigen. Wenn diese Verknüpfung fehlt, ist das Register im Ernstfall zu langsam.
Kritische Funktionen brauchen einen sichtbaren Anschluss an Ownership und Risiko
DORA interessiert sich nicht für Lieferantenverzeichnisse um ihrer selbst willen. Relevant ist, welche Drittleistungen kritische oder wichtige Funktionen stützen und wie daraus gesteuerte Risiken abgeleitet werden. Genau deshalb reicht es nicht, im Register einfach ein Häkchen für „kritisch“ zu setzen. Die Klassifikation muss nachvollziehbar sein und an echte Verantwortlichkeiten anschließen.
Für den Betrieb bedeutet das: Jede als kritisch eingestufte Leistung braucht einen benannten internen Owner, klare Eskalationswege und eine verständliche Begründung, warum sie für das Unternehmen kritisch oder wichtig ist. Sonst entsteht ein typisches Prüfproblem. Das Risikoteam kennt zwar die Kritikalität, aber Operations, Service-Desk oder Provider-Management können nicht sagen, welche Reaktionspflichten daraus folgen.
Hilfreich ist deshalb eine einfache Brücke zwischen Register und Betriebsmodell: Welche Services betreffen kritische Funktionen? Welche davon haben privilegierte Zugriffe oder sensible Datenflüsse? Welche hätten bei 24 Stunden Ausfall unmittelbare operative oder regulatorische Folgen? Sobald diese Fragen strukturiert beantwortbar sind, wird das Register von einer Nachweispflicht zu einem echten Steuerungsobjekt.
Vertragsklauseln, Sub-Outsourcing und Exit dürfen nicht neben dem Register herlaufen
Eine zweite häufige Schwäche entsteht, wenn das Register nur den Bestand zeigt, aber nicht die Qualität der Vereinbarung. Gerade bei ICT-Drittparteien reicht es nicht, Namen und Laufzeiten zu sammeln. Entscheidend ist auch, ob Audit- und Zugriffsrechte, Meldepflichten, Sub-Outsourcing-Regeln, Standortinformationen und Exit-Vorkehrungen im Vertrag und im laufenden Steuerungsmodell wirklich abgebildet sind.
Der praktische DORA-Nutzen entsteht genau aus dieser Verbindung. Wenn ein Anbieter Subunternehmer in kritischen Betriebsbereichen nutzt, muss das nicht nur juristisch irgendwo erwähnt sein, sondern im operativen Risikobild auftauchen. Wenn ein Exit theoretisch vorgesehen ist, aber Datenexporte, Rollenübergaben oder Konfigurationsübernahmen nicht beschrieben sind, ist der Ausstiegspfad eben nicht belastbar. Und wenn mehrere Verträge denselben technischen Dienst stützen, gehört auch diese Abhängigkeit sichtbar ins Register oder in die angeschlossene Steuerungslogik.
Für IT-Leitungen heißt das: Das Register sollte nicht als Endprodukt verstanden werden, sondern als Knotenpunkt zwischen Vertragssteuerung, Service-Architektur und Notfall- bzw. Exit-Fähigkeit.
Aktualität ist unter DORA kein Verwaltungsdetail, sondern eine laufende Kontrolle
Besonders unterschätzt wird die Pflege. Viele Teams denken noch in periodischen Aufräumaktionen vor Audits oder Aufsichtsanfragen. Genau das ist bei DORA zu wenig. Ein Register verliert seinen Wert schon dann, wenn neue SaaS-Dienste im Fachbereich auftauchen, Vertragsverlängerungen ohne technische Neubewertung durchlaufen oder Plattformwechsel nicht bis in die Ownership- und Kritikalitätsfelder nachgezogen werden.
Deshalb sollte „aktuell halten“ nicht als Nachpflege organisiert sein, sondern als fester Bestandteil von Onboarding, Vertragsänderung, Renewal, Architekturfreigabe und Provider-Offboarding. Jedes Mal, wenn sich Service-Scope, kritische Funktion, Speicherort, privilegierter Zugriff oder Exit-Annahme ändert, muss das Register mitwandern. Sonst entstehen genau die Lücken, die DORA eigentlich schließen will: scheinbar vollständige Bestände mit veralteter Aussagekraft.
Ein gutes Betriebsmodell erkennt man daran, dass Registerpflege keine Sonderaktion mehr ist. Sie hängt an normalen Arbeitsabläufen, besitzt klare Verantwortliche und wird über einfache Qualitätskontrollen abgesichert, etwa auf fehlende Owner, leere Kritikalitätsbegründungen oder widersprüchliche Service-Bezeichnungen.
Wie ein pragmatischer Start aussieht
Niemand muss sofort jede Altlast bereinigen. Ein sinnvoller Einstieg beginnt mit den Leistungen, die eindeutig kritische oder wichtige Funktionen unterstützen. Für diese Gruppe sollten Teams zuerst fünf Dinge sauber machen: die servicebezogene Zuordnung, den internen Owner, den Vertragsbezug, die Abhängigkeit zu kritischen Funktionen und den groben Exit- bzw. Sub-Outsourcing-Status.
Danach lohnt sich ein Abgleich mit bestehenden Inventaren: Wo stimmen Lieferantenliste und Service-Katalog nicht überein? Welche Leistungen laufen zwar produktiv, haben aber keinen klaren Business Owner? Wo ist die Kritikalität dokumentiert, aber nicht mit konkreten Vertrags- oder Architekturinformationen verknüpft? Genau in diesen Differenzen steckt meist der größte operative Gewinn.
Wichtig ist, das Register nicht isoliert in Compliance oder Einkauf zu parken. Tragfähig wird es erst, wenn Provider-Management, IT-Risiko, Service-Owner, Architektur und Betriebsverantwortung regelmäßig an denselben Datensätzen arbeiten. Dann kann das Register nicht nur abgegeben werden, sondern im Alltag tatsächlich helfen.
Fazit
DORA verlangt kein hübscheres Lieferantenverzeichnis, sondern ein belastbares Bild darüber, welche ICT-Drittleistungen kritische Funktionen tragen und wie diese Abhängigkeiten geführt werden. Genau deshalb reicht eine reine Vertrags- oder Einkaufssicht nicht aus. Erst wenn Verträge, Services, Ownership, Kritikalität und Exit-Pfade zusammenlaufen, wird das Register zu einem Instrument, das Aufsicht, Betrieb und Provider-Steuerung zugleich unterstützt. Wer das früh als Betriebsarbeit versteht, spart sich später hektische Nachpflege und gewinnt eine deutlich realistischere Sicht auf Drittparteirisiken.
