Wissensraum · Deep Dive 12 von 27
Warum Verträge allein keine Resilienz schaffen
Was dieser Deep Dive Ihnen zeigt
Warum Verträge allein keine Resilienz schaffen – und was bei Outsourcing unter DORA wirklich zählt.
DORA verändert den Umgang mit Auslagerungen grundlegend. Unternehmen müssen nicht mehr nur vertragliche Risiken steuern, sondern die tatsächliche operative Resilienz ihrer Dienstleister verstehen und kontrollieren.
Zentraler Grundsatz unter DORA: Die Verantwortung für ICT-Risiken verbleibt beim auslagernden Unternehmen – unabhängig von vertraglichen Regelungen. Outsourcing reduziert operative Lasten, aber nicht die regulatorische Verantwortung.
Fokus auf SLAs, Auftragsverarbeitungsvereinbarungen und Haftungsregelungen
Kaum technische oder architektonische Einordnung
Keine systematische Überprüfung realer Kontrollen
Risiken werden formal adressiert, operativ jedoch nicht gesteuert
Einordnung
Verträge definieren Erwartungen, ersetzen aber keine operative Kontrolle.
Strukturierte Risikoanalysen
Regelmäßige Reviews
Nachweise wie Zertifikate oder Penetrationstests
Geringe Einbettung in die eigene System- und Prozessarchitektur
Abhängigkeiten und Wechselwirkungen bleiben oft unklar
Einbindung von Dienstleistern in die eigene Resilienz- und Architekturbetrachtung
Klare Zuordnung zu kritischen oder wesentlichen Funktionen
Transparenz über technische Schnittstellen und Datenflüsse
Integration in Monitoring, Logging und Incident Management
Definierte Exit-, Substitutions- und Portabilitätsstrategien
Klassifikation von Auslagerungen nach Kritikalität
Risikobasierte Analyse je Dienstleistung
Nachweis der Wirksamkeit von Kontrollen – nicht nur ihrer Existenz
Integration in Incident-, Business-Continuity- und Testing-Prozesse
Transparenz über Sub-Outsourcing-Strukturen
Exit- und Substitutionsmechanismen für kritische Auslagerungen
Kernlogik Nicht der Vertrag allein schützt – sondern die zugrunde liegende Struktur.
Ausgangslage
Ein Versicherungsunternehmen lagert sein Kundendaten-Reporting an einen externen SaaS-Anbieter aus. Der Vertrag ist umfassend und formal korrekt.
Was passiert
Der Anbieter führt ein Systemupdate ohne abgestimmtes Change-Management durch. In der Folge werden Daten unvollständig verarbeitet. Der Vorfall wird verspätet gemeldet.
Analyse zeigt
SLAs sind klar definiert – technische Realität: keine Test- oder QA-Umgebung
Kein Monitoring der Datenqualität
Fehlende Architektur- und Abhängigkeitsübersicht
Subdienstleister waren nicht bekannt
Konsequenzen
Fehlerhafte Berichterstattung gegenüber der Aufsicht
Meldepflichtiger Incident
Reputationsrisiken
Praxis-Impuls
Unter 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: Wissen wir, wer die Subdienstleister unserer kritischen Anbieter sind?
Was bleibt
Third-Party Risk ist nicht Vertragsmanagement. DORA verlangt technische Audits, Incident Reporting und Exit-Szenarien – Verträge alleine reichen nicht.
Outsourcing ändert nicht die Verantwortlichkeit. Der Kunde trägt die Verantwortung für Sicherheit und Verfügbarkeit, auch wenn ein Dritter die Systeme betreibt. Das ist eine Kernaussage von DORA und NIS2.
Die Abgrenzung zu klassischem Outsourcing ist regulatorisch. DORA unterscheidet «kritische» und «wichtige» Drittanbieter – mit unterschiedlichen Anforderungen. Klassisches Outsourcing-Management ist dafür zu grob.
Sub-Auftragnehmer sind Ihre Verantwortung. Wenn Ihr Cloud-Provider weitere Subunternehmer nutzt, müssen Sie das transparent dokumentieren und das Risiko bewerten. Das wird häufig übersehen.