Der Exit-Plan nach DORA: Was er enthalten muss und warum er getestet werden muss

Teil 2 von 7 unserer DORA-Serie für Banken. Nachdem Teil 1 die Grundlogik von DORA eingeordnet hat, geht es hier um die konkrete Gegenprobe für jede Auslagerung: Kann die Bank einen Dienstleister tatsächlich verlassen, ohne eine kritische oder wichtige Funktion unkontrolliert zu gefährden?

Autor: acceleraid Redaktion

Ein Exit-Plan ist keine Kündigungsvorlage

Ein Exit-Plan wird oft mit einer Vertragsklausel oder einer Migrationsliste verwechselt. Nach DORA ist er beides nicht. Für IKT-Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen verlangt Artikel 28 Absatz 8 Ausstiegsstrategien. Der Wortlaut ist eindeutig: „Ausstiegspläne müssen umfassend, dokumentiert und im Einklang mit den in Artikel 4 Absatz 2 aufgeführten Kriterien ausreichend getestet sein sowie regelmäßig überprüft werden.“ Die Pflicht umfasst alternative Lösungen und Übergangspläne, mit denen Dienste und zugehörige Daten sicher und vollständig zu einem anderen Anbieter übertragen oder wieder intern übernommen werden können. (EUR-Lex, Artikel 28 DORA)

Die richtige Managementfrage lautet deshalb nicht: „Haben wir einen Exit?“ Sondern: „Können die benannten Personen unter realistischen Bedingungen die Funktion, die Daten und die Kontrollnachweise in einem vertretbaren Übergangszeitraum bewegen?“ Erst diese Frage trennt einen nachweisbaren Plan von einem Dokument im Vertragsarchiv.

Welche Services in diesen Pflichtenkern fallen, entscheidet nicht der Produktname. Entscheidend ist, ob die Auslagerung eine kritische oder wichtige Funktion unterstützt. Die dafür nötige Bewertungslogik wird in Teil 7 der Serie zu kritischen und wichtigen Bankfunktionen vertieft. Für jeden so eingestuften Service sollte der Exit-Plan schon vor dem Go-live als Teil der Betriebsfreigabe vorliegen. (EZB, Cloud-Outsourcing-Leitfaden)

Der Vertrag ist die technische Voraussetzung des Exits

Ein Exit kann nur funktionieren, wenn der Vertrag die nötigen Rechte und Informationen sichert. Artikel 30 Absatz 2 verlangt unter anderem Angaben zu Orten der Leistungserbringung und Datenverarbeitung, die Rückgabe von Daten in einem leicht zugänglichen Format und Kündigungsrechte. Für kritische oder wichtige Funktionen kommen in Absatz 3 Leistungsziele im SLA, Notfallpläne, laufende Überwachung sowie Ausstiegsstrategien mit einem verbindlichen angemessenen Übergangszeitraum hinzu.

Das ergibt einen belastbaren Mindestinhalt. Ein Plan sollte die unterstützte Funktion und ihre Abhängigkeiten benennen, Datenklassen und Exportformate beschreiben, Rollen und notwendige Fachkenntnisse zuordnen sowie Meilensteine, Kostenannahmen und Erfolgskriterien enthalten. Außerdem braucht er vorab definierte Auslöser: etwa gravierende Vertragsverletzungen, festgestellte Schwächen im IKT-Risikomanagement oder die Behinderung aufsichtlicher Kontrolle. Für solche Umstände nennt DORA Kündigungspflichten.

Die technische Lieferkette darf nicht hinter dem Hauptvertrag verschwinden. Die Delegierte Verordnung (EU) 2025/532 verlangt vor Vertragsschluss eine Bewertung von Art der Dienste, Standorten, Länge und Komplexität der Subunternehmerkette, Datenarten, Drittlandbezug, Konzentration und möglicher Beeinträchtigung der Übertragbarkeit. Zugangs- und Prüfrechte müssen bis auf Subunternehmerebene reichen; wesentliche Änderungen brauchen wirksame Zustimmungs-, Widerspruchs- oder Beendigungsrechte. (EUR-Lex, Delegierte Verordnung (EU) 2025/532)

Testpflicht: Was Aufsicht als belastbar ansieht

DORA fordert ausreichende Tests; sie schreibt kein starres jährliches Intervall vor. Der EZB-Leitfaden für Cloud-Auslagerungen konkretisiert jedoch die aufsichtliche Erwartung: Exit-Pläne sollen regelmäßig überprüft und getestet werden, unter Beachtung des Proportionalitätsprinzips. Das ist der Maßstab, an dem ein Institut die praktische Durchführbarkeit nachweisen sollte.

Als Mindestniveau nennt die EZB einen eingehenden Desktop-Review durch Mitarbeitende mit ausreichender Cloud-Expertise. Dabei sind Datenvolumen, Anwendungskomplexität und Methode der Datenübertragung zu prüfen, damit Zeitschätzungen belastbar werden. Das ist keine reine Dokumentenlektüre: Es ist eine strukturierte Plausibilisierung, ob die Angaben zum Exit technisch und organisatorisch zusammenpassen.

Darauf sollte ein Walkthrough folgen. Die beteiligten Personen gehen Aufgaben, Abhängigkeiten, Freigaben und Kommunikationswege durch und zeigen damit, dass der Plan nicht an einzelnen Experten hängt. Für die kritischsten Migrationsschritte hält die EZB periodische Tests für gute Praxis; die Durchführbarkeit jedes Plans sollte unabhängig von Personen verifiziert werden, die ihn erstellt haben. (EZB, Cloud-Outsourcing-Leitfaden: Tests von Exit-Plänen)

Die EBF-Testtypologie hilft, diesen Aufwand angemessen zu staffeln. Sie unterscheidet Table-top-Test, Walkthrough, Desktop Exercise und Simulation; eine Simulation kann Datenextraktion, -transformation und -import einschließen. Das Papier fordert keine reale Migration für jeden SaaS-Fall und bewertet reale Datenoperationen dort als unverhältnismäßig. Gerade deshalb sollte ein Testdesign präzise begründen, was getestet wird, was simuliert wird und welche offene Unsicherheit verbleibt. (EBF, Cloud exit strategy — testing of exit plans)

Datenportabilität setzt einen Takt, ersetzt aber keinen Test

Der Data Act liefert für bestimmte Cloud-Switching-Szenarien wichtige Zeitplanken. Der maximale Übergangszeitraum beträgt 30 Kalendertage, die maximale Kündigungsfrist zwei Monate. Bei technischer Unmöglichkeit ist dies innerhalb von 14 Arbeitstagen mitzuteilen; ein alternativer Übergangszeitraum darf höchstens sieben Monate betragen. Ab 12. Januar 2027 dürfen keine Wechselentgelte mehr erhoben werden. (EUR-Lex, Verordnung (EU) 2023/2854, Artikel 25 und 29)

Diese Fristen machen Portabilität nicht automatisch einfach. Artikel 30 des Data Act verlangt offene Schnittstellen ohne Entgelt sowie den Export in einem strukturierten, gängigen und maschinenlesbaren Format, begrenzt dies aber ausdrücklich durch den Schutz von geistigem Eigentum und Geschäftsgeheimnissen. Zudem sind maßgeschneiderte Dienste und Nicht-Produktionsversionen vom Anwendungsbereich ausgenommen, und bei paralleler Nutzung können Daten-Egress-Kosten weitergegeben werden. (EUR-Lex, Data Act Artikel 30, 31 und 34)

Für personenbezogene Daten ergänzt Artikel 20 DSGVO den Anspruch auf ein strukturiertes, gängiges und maschinenlesbares Format sowie auf Direktübermittlung, soweit dies technisch machbar ist. Für den DORA-Exit ist das nützlich, aber nicht ausreichend: Er muss auch Integrationen, Berechtigungen, Betriebswissen, Nachweise und den kontrollierten Cutover abdecken. (EUR-Lex, DSGVO Artikel 20)

Ein Playbook für einen testbaren Exit

Ein praxistaugliches Playbook verbindet Recht, Architektur und Betrieb in sechs Schritten. Erstens: Funktion und Abhängigkeiten eindeutig abgrenzen. Zweitens: die Vertrags- und Subunternehmerkette gegen Datenflüsse, Standorte und Prüfungsrechte abgleichen. Drittens: einen konkreten Zielzustand wählen — alternativer Provider oder Eigenbetrieb — und dessen Eignung prüfen. Viertens: die Migrationsschritte mit Verantwortlichen, Datenvolumen, Sicherheitskontrollen, Zeit- und Kostenannahmen planen. Fünftens: Desktop-Review, Walkthrough und risikogerechte Simulation durchführen. Sechstens: Ergebnisse unabhängig bewerten, Lücken schließen und den Plan aktualisieren.

Die Priorisierung sollte risikobasiert sein, nicht kalendergetrieben. Aufsichtsdaten zeigen, wie anspruchsvoll das Thema ist: Der Anteil ausgelagerter kritischer Funktionen, die schwer oder unmöglich substituierbar sind, stieg von 80 auf 82 Prozent; 95 Prozent davon gelten als schwer oder unmöglich reintegrierbar. (EZB, Cloud outsourcing and concentration risk)

Teil 3 untersucht die daraus entstehende Cloud-Abhängigkeit europäischer Banken. Teil 5 zeigt, warum ein vollständiges Informationsregister die Voraussetzung ist, um Verträge und Lieferketten überhaupt testbar zu machen. Der Kern bleibt: Ein Exit-Plan ist erst dann glaubwürdig, wenn Verantwortliche, Daten, Verträge und Übergangsschritte in einer Übung zusammenkommen.

Die DORA-Serie im Überblick

• Teil 1: DORA für Banken: Was die EU-Verordnung regelt und wie sie funktioniert

• Teil 2: Der Exit-Plan nach DORA: Was er enthalten muss und warum er getestet werden muss (dieser Beitrag)

• Teil 3: Cloud-Abhängigkeit europäischer Banken: Wie man von AWS, Microsoft und Google notfalls loskommt

• Teil 4: Exit-Option für Customer-Engagement-Workloads: CDP, Personalisierung und Kampagnen DORA-konform absichern

• Teil 5: Das DORA-Informationsregister: Warum es in Wahrheit ein Datenqualitätsproblem ist

• Teil 6: KI-Anbieter als neues Konzentrationsrisiko: Was DORA für Modell-Abhängigkeiten bedeutet

• Teil 7: Kritisch oder wichtig? Risiko-Level von Core Banking bis CRM, Data Lake und CDP

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.