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

Teil 3 von 7 unserer DORA-Serie: Cloud-Abhängigkeit ist nicht allein eine Beschaffungsfrage. Sie bestimmt, ob eine Bank bei einer Störung, einem Vertragskonflikt oder einer aufsichtsrechtlichen Anordnung handlungsfähig bleibt. Der Exit-Plan nach DORA liefert dafür die Pflicht; dieser Beitrag übersetzt sie in eine realistische Architektur- und Betriebsfrage.

Autor: acceleraid Redaktion

DORA macht Konzentration sichtbar – sie löst sie nicht auf

Die europäischen Aufsichtsbehörden haben 19 kritische IKT-Drittdienstleister designiert. Auf der offiziellen Liste stehen unter anderem Amazon Web Services EMEA, Google Cloud EMEA und Microsoft Ireland Operations. Das ist kein Urteil über die Qualität einzelner Anbieter. Es macht jedoch sichtbar, dass ihre Dienste für Teile des Finanzsystems eine besondere Relevanz besitzen. Die Liste ist ein transparenter Ausgangspunkt für die eigene Konzentrationsanalyse. ESMA führt die vollständige CTPP-Liste.

DORA antwortet darauf mit Aufsicht über den kritischen Anbieter und mit Verantwortung bei der Bank. Der stärkste, aber nachgelagerte Hebel ist die Ultima Ratio: Zuständige Behörden können die Nutzung eines Dienstes aussetzen oder beenden lassen. Für Institute ist das keine bequeme externe Absicherung. Es ist das Szenario, für das sie eine technisch und organisatorisch belastbare Handlungsoption vorbereiten müssen. Der Exit ist damit nicht das Ende einer Lieferantenbeziehung, sondern ein Bestandteil der Resilienzplanung.

Die Marktdaten erklären, warum ein Exit anspruchsvoll ist

Die Konzentration beginnt weit vor dem einzelnen Bankvertrag. Im weltweiten Public-IaaS/PaaS-Markt entfielen im dritten Quartal 2025 auf AWS 29 %, Microsoft 20 % und Google 13 % – zusammen 63 %. Synergy Research dokumentiert diese Verteilung und den Zeitverlauf. Die Registeranalyse der EZB beschreibt die bankpraktische Seite. Fast alle Banken haben Cloud-Verträge für kritische Funktionen; die Ausgaben stiegen um 13,5 %. Zugleich entfällt die Hälfte des gesamten Auslagerungsbudgets auf nur 30 externe Anbieter. Verträge haben im Durchschnitt vier Subunternehmer, und 67 % werden an externe Dienstleister weitergegeben. Der EZB-Aufsichtsnewsletter fasst diese Befunde zusammen. Ein Exit muss daher nicht nur Daten und Anwendungen bewegen. Er muss auch Standorte, Identitäten, Schnittstellen, Betriebswissen und Lieferketten transparent machen.

Die richtige Frage: Welche Abhängigkeit soll beherrscht werden?

„Wir haben zwei Clouds“ ist noch keine Exit-Strategie. Entscheidend ist, welche Abhängigkeit konkret besteht und wie sie im Störfall aufgelöst wird. Vier Prüfpfade helfen bei der Einordnung:

Dieser Raster verhindert zwei typische Fehlannahmen. Erstens ist Redundanz nicht automatisch Portabilität: Eine replizierte Datenbank hilft wenig, wenn Identitätsmodell, Schlüsselverwaltung oder Observability nur in einem proprietären Dienst funktionieren. Zweitens ist eine Repatriierung nicht automatisch einfacher als ein Providerwechsel: Das interne Ziel braucht Kapazitäten, Kontrollen und Betriebsteams, bevor der Auslöser eintritt.

Die EZB nennt genau diese Risikofelder: Provider-Lock-in, weniger vorhersehbare Kosten, erschwerte Prüfungen, Konzentration bereitgestellter Funktionen und geringe Sichtbarkeit von Subdienstleistern. Sie empfiehlt ausdrücklich, die Abhängigkeit von einzelnen Anbietern regelmäßig zu überprüfen. Der EZB-Leitfaden zu Cloud-Outsourcing macht daraus keine Blaupause für eine bestimmte Zielarchitektur. Er verlangt vielmehr, dass die Bank die eigene technische Ersetzbarkeit nachvollziehbar bewertet.

Drei Exit-Optionen – und ihre Grenzen

Erstens: Anbieterwechsel. Diese Option ist plausibel, wenn die Anwendung mit portablen Laufzeitumgebungen, klaren Datenformaten und dokumentierten Schnittstellen betrieben wird. Sie setzt voraus, dass ein qualifizierter Zielanbieter vorab identifiziert wird. Der Nachweis ist nicht eine Folie mit Logos, sondern ein Plan für Datenübertragung, Sicherheitskontrollen, Tests und den Betrieb nach dem Wechsel.

Zweitens: Repatriierung. Ein Workload wird in das eigene Rechenzentrum oder eine kontrollierte Private-Cloud-Umgebung überführt. Das kann Souveränität und Steuerbarkeit erhöhen, verlagert aber Verantwortung für Kapazität, Patchen, Wiederherstellung und Fachkräfte zurück in die Bank. Repatriierung ist deshalb ein Designpfad, kein automatischer Risikoabbau.

Drittens: bewusste Diversifikation. Mehrere Ausführungsorte können das Risiko eines einzelnen Ausfalls begrenzen. Sie erhöhen allerdings Integrations- und Testaufwand. Diversifikation ist nur dann Resilienz, wenn die Umschaltung für die priorisierten Dienste, Daten und Berechtigungen tatsächlich geprobt werden kann. Wie ein solcher Nachweis aussehen soll, erläutert Teil 2 unserer Serie zum Testen von Exit-Plänen.

Der Data Act stärkt die Vertragsposition beim Switching: Er verpflichtet Anbieter, Wechselhindernisse abzubauen; für den Übergang gelten grundsätzlich höchstens 30 Kalendertage, für die Kündigungsfrist höchstens zwei Monate. Ausnahmen und Grenzen bleiben bestehen. Artikel 25 und 30 der Data-Act-Verordnung ersetzen daher weder eine Anwendungsmigration noch ein DORA-Exit-Runbook. Sie geben dem Runbook aber wichtige Anforderungen an Datenexport und Schnittstellen.

Souveränität heißt Wahlfähigkeit, nicht Herkunftslabel

Die Debatte über europäische Souveränität wird oft auf den Standort eines Rechenzentrums verkürzt. Standort ist relevant, reicht aber nicht. Der US CLOUD Act verpflichtet bestimmte US-Anbieter zur Aufbewahrung, Sicherung oder Offenlegung von Daten unabhängig davon, ob diese innerhalb oder außerhalb der USA liegen. Der Gesetzestext bei Congress.gov zeigt, weshalb Vertrags- und Rechtsraumfragen in die Risikobewertung gehören.

Gleichzeitig ist ein europäischer Anbieter nicht per se austauschbar und ein internationaler Anbieter nicht per se unbeherrschbar. Souveränität entsteht aus überprüfbarer Wahlfähigkeit: exportierbare Daten, dokumentierte Schnittstellen, nachvollziehbare Subunternehmerketten, Rechte auf Prüfung und ein getesteter Wechselpfad. Der Standort einer Cloud gehört in diese Bewertung, ist aber kein Ersatz für diese Nachweise.

Schweiz: Stressed Exit als Szenario

Für Schweizer Banken ist der Stressed Exit ausdrücklich Teil des Szenariotests: Die FINMA nennt unter anderem die Insolvenz eines wichtigen Dienstleisters oder ein längeres Verbot ausländischer Regierungen, nach dem Cloud-Anbieter schweizerische Firmen nicht mehr bedienen dürfen. Tests sind mindestens jährlich vorgesehen; Table-Top-Übungen sind zulässig. FINMA-RS 2023/1 rückt damit das belastbare Szenario in den Vordergrund. Die Lehre gilt auch über die Schweiz hinaus: Nicht die Anbieterliste schafft Resilienz, sondern die Fähigkeit des Instituts, einen Ausfall geordnet zu steuern.

Ein praktikabler Arbeitsauftrag für das nächste Quartal

Beginnen Sie nicht mit einer Cloud-Strategie-Präsentation. Beginnen Sie mit den wenigen Workloads, deren Ausfall Kundengeschäft, Kontrollfunktionen oder Meldepflichten spürbar trifft. Ordnen Sie diese im Informationsregister ein und prüfen Sie die Kriterien der kritischen oder wichtigen Funktion – insbesondere Datenbezug und Substituierbarkeit. Teil 7 wird diese Einstufungslogik für Core Banking, CRM, Data Lake und CDP vertiefen.

Für jeden priorisierten Workload sollten Architekturteam, Einkauf, Informationssicherheit und Fachbereich einen gemeinsamen Exit-Nachweis erzeugen: Zieloption, Datenexport, Abhängigkeiten, Zeit- und Ressourcenannahmen, Testschritte und Entscheidungstrigger. Daraus wird ein steuerbarer Backlog. Die Kernthese lautet: Wegkommen können ist kein Ereignis. Es ist eine laufend gepflegte Fähigkeit.

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

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

• 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.