Wissensraum · Deep Dive 6 von 27
Warum Verträge allein nicht schützen
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.
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.
Fokus auf SLAs, Haftung und Verfügbarkeit
Keine Abbildung der realen Systemarchitektur
Keine laufende operative Überwachung
Unzureichend für kritische oder wesentliche Dienstleistungen
Einordnung
Verträge definieren Erwartungen, schaffen aber keine operative Transparenz über Risiken.
Vendor Questionnaires und Selbsteinschätzungen
Häufig standardisierte oder nicht verifizierbare Antworten
Geringe Aussagekraft zu tatsächlichen Abhängigkeiten
Kaum verlässliche Überprüfung technischer Kontrollen
Einbindung von Dienstleistern in die eigene System- und Prozessarchitektur
Transparenz über Datenflüsse und technische Abhängigkeiten
Definierte Kontrollen, KPIs und Überwachungsmechanismen
Regelmäßige, nachvollziehbare Überprüfung
Klassifikation von ICT-Drittdienstleistern nach Kritikalität
Risikoanalysen pro Dienstleistung, nicht nur pro Vertrag
Exit-Strategien für kritische oder wesentliche Dienstleistungen
Laufende Überwachung der Dienstleister
Überprüfung der Wirksamkeit von Kontrollen, nicht nur der Dokumentation
Integration von Third-Party Risks in Incident Management
Vollständige Nachvollziehbarkeit der Bewertungen und Entscheidungen
Kernlogik Drittdienstleister werden risikoseitig wie Bestandteile des eigenen Systems betrachtet.
Ausgangslage
Ein Versicherungsunternehmen nutzt einen externen Dienstleister zur Dokumentenerstellung. Der Vertrag ist formal korrekt: SLAs, Sicherheitsanforderungen und Verfügbarkeiten sind definiert.
Was passiert
Das Kernsystem ist über eine interne API eng mit dem Dienstleister verbunden. Als das externe System ausfällt: Interne Prozesse stehen still, Policen können nicht erstellt werden, regulatorische Fristen werden verpasst, der Audit-Trail reißt ab.
Erkenntnisse aus der Analyse
Der Dienstleister wurde nicht als kritisch eingestuft
Die API-Abhängigkeit war technisch nicht überwacht
Logging war unvollständig und nicht auswertbar
Die Exit-Strategie existierte nur konzeptionell – ein technisches Failover fehlte
Kernproblem
Der Fragebogen war korrekt ausgefüllt. Die operative Abhängigkeit wurde jedoch nicht verstanden.
Bewertung der Kritikalität nach Prozess- und Systemabhängigkeit – nicht nach Dienstleisterkategorie.
Architektur- und Abhängigkeits-Mapping: Sichtbarmachung von Datenflüssen, APIs und technischen Kontrollen.
Monitoring und KPIs: Laufende Überwachung von Verfügbarkeit, Latenz und Fehlerquoten.
Echte Exit-Strategien: Technisch getestetes Failover oder klar definierte manuelle Fallbacks.
Regelmäßige technische und organisatorische Verifikation: Funktionale Prüfungen statt reiner Dokumentenkontrolle.
Praxis-Impuls
Third-Party Risk ist kein Vertragsthema – sondern eine Frage von Systemverständnis und Kontrolle. Fragen Sie für jeden kritischen Dienstleister: Wissen wir, was passiert, wenn er ausfällt? Haben wir das je getestet?