Bildquelle: Bildquelle: Pexels / Karola G / https://www.pexels.com/photo/person-signing-a-contract-7875831/
Provider-Ausstieg scheitert oft an Datenrückgabe, Zugängen und ungeübten Übergängen
Viele IT-Organisationen glauben, sie hätten das Risiko kritischer Dienstleister im Griff, sobald ein Vertrag Kündigungsrechte, Service Levels und Audit-Klauseln enthält. Im Alltag zeigt sich aber etwas anderes: Der echte Stresstest beginnt nicht bei der Unterschrift, sondern beim möglichen Ausstieg. Wer dann Daten nicht in verwertbarer Form zurückbekommt, Admin-Zugänge an Personen statt an Rollen hängen, Integrationen kaum dokumentiert sind oder niemand den Übergang zu einem Ersatzanbieter geprobt hat, besitzt zwar Vertragswerk, aber noch keinen belastbaren Exit-Pfad.
Genau dieser Unterschied wird regulatorisch immer sichtbarer. Die europäische Finanzaufsicht hat das Thema bei Outsourcing und digitaler Resilienz sehr konkret gemacht. Für IT-Leitungen außerhalb des Finanzsektors ist das ebenfalls relevant, weil dort in verdichteter Form beschrieben wird, was in praktisch jeder stärker ausgelagerten IT-Landschaft operativ schiefgehen kann: zu wenig Transparenz über den Lieferpfad, zu schwache Zugriffsrechte, ungetestete Übergänge und fehlende Datenrückgabe.
Ein Kündigungsrecht ist noch kein Ausstiegsplan
Die zentrale Fehlannahme lautet: Wenn der Vertrag eine Beendigung vorsieht, lässt sich der Anbieter im Zweifel schon austauschen. In Wirklichkeit trennt sich an dieser Stelle juristische Option von operativer Fähigkeit. Die Digital Operational Resilience Regulation (DORA) verlangt bei ICT-Drittdienstleistungen nicht nur Kündigungsrechte, sondern ausdrücklich auch Bestimmungen zur Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit von Daten, zur Rückgabe von Daten in leicht zugänglichem Format sowie zu Exit-Strategien und Übergangsfristen. Der Gedanke dahinter ist sehr praktisch: Ein Exit nützt nichts, wenn die Organisation den Betrieb danach nicht ohne Schaden fortsetzen kann.
Für das Management bedeutet das, Vertragsprüfung und Betriebsarchitektur nicht länger getrennt zu behandeln. Ein sauberer Vertrag kann nur dann wirken, wenn parallel geklärt ist, welche Daten exportiert werden müssen, in welchem Format sie ankommen, welche Identitäten und Berechtigungen betroffen sind, welche Schnittstellen neu verdrahtet werden müssen und welche Teams den Übergang tatsächlich steuern.
Warum Datenrückgabe fast immer zu spät konkretisiert wird
Der kritischste Punkt ist selten die abstrakte Frage, ob Daten zurückgegeben werden. Fast jeder Anbieter bestätigt das grundsätzlich. Problematisch wird die operative Qualität der Rückgabe. Sind historische Tickets, Logs, Wissensobjekte, Konfigurationsstände, Rollenmodelle und Reporting-Daten wirklich exportierbar? Kommen sie in einem Format, das ein anderer Anbieter oder ein internes Team weiterverwenden kann? Bleiben Referenzen, Zeitstempel und Anhänge vollständig erhalten? Gibt es Fristen, nach denen Daten nur noch gegen Zusatzkosten oder gar nicht mehr verfügbar sind?
DORA formuliert deshalb ausdrücklich, dass Zugang, Wiederherstellung und Rückgabe personenbezogener und nicht personenbezogener Daten in einem leicht zugänglichen Format sichergestellt werden müssen, gerade auch bei Insolvenz, Geschäftsaufgabe oder Vertragsende des Dienstleisters. Für IT-Service-Management und Provider Governance ist das ein wichtiger Hinweis: Datenportabilität ist keine Randnotiz für die Rechtsabteilung, sondern eine Kernanforderung an Betriebsfähigkeit, Auditierbarkeit und Wechseloption.
Zugänge, Rollen und Schnittstellen entscheiden über die reale Wechselbarkeit
Selbst wenn Daten exportierbar sind, scheitert ein Anbieterwechsel oft an abhängigen Zugängen und versteckten Betriebsobjekten. Typische Beispiele sind personenbezogene Admin-Konten beim Provider, hart verdrahtete API-Schlüssel, benutzergebundene Zertifikate, proprietäre Automationsskripte oder unvollständig dokumentierte Übergaben an den Service Desk. Dann hängt ein kritischer Service faktisch stärker am Betriebsmodell des Anbieters als am eigentlichen Vertrag.
Die EBA hat in ihren Outsourcing-Leitlinien bereits vor Jahren klargestellt, dass die Unternehmensleitung jederzeit verantwortlich bleibt und Outsourcing nicht dazu führen darf, dass ein Institut zur „empty shell“ ohne eigene Substanz wird. Übersetzt in allgemeine IT-Praxis heißt das: Wer kritische Leistungen auslagert, muss trotzdem genügend eigenes Verständnis, Dokumentation und Steuerungsfähigkeit behalten, um Risiken zu überwachen und im Ernstfall eingreifen zu können. Ein Provider darf operative Arbeit übernehmen, aber nicht das letzte verwertbare Wissen über Datenflüsse, Rechteketten und Wiederanlaufpfade monopolisieren.
Audit-Rechte helfen nur, wenn sie im Alltag benutzt werden
Viele Verträge enthalten Auskunfts-, Prüf- und Audit-Rechte, die im Normalbetrieb jedoch nie strukturiert eingesetzt werden. Dann merkt die Organisation erst im Konfliktfall, dass notwendige Nachweise nicht standardisiert vorliegen, Unterauftragnehmer unklar eingebunden sind oder sicherheitsrelevante Änderungen zu spät gemeldet wurden. DORA verlangt deshalb fortlaufende Überwachung, uneingeschränkte Zugangs-, Inspektions- und Audit-Rechte für kritische oder wichtige Funktionen sowie Kooperation des Anbieters bei Prüfungen.
Das sollte nicht nur als Spezialregel für Banken missverstanden werden. Auch außerhalb regulierter Branchen entsteht ein klarer Management-Nutzen, wenn Provider-Reviews nicht nur Verfügbarkeitswerte abhaken, sondern konkrete Ausstiegsvoraussetzungen prüfen: aktuelle Kontakt- und Eskalationsketten, dokumentierte Exportpfade, bekannte Abhängigkeiten zu Unterauftragnehmern, vorhandene Testdaten für Migrationen und belastbare Zeitannahmen für einen Übergang.
Exit-Strategien müssen geprobt werden, bevor sie gebraucht werden
Der stärkste Punkt in DORA ist nicht die Vertragsliste, sondern die Forderung nach dokumentierten, hinreichend getesteten Exit-Plänen. Das ist unbequem, aber fachlich zwingend. Ein ungeübter Exit-Plan ist oft nur eine Präsentation mit Pfeilen. Erst ein Test zeigt, ob Daten tatsächlich rechtzeitig kommen, welche manuellen Arbeitsschritte vergessen wurden, wie lange Parallelbetrieb möglich ist und ob der Ersatzpfad die Servicequalität hält.
Praktisch muss nicht jedes Unternehmen sofort einen Vollausstieg simulieren. Sinnvoll ist ein stufenweiser Ansatz: zunächst kritische Provider identifizieren, danach je Anbieter die minimal nötigen Exit-Artefakte definieren, etwa Dateninventar, Rollen- und Rechteübersicht, Integrationskarte, Kostenfallen, Mindestübergangszeit und Zielbild für Inhouse- oder Ersatzbetrieb. Anschließend sollten einzelne Bausteine getestet werden: Export eines repräsentativen Datensatzes, Umschalten eines Interfaces, Neuanlage administrativer Rollen oder Trockenübung für einen Service-Desk-Handover. So wird aus Governance ein belastbarer Betriebsmechanismus.
NIST beschreibt das Grundproblem breiter als reine Regulierung
NIST beschreibt in SP 800-161 zur Cybersecurity Supply Chain Risk Management sehr treffend, warum Organisationen mit Lieferantenrisiken kämpfen: Es fehlt oft an Sichtbarkeit darauf, wie eingekaufte Technologien und Services entwickelt, integriert und betrieben werden und welche Prozesse die Sicherheit, Resilienz und Qualität tatsächlich absichern. Genau diese Lücke zeigt sich auch bei ausgelagerten IT-Services. Wer nur Preise, SLAs und Vertragslaufzeiten steuert, aber nicht den operativen Lieferpfad versteht, merkt die Abhängigkeit häufig erst, wenn ein Sicherheitsvorfall, eine Preiserhöhung oder eine strategische Trennung ansteht.
Deshalb sollte Provider-Management nicht erst bei der Ausschreibung ansetzen und auch nicht bei Vendor-Scorecards enden. Es gehört in Architektur, Betrieb, Identity Governance, Service Continuity und Incident Response. Ein gut verhandelter Vertrag ist wertvoll. Entscheidend ist aber, ob die eigene Organisation einen Dienstleisterwechsel ohne Blindflug übersteht.
Fazit
Provider-Risiko wird nicht in dem Moment beherrschbar, in dem ein Vertrag unterschrieben ist, sondern in dem Moment, in dem Datenrückgabe, Zugangssteuerung, Audit-Fähigkeit und Übergangswege real vorbereitet sind. DORA und die EBA-Leitlinien machen sichtbar, was viele IT-Organisationen längst praktisch spüren: Der Ausstieg ist der ehrlichste Test für Sourcing-Reife. Wer kritische Services auslagert, sollte deshalb nicht nur Kündigungsrechte prüfen, sondern konkrete Exit-Artefakte verlangen, Verantwortungen intern halten und Übergänge vorab üben. Sonst bleibt Wechselbarkeit ein beruhigender Satz im Vertrag – und kein belastbarer Betriebszustand.
