Was dieser Deep Dive Ihnen zeigt
Warum Third-Party Risk Management unter DORA mehr ist als Vendor-Listen – und welche vertraglichen, operativen und strategischen Anforderungen jetzt gelten.
DORA rückt das Management von Risiken aus ICT-Drittdienstleistungen ins Zentrum der operativen Resilienz. Die Verordnung trägt damit der Realität Rechnung, dass ein erheblicher Teil der Verwundbarkeit moderner Organisationen aus ausgelagerten Leistungen und Abhängigkeiten entsteht. Ein zentraler Grundsatz dabei: Die Verantwortung für ICT-Risiken verbleibt beim auslagernden Unternehmen – unabhängig von vertraglichen Regelungen. Outsourcing reduziert operative Lasten, aber nicht die regulatorische Verantwortung.
In vielen Unternehmen besteht Third-Party Risk Management jedoch im Wesentlichen aus vertraglichen Regelungen und Selbstauskünften der Dienstleister. Diese Instrumente bleiben wichtig, reichen unter DORA jedoch nicht aus. Gefordert ist strukturelle Kontrolle, nicht lediglich formale Absicherung. Verträge definieren Erwartungen, schaffen aber keine operative Transparenz über tatsächliche Abhängigkeiten und Risiken.
1. Drei Ansätze im Third-Party Risk Management – und ihre Grenzen
A) Vertragsbasierter Ansatz (klassisch, für DORA nicht ausreichend)
Fokus auf SLAs, Haftung und Verfügbarkeit
Keine Abbildung der realen Systemarchitektur
Keine laufende operative Überwachung
Unzureichend für kritische oder wichtige Dienstleistungen
Einordnung
Verträge definieren Erwartungen, schaffen aber keine operative Transparenz über Risiken.
B) Prozess- und kontrollbasierter Ansatz (weiterentwickelt, aber oft unvollständig)
Strukturierte Risikoanalysen und regelmäßige Reviews
Nachweise wie Zertifikate, Penetrationstests oder Vendor-Fragebogen
Definierte Security Standards und dokumentierte Kontrollen
Geringe Einbettung in die eigene System- und Prozessarchitektur – Abhängigkeiten und Wechselwirkungen bleiben oft unklar
C) Integrationsorientierter Ansatz (DORA-orientierter Ansatz)
Einbindung von Dienstleistern in die eigene Resilienz- und Architekturbetrachtung
Klare Zuordnung zu kritischen oder wichtigen Funktionen
Transparenz über technische Schnittstellen, Datenflüsse und Sub-Outsourcing-Strukturen
Integration in Monitoring, Logging und Incident Management
Definierte Exit-, Substitutions- und Portabilitätsstrategien
2. Welche Anforderungen sich aus DORA ergeben
Klassifikation der ICT-Dienstleistungen danach, ob sie kritische oder wichtige Funktionen unterstützen – nicht pauschale Einstufung des gesamten Anbieters
Risikoanalysen pro Dienstleistung, nicht nur pro Vertrag
Transparenz über Sub-Outsourcing-Strukturen – Wer sind die Subdienstleister Ihrer kritischen Anbieter?
Exit-Strategien für kritische oder wichtige Dienstleistungen
Laufende, zu Risiko und Kritikalität proportionale Überwachung der Dienstleister mit definierten KPIs
Überprüfung der Wirksamkeit von Kontrollen, nicht nur der Dokumentation
Integration von Third-Party Risks in Incident-, Business-Continuity- und Testing-Prozesse
Vollständige Nachvollziehbarkeit der Bewertungen und Entscheidungen
Kernlogik
Drittdienstleister werden risikoseitig wie Bestandteile des eigenen Systems betrachtet.
3. Fallstudie
Ausgangslage
Ein Versicherungsunternehmen lagert sein Kundendaten-Reporting an einen externen SaaS-Anbieter aus. Ein zweiter Dienstleister stellt Dokumentenerstellung bereit. Der Hauptvertrag zum SaaS-Anbieter ist formal korrekt: SLAs, Sicherheitsanforderungen und Verfügbarkeiten sind definiert.
Was passiert
Das Kernsystem ist über eine interne API eng mit beiden Dienstleistern verbunden. Der SaaS-Anbieter führt ein Systemupdate durch, ohne abgestimmtes Change-Management. Der API-Dienstleister ist zu dieser Zeit nicht erreichbar. In der Folge werden Daten unvollständig verarbeitet, Policies können nicht erstellt werden, regelmäßige Fristen werden verpasst, der Audit-Trail reißt ab. Der Vorfall wird verspätet gemeldet, die Subunternehmer-Struktur war nicht transparent.
Erkenntnisse aus der Analyse
Die SaaS-Anbieter wurden zwar als kritisch eingestuft, aber technische Realität: Keine Test- oder QA-Umgebung vorhanden
Die API-Abhängigkeiten waren konzeptionell bekannt, aber nicht technisch überwacht
Monitoring der Datenqualität fehlte völlig
Logging war unvollständig und nicht auswertbar
Subdienstleister waren nicht transparent dokumentiert – regulatorische Anforderung nicht erfüllt
Die Exit-Strategie existierte nur konzeptionell – ein technisches Failover oder klares manuelles Fallback fehlte
Kernproblem
Der Fragebogen war korrekt ausgefüllt. Die operative Abhängigkeit wurde jedoch nicht verstanden. Verträge allein schaffen keine Transparenz über tatsächliche Systemintegration und Sub-Outsourcing-Strukturen.
Konsequenzen
Fehlerhafte Berichterstattung gegenüber der Aufsicht
Der erhebliche operative Vorfall musste auf seine Meldepflicht geprüft werden; die fehlende Sub-Dokumentation verzögerte Klassifikation und Kundeninformation
Reputationsrisiken
4. Wie Third-Party Risk Management unter DORA funktionieren muss
Bewertung der Kritikalität nach Prozess- und Systemabhängigkeit – nicht nach Dienstleisterkategorie.
Architektur- und Abhängigkeits-Mapping: Sichtbarmachung von Datenflüssen, APIs, technischen Kontrollen und Sub-Outsourcing-Strukturen.
Monitoring und KPIs: Laufende Überwachung von Verfügbarkeit, Latenz, Fehlerquoten und Datenqualität.
Praktikable, getestete Exit- und Übergangsmaßnahmen: je nach Dienst und Architektur etwa Failover, Portabilität, Anbieterwechsel, Insourcing oder manuelle Fallbacks — ein paralleles technisches Failover ist nicht für jede Leistung zwingend.
Regelmäßige technische und organisatorische Verifikation: Funktionale Prüfungen statt reiner Dokumentenkontrolle. Vendor-Performance, Incident-Historie, geografische Risiken und Key-Person-Dependencies regelmäßig überprüfen.
Transparente Dokumentation von Sub-Auftragnehmern und deren Kritikalität für die eigene Resilienz.
Praxis-Impuls
Under DORA wird Third-Party-Management zu Resilienzmanagement. Verträge bleiben wichtig, bilden jedoch nur den Rahmen. Resilienz entsteht dort, wo Dienstleister strukturell verstanden, technisch eingebunden und organisatorisch gesteuert werden. Fragen Sie für jeden kritischen Dienstleister: Wissen wir, was passiert, wenn er ausfällt? Haben wir das je getestet? Wer sind die Subdienstleister, und sind sie transparent dokumentiert?
Was bleibt
1
Third-Party Risk Management unter DORA ist kein Vendor-Onboarding-Prozess – es ist ein permanentes Resilienz-Regime mit vertraglichen, operativen und strategischen Anforderungen.
2
Die Auslagerung beseitigt nicht die regulatorische Verantwortung des Finanzunternehmens für seine eigene digitale operationale Resilienz. Der Dienstleister trägt daneben eigene vertragliche und gesetzliche Verantwortlichkeit. Das ist eine Kernaussage von DORA und NIS2.
3
Verträge sind der erste Governance-Punkt: Ohne schriftliche Vereinbarungen zu Security, Incident-Meldung, Audit-Rechten und Exit-Szenarien ist kein Third-Party-Risiko gesteuert. Aber Verträge allein schaffen keine operative Transparenz.
4
Risiken aus relevanten Unterauftragsketten bleiben Teil Ihrer eigenen DORA-Risikosteuerung: Subunternehmerketten angemessen berücksichtigen, Verträge prüfen, Konzentrations- und Standortrisiken bewerten, Änderungen steuern. Das wird häufig übersehen.
5
Operational Due Diligence muss kontinuierlich sein: Vendor-Performance, Incident-Historie, geografische Risiken, Key-Person-Dependencies und die operative Integration in Ihre Systeme müssen regelmäßig überprüft werden.