DORA-Cloud-Exit planen: Eine Sicherung ist noch kein Wechselplan

Für einen ausgelagerten ICT-Dienst, der eine kritische oder wichtige Funktion unterstützt, braucht ein belastbarer Cloud-Exit zwei Ebenen: eine übergreifende Strategie für Entscheidungen und Risikotoleranz sowie einen ausführbaren Plan für den einzelnen Dienst. Eine Sicherung belegt noch keinen möglichen Anbieterwechsel, denn Artikel 28 Absatz 8 DORA verlangt auch alternative Lösungen und Übergangspläne, mit denen ICT-Dienste und relevante Daten sicher und vollständig zu einem anderen Anbieter oder zurück in die eigenen Systeme gelangen.

Das Arbeitsdokument muss deshalb festlegen, wann der Exit ausgelöst wird, wer entscheidet, welche Abhängigkeiten zu übertragen sind, welcher Zielbetrieb bereitsteht und woran der erfolgreiche Übergang gemessen wird. Erst dokumentierte Rollen, realistische Zeit- und Kostenannahmen sowie erprobte technische Schritte machen aus einer Datensicherung einen Wechselplan.

1. Strategie und dienstspezifischen Plan trennen

Die Strategie setzt den verbindlichen Rahmen: Geltungsbereich, Entscheidungsbefugnisse, akzeptierte Ausstiegswege, Risikotoleranz, Finanzierung und Testgrundsätze. Der dienstspezifische Plan übersetzt ihn in technische und betriebliche Arbeitspakete für eine konkrete Cloud-Auslagerung.

Diese Trennung entspricht auch dem Aufsichtskontext für direkt von der EZB beaufsichtigte Banken. Nach der Erläuterung der EZB zur finalen Leitlinie schafft das Dokument keine neuen verbindlichen Regeln, sondern verdeutlicht Erwartungen zur Umsetzung bestehender DORA-Anforderungen und beschreibt bewährte Verfahren für das Cloud-Auslagerungsrisiko.

Die Strategie beantwortet somit, welche Exit-Optionen das Unternehmen grundsätzlich akzeptiert. Der Einzelplan zeigt dagegen, wie ein bestimmter Dienst tatsächlich übertragen, zurückgeführt oder geordnet stillgelegt werden kann.

2. Eine editierbare Gliederung anlegen

Für jeden dienstspezifischen Plan eignet sich das folgende Mindestgerüst. Zu jedem Punkt gehören ein verantwortlicher Rollenname, eine Vertretung, der Freigabestatus und das Datum der letzten internen Prüfung:

1. Gegenstand und Abhängigkeiten: betroffene Geschäftsfunktion, Cloud-Dienst, Regionen, Unterauftragnehmer, Datenbestände, Identitätsdienste, Schlüsselverwaltung, Netzwerkverbindungen, Schnittstellen sowie vor- und nachgelagerte Systeme.
2. Auslöser: Vertragsende, anhaltende Leistungsverschlechterung, Kontrollverlust, nicht beherrschbares Sicherheitsrisiko, relevante Anbieter- oder Standortänderung und plötzlicher Dienstausfall. Für jeden Auslöser werden Schwellenwert, Beobachter und Eskalationsweg festgelegt.
3. Entscheidung und Rollen: entscheidungsbefugtes Gremium, Exit-Leitung sowie Verantwortliche für Fachbetrieb, Architektur, Daten, Informationssicherheit, Datenschutz, Recht, Einkauf, Kommunikation und unabhängige Prüfung.
4. Zieloptionen: qualifizierter Alternativanbieter, Rückführung ins eigene Unternehmen oder geordnete Stilllegung. Jede Option erhält Voraussetzungen, Ausschlussgründe und einen Zielverantwortlichen.
5. Durchführung: Export, Integritätsprüfung, Transformation, Import, technische Abnahme, fachliche Abstimmung, Umschaltung, gegebenenfalls Parallelbetrieb, Rückfallpunkt und nachweisbare Löschung beim bisherigen Anbieter.
6. Vertrag und Budget: Mitwirkung des Anbieters, Datenformate, Exportzugang, Übergangszeit, Kostenpositionen, Ressourcenreservierung und Vorgehen für einen Exit ohne reguläre Unterstützung des bisherigen Anbieters.

Ein Name in einer RACI-Tabelle genügt nicht. Für jede kritische Aufgabe müssen auch Vertretung, Entscheidungsbefugnis sowie der Zugang zu Werkzeugen, Schlüsseln und aktuellen Betriebsinformationen geklärt sein.

3. Annahmen in Migrationsmesswerte verwandeln

Ein Zeitplan wird erst belastbar, wenn seine Eingangsgrößen messbar sind. Erfassen Sie je Datenbestand das produktive Volumen, die tägliche Änderungsmenge, das Exportformat, die bei einem Test erreichte Nettoübertragungsrate, die Dauer der Integritätskontrolle und den Speicherbedarf am Ziel. Für Anwendungen gehören Schnittstellen, nicht portable Plattformdienste, notwendige Konfigurationsänderungen und Testaufwand in dieselbe Kalkulation.

Die finale EZB-Leitlinie zum Cloud-Outsourcing nennt für granulare Exit-Pläne kritische Meilensteine, Aufgaben, benötigte Fähigkeiten sowie grobe Zeit- und Kostenschätzungen. Sie empfiehlt zudem, Datenvolumen, Anwendungskomplexität, Übertragungsmethode, Personalbedarf und qualifizierte Alternativanbieter zu berücksichtigen.

Eine nutzbare Messwerttabelle enthält deshalb je Arbeitspaket Soll-Dauer, spätesten Start, Personalstunden nach Rolle, externe Unterstützung, Einmalkosten, Kosten des Parallelbetriebs und Abnahmekriterium. Rechnen Sie mit Ergebnissen eines Exporttests statt mit der nominellen Bandbreite. Wo Messungen noch fehlen, werden Bandbreite, Annahme und verantwortliche Stelle dokumentiert, nicht eine scheinpräzise Endfrist.

4. Den plötzlichen Provider-Ausfall separat planen

Ein ungeplanter Exit ist nicht lediglich eine beschleunigte ordentliche Migration. Bei einem abrupten Ausfall können auch Verwaltungsportal, Exportfunktionen oder Unterstützungspersonal des bisherigen Anbieters fehlen. Der Plan sollte daher einen Ablauf enthalten, der mit den zuvor gesicherten Daten, Zugängen und technischen Informationen ohne reguläre Mitwirkung des Providers beginnen kann.

Ein geeignetes Übungsszenario lautet: Der produktive Dienst und die Administrationsschnittstelle sind nicht erreichbar; der letzte verifizierte Export liegt in einer getrennten Umgebung vor. Das Krisengremium priorisiert die betroffenen Geschäftsprozesse, aktiviert den vorbereiteten Zielbetrieb, stellt Schlüssel und Identitäten bereit, spielt Daten ein, verbindet die wesentlichen Schnittstellen und nimmt die definierte Mindestfunktion fachlich ab.

Dazu gehören sichtbare Rückfallpunkte: Bis wann kann die Aktivierung abgebrochen werden, welcher Datenstand gilt dann und wer genehmigt den Abbruch? Ein klar benanntes Mindestbetriebsniveau trennt die kurzfristige Wiederherstellung von der längerfristigen Ablösung des Providers. Die Sicherung beantwortet dabei nur, welcher Datenstand verfügbar ist; der Exit-Plan regelt, wie daraus wieder ein verantworteter Dienst entsteht.

5. Trockenübungen als Nachweis gestalten

Die Testtiefe sollte sich nach Kritikalität, technischer Komplexität und Änderungsumfang richten. Ein Dokumentenreview prüft Aktualität und Widerspruchsfreiheit, ein Walkthrough lässt die benannten Rollen ihre Schritte und Zugänge nachvollziehen, und technische Teilübungen erproben besonders kritische Exporte, Wiederherstellungen, Transformationen oder Umschaltungen. Eine Ende-zu-Ende-Probe kann zusätzlich den Zielbetrieb und die fachliche Abnahme einschließen, sofern Aufwand und Risiko dies rechtfertigen.

Das Testprotokoll hält Szenario, Umfang, Teilnehmer, Datenstand, Start- und Endzeiten, erreichte Messwerte, Abweichungen und offene Maßnahmen fest. Die Durchführbarkeit sollte außerdem eine fachkundige Person prüfen, die den Plan nicht selbst erstellt hat. Für jeden Befund werden Verantwortliche und Frist vergeben.

Nach einer Übung sind nicht nur Formulierungen zu korrigieren. Aktualisiert werden auch Zeit- und Kostenannahmen, Personalbedarf, Alternativanbieter, Vertragslücken und Rückfallpunkte. Einsatzfähig ist der Plan, wenn ein qualifiziertes Ersatzteam anhand der Unterlagen den nächsten Schritt bestimmen, die nötigen Zugänge finden und das Ergebnis gegen vorab definierte Kriterien prüfen kann.

Lesen Sie auch:

• 22 Millionen KI-Prompts am Arbeitstag – die Stromzahl ist nur eine Schätzung
• Lupin Dental erhält 15 Millionen Euro – doch die EU-Zulassung steht noch aus
• Microsoft und HUMAIN schicken Ingenieure zum Kunden – das Modell ist der Engpass