Wissensraum · Deep Dive 27
Die erste Frage im DORA-Audit lautet fast immer: «Zeigen Sie mir Ihr ICT-Drittanbieter-Register.» Was danach passiert, entscheidet sich nicht im Audit – sondern in den Monaten davor.
Was dieser Deep Dive Ihnen zeigt
Was das ICT-Drittanbieter-Register nach DORA Art. 28 tatsächlich enthalten muss – und warum eine Vendorliste, ein Confluence-Eintrag oder eine Excel-Übersicht der Anforderung nicht genügt.
DORA Art. 28 verpflichtet Finanzunternehmen, ein vollständiges Register aller ICT-Drittdienstleister zu führen und aktuell zu halten. Das Register ist nicht ein Compliance-Dokument unter vielen – es ist die Grundlage für sämtliche weitere Drittanbieter-Governance: Risikoanalysen, Vertragsprüfungen, Exit-Strategien, Resilienztests und das Monitoring kritischer Abhängigkeiten.
Aufsichtsbehörden beginnen DORA-Prüfungen regelmäßig mit der Aufforderung: «Zeigen Sie mir Ihr Register.» Was sie sehen, bestimmt den Verlauf des gesamten Audits. Ein vollständiges, strukturiertes, aktuelles Register signalisiert: Diese Organisation hat DORA verstanden. Eine Vendorliste aus dem Beschaffungssystem signalisiert das Gegenteil.
Einordnung
Das Register ist kein statisches Dokument. DORA verlangt, dass es «auf dem neuesten Stand» gehalten wird – Art. 28 Abs. 3. Eine Übersicht, die vor 18 Monaten erstellt und seitdem nicht aktualisiert wurde, erfüllt die Anforderung nicht.
Der häufigste Fehler: Unternehmen verwechseln ihr Beschaffungssystem oder ihre Vertragsdatenbank mit dem ICT-Register nach DORA. Der Unterschied liegt nicht in der Form, sondern im Inhalt und in der Logik.
Eine Vendorliste enthält alle Lieferanten mit aktiven Rechnungsbeziehungen. Das ICT-Register nach DORA enthält alle ICT-Drittdienstleister – unabhängig davon, ob die Beziehung vertraglich formalisiert ist, ob Gebühren anfallen und ob der Anbieter intern als «IT-Dienstleister» klassifiziert wird. Ein Softwarehersteller, der eine in kritische Prozesse eingebettete Bibliothek pflegt, gehört ins Register. Ob er eine Rechnung stellt, ist irrelevant.
Art. 28 Abs. 3 DORA verlangt, dass Finanzunternehmen diejenigen Drittdienstleister identifizieren, die kritische oder wesentliche Funktionen unterstützen. Das ist keine Ja/Nein-Entscheidung, sondern eine begründete Bewertung: Welche Geschäftsprozesse hängen an diesem Dienstleister? Was passiert bei Ausfall? Wie schnell kann gewechselt werden? Ohne Kritikalitätsklassifikation ist das Register regulatorisch wertlos.
DORA Art. 28 Abs. 2 lit. d verlangt Transparenz über Drittdienstleister der Drittdienstleister – Sub-Outsourcing. Ein Cloud-Provider, der seinerseits kritische Dienste auslagert, erzeugt Abhängigkeiten, die im eigenen Register sichtbar sein müssen. Das ist das am häufigsten übersehene Element – und das Element, das in DORA-Audits am häufigsten zu Findings führt.
Für jeden als kritisch oder wesentlich eingestuften Dienstleister verlangt DORA Art. 28 Abs. 2 lit. e eine dokumentierte Exit-Strategie. Diese muss nicht im Register selbst ausformuliert sein – aber das Register muss auf sie verweisen und zeigen, dass sie existiert. Ein Register ohne Exit-Referenzen ist für kritische Dienstleister unvollständig.
DORA Art. 28 Abs. 2 definiert den Mindestinhalt. Die folgende Tabelle zeigt, was für jeden Eintrag dokumentiert sein muss – und was über den Mindestinhalt hinaus operativ notwendig ist.
| Feld | DORA-Anforderung | Praktische Bedeutung |
|---|---|---|
| Name und Sitz | Art. 28 Abs. 2 lit. a – Pflicht | Vollständiger juristischer Name, Registrierungsland. Relevant für Rechtsordnung und regulatorische Zuordnung. |
| Art der Dienstleistung | Art. 28 Abs. 2 lit. b – Pflicht | Konkrete Leistungsbeschreibung – nicht «IT-Dienstleister», sondern «Cloud-Hosting kritischer Kernsysteme» oder «Authentifizierungsdienst». |
| Standorte der Datenverarbeitung | Art. 28 Abs. 2 lit. c – Pflicht | Wo werden Daten verarbeitet und gespeichert? Für Souveränitätsfragen, Datenschutz und regulatorische Compliance entscheidend. |
| Sub-Dienstleister | Art. 28 Abs. 2 lit. d – Pflicht | Welche weiteren Anbieter setzt der Dienstleister für die erbrachten Leistungen ein? Häufig nicht bekannt – muss aktiv erhoben werden. |
| Kritikalitätsklassifikation | Art. 28 Abs. 3 – Pflicht | Kritisch / Wesentlich / Standard – mit dokumentierter Begründung. Nicht optional für Dienstleister, die kritische Funktionen unterstützen. |
| Vertragsdatum und -laufzeit | Operativ erforderlich | Wann läuft der Vertrag aus? Relevant für Exit-Planung und Verlängerungsentscheidungen unter regulatorischen Anforderungen. |
| Exit-Strategie-Referenz | Art. 28 Abs. 2 lit. e – für kritische/wesentliche Dienstleister Pflicht | Verweis auf das Exit-Strategiedokument oder direkte Kurzbeschreibung des Ausstiegspfads. Nicht «TBD». |
| Verantwortlicher intern | Operativ erforderlich | Wer ist intern für diesen Dienstleister verantwortlich? Ohne Named Owner ist das Register nicht steuerbar. |
| Letztes Review-Datum | Aktualisierungspflicht Art. 28 Abs. 3 | Wann wurde der Eintrag zuletzt inhaltlich geprüft und bestätigt? Ohne Datum ist die Aktualitätspflicht nicht nachweisbar. |
Ein Register ohne Kritikalitätsklassifikation ist eine Adressliste. Ein Register ohne Exit-Referenzen für kritische Dienstleister ist unvollständig. Ein Register ohne letztes Review-Datum ist regulatorisch nicht vertretbar.
Die Kritikalitätsbewertung ist die intellektuell anspruchsvollste Aufgabe beim Aufbau des Registers. Sie ist keine Ja/Nein-Entscheidung, sondern eine strukturierte Risikobeurteilung entlang vier Dimensionen:
Ein Dienstleister ist kritisch, wenn sein Ausfall eine kritische oder wesentliche Funktion des Finanzunternehmens beeinträchtigt. Die Klassifikation folgt dem Prozess – nicht dem Dienstleistungstyp.
Ein Dienstleister mit hoher Substituierbarkeit – viele alternative Anbieter, geringe Migrationskosten – kann tiefer klassifiziert werden als ein Dienstleister mit faktischem Lock-in.
Was passiert konkret bei einem Ausfall von 27 oder 24 Stunden? Die Ausfallwirkungsanalyse verbindet den Dienstleister mit den RTO/RPO-Anforderungen der abhängigen Prozesse.
Wie viele kritische Prozesse hängen an diesem einen Anbieter? Das Register muss diese Aggregation sichtbar machen.
Einordnung
Die Kritikalitätsklassifikation ist eine Entscheidung des Managements – nicht der IT. DORA Art. 5 legt die Verantwortung für das ICT-Risikomanagement-Framework beim Leitungsorgan.
Das folgende Beispiel zeigt drei Einträge mit unterschiedlicher Kritikalitätsstufe.
| Anbieter | Leistung | Datenhaltung | Sub-Anbieter | Kritikalität | Exit-Strategie |
|---|---|---|---|---|---|
| CloudProvider AG | Hosting Kernsysteme, Zahlungsabwicklung | Frankfurt (DE) | Equinix, Akamai | Kritisch | Ja – EXIT-001 |
| AuthService GmbH | Authentifizierung / MFA | Amsterdam (NL) | AWS Frankfurt | Wesentlich | Ja – EXIT-004 |
| DocuSign Inc. | Elektronische Signatur | USA | AWS (USA) | Standard | Alternativanbieter verfügbar |
Ausgangssituation
Ein mittelgroßes Finanzdienstleistungsunternehmen bereitet sich auf eine DORA-Prüfung vor. Der CISO legt dem Prüfer eine Excel-Tabelle mit 214 Einträgen vor – alle Lieferanten, mit denen in den letzten drei Jahren Verträge bestanden haben.
Was folgt
Vier DORA-Findings: Fehlendes Register, keine Kritikalitätsklassifikation, keine Exit-Strategien für kritische Dienstleister, fehlende Sub-Outsourcing-Transparenz. Das Unternehmen erhält eine Nachbesserungsfrist von drei Monaten.
Die eigentliche Ursache
Niemand hatte den Unterschied zwischen einer Vendorliste und einem DORA-konformen Register erklärt. Das Beschaffungsteam hatte getan, was es konnte. Das Ergebnis war operativ plausibel – regulatorisch unbrauchbar.
Der Ausgangspunkt ist eine Vollerhebung aller ICT-Abhängigkeiten. Erfahrungsgemäß sind 20–40 % der tatsächlichen ICT-Abhängigkeiten nicht in der Vertragsdatenbank erfasst.
Die Bewertung wird schriftlich begründet – nicht als Ampelfarbe vergeben. Ein Auditor fragt nach der Begründung, nicht nach der Farbe.
Sub-Dienstleister-Information muss aktiv bei den Drittdienstleistern erhoben werden – DORA Art. 30 verlangt solche Klauseln für kritische und wesentliche Dienstleister.
Für jeden kritischen und wesentlichen Dienstleister muss eine Exit-Strategie existieren, die tatsächlich funktioniert: Migrationsdauer, Alternative, technische Voraussetzungen, Datenmigration.
Der Review-Zyklus für kritische Einträge: mindestens jährlich, bei wesentlichen Änderungen ad hoc. Das gesamte Register wird mindestens jährlich dem Leitungsorgan vorgelegt.
Was das Leitungsorgan wissen muss
Praxis-Impuls
Stellen Sie sich drei Fragen: Haben Sie ein Register, das alle ICT-Abhängigkeiten enthält? Enthält jeder Eintrag eine begründete Kritikalitätsklassifikation, Sub-Outsourcing-Information und Exit-Strategiereferenz? Wurde das Register in den letzten zwölf Monaten inhaltlich geprüft und dem Leitungsorgan vorgelegt?
Was bleibt
Eine Vendorliste ist kein ICT-Register. DORA verlangt ein strukturiertes Dokument mit Kritikalitätsklassifikation, Sub-Outsourcing-Transparenz und Exit-Strategiereferenzen.
Die Kritikalitätsklassifikation ist die wichtigste intellektuelle Leistung beim Registeraufbau. Sie folgt dem Prozess – nicht dem Vertragstyp – und muss begründet sein.
Sub-Outsourcing ist der häufigste blinde Fleck. Wer nicht weiß, welche Drittdienstleister seine eigenen Drittdienstleister einsetzen, erfüllt Art. 28 Abs. 2 lit. d nicht.
Das Register ist Chefsache. DORA Art. 5 legt die Verantwortung für das ICT-Risikomanagement beim Leitungsorgan. Das Register ist das zentrale Dokument dieses Systems.