• Contact us
  • Documentation
  • Login
Watch a demoFree trial
Blog
Blog
BlogProduktFallstudienNachrichtenInsights
Blog

DORA-Exit-Strategie für Finanzdienstleistungen: portable cloud-Architektur mit Upsun

MigrationcloudIaCKonfigurationGitCloud-Anwendungsplattform
24 März 2026
Teilen
Diese Seite wurde von unseren Experten auf Englisch verfasst und mithilfe einer KI übersetzt, um einen schnellen Zugriff zu ermöglichen! Die Originalversion findest du hier.

Diese Seite wurde von unseren Experten auf Englisch verfasst und mithilfe einer KI übersetzt, um einen schnellen Zugriff zu ermöglichen! Die Originalversion findest du hier.

Finanzinstitute müssen nachweisen, dass sie sicher in der Cloud arbeiten können, ohne von einem einzigen Technologieanbieter abhängig zu sein. Was passiert, wenn dein Cloud-Anbieter ausfällt oder du umziehen musst?

Früher war das eine theoretische Frage. Seit Januar 2025 ist es jedoch eine gesetzliche Anforderung. 

Der Digital Operational Resilience Act (DORA) der EU verlangt von Banken, Versicherungen und Wertpapierfirmen, dass sie nachweisen, dass sie Störungen der cloud-Plattformen, auf die sie angewiesen sind, standhalten können, einschließlich der Aufrechterhaltung einer dokumentierten, getesteten Ausstiegsstrategie für jeden Technologieanbieter.

Für viele Unternehmen offenbart dies eine harte Wahrheit: Die meisten modernen cloud-basierten Implementierungen sind eng an einen einzigen Anbieter gebunden. 

Wenn eine Aufsichtsbehörde fragt, wie du morgen von AWS wegkommen würdest, ist „das würden wir schon irgendwie hinbekommen“ keine akzeptable Antwort mehr.

Die Falle der Anbieterabhängigkeit

Die meisten cloud-basierten Architekturen sind nicht portabel. Sie basieren auf anbieterspezifischen Diensten: AWS-Lambda-Funktionen, Azure-nativen Datenbanken und GCP-spezifischen Netzwerkkonfigurationen, wodurch tiefe, unsichtbare Abhängigkeiten entstehen. Mit der Zeit häufen sich diese Abhängigkeiten an.

Der Wechsel von einem einzelnen cloud-basierten Anbieter bedeutet nicht nur, ein Hosting-Konto zu wechseln. Es bedeutet, deine Anwendung neu zu gestalten. 

Für eine regulierte Bank ist das riskant. Wenn eine Bank ihre Workloads nicht von einem Anbieter weg verlagern kann, kann sie keine Ausfallsicherheit gegenüber Ausfällen, regulatorischen Maßnahmen oder geopolitischen Störungen nachweisen.

Dies ist das Konzentrationsrisiko, für dessen Bewältigung DORA konzipiert wurde. 

Im November 2025 stuften die EU-Aufsichtsbehörden 19 IKT-Anbieter im Rahmen von DORA als kritisch ein, darunter AWS, Microsoft Azure und Google Cloud. Diese Anbieter unterliegen nun einer direkten Aufsicht auf EU-Ebene. 

Für Finanzunternehmen, die von ihnen abhängig sind, ist die Botschaft klar: Beweist, dass ihr nicht in der Falle sitzt.

Gemäß Artikel 28 der DORA müssen Finanzinstitute in der Lage sein, Verträge mit IKT-Anbietern zu kündigen, ohne dass es zu Dienstunterbrechungen kommt oder regulatorische Anforderungen verletzt werden. Das bedeutet, dass Institute:

  • Dokumentierte Ausstiegsstrategien vorhalten
  • Alternative Anbieter identifizieren und Übergangspläne entwickeln
  • Datenmigrations- und Übergangsprozesse planen
  • Ausstiegspläne regelmäßig testen und überprüfen

Warum Multi-Cloud allein keine DORA-Ausstiegsstrategie ist

Wenn Teams den Begriff „Ausstiegsstrategie“ hören, ist der erste Impuls oft, eine Multi-Cloud-Laufzeitumgebung einzuführen: Anwendungen gleichzeitig bei mehreren Anbietern ausführen.

In der Praxis ist dieser Ansatz teuer und komplex. 

Die Ausführung von Produktions-Workloads über mehrere clouds hinweg erfordert doppelte Infrastruktur, doppelte Überwachung und doppelte Betriebsteams. Schlimmer noch: Die Anwendung selbst ist möglicherweise weiterhin von anbieterspezifischen Diensten abhängig. Echte Portabilität bleibt unerreichbar.

Was Finanzinstitute wirklich brauchen, ist standardisierte Portabilität: ein Bereitstellungsmodell, bei dem Anwendungen bei einem anderen Infrastrukturanbieter neu erstellt werden können, ohne das gesamte System neu zu entwerfen.

Standardisierte Portabilität: der Upsun-Ansatz

Upsun geht dieses Problem anders an. 

Anstatt Anwendungen um einen bestimmten cloud-Anbieter herum zu entwickeln, standardisiert Upsun die Art und Weise, wie Anwendungen definiert und bereitgestellt werden. Die Grundlage dieses Ansatzes ist eine einzige Konfigurationsdatei: .upsun/config.yaml.

Diese Konfiguration definiert die gesamte Anwendungsumgebung:

  • Laufzeitversionen
  • Dienste (Datenbanken, Caches, Suchmaschinen)
  • Build- und Bereitstellungsprozesse
  • Routen und Netzwerk
  • Geplante Aufgaben

Deine Infrastrukturdefinition ist nicht in einer cloud-basierten Konsole oder einer proprietären Orchestrierungsschicht eingeschlossen. Sie ist versioniert, überprüfbar und portabel.

Da die Konfiguration anbieterunabhängig ist, kann die Anwendungsumgebung auf jeder unterstützten Infrastruktur – einschließlich AWS, Azure, Google Cloud, IBM und OVHCloud – neu erstellt werden, ohne das Bereitstellungsmodell neu zu entwerfen.

Sollte eine Aufsichtsbehörde einen Wechsel verlangen oder ein Anbieter einen längeren Ausfall haben, kann die Anwendung unter Verwendung derselben Upsun-Konfiguration und des Git-basierten Workflows wiederhergestellt oder zu einem anderen unterstützten Anbieter migriert werden.

Was das für die DORA-Konformität bedeutet

Artikel 28 der DORA verpflichtet Finanzunternehmen zur Aufrechterhaltung umsetzbarer Ausstiegsstrategien, während Artikel 30 spezifische Vertragsbestimmungen festlegt, die in Vereinbarungen mit IKT-Anbietern enthalten sein müssen und die Dienstkontinuität, Kündigungsrechte und Datenmigration abdecken. 

Upsun bietet bereits einen DORA-Vertragsnachtrag an, um Finanzdienstleistungskunden bei der Erfüllung dieser Anforderungen zu unterstützen.

Aber die technische Seite ist genauso wichtig wie die vertragliche. DORA erwartet umsetzbare Ausstiegspläne, keine theoretischen. 

Eine portable, versionskontrollierte Infrastrukturdefinition gibt Compliance-Teams etwas Konkretes an die Hand: Hier ist der Entwurf.

In Kombination mit den bestehenden Compliance-Zertifizierungen von Upsun – ISO 27001, SOC 2 Typ 2, PCI DSS Level 1, HIPAA und der Validierung für IBM Cloud for Financial Services – ist Upsun darauf ausgelegt, Teams zu unterstützen, die in regulierten Umgebungen arbeiten.

Portabilität ist nicht alles: Migration erfordert Planung

Eine ehrliche Ausstiegsstrategie erfordert mehr als eine portable Konfigurationsdatei. 

Der Wechsel einer Produktionsanwendung zwischen Cloud-Anbietern erfordert nach wie vor einen geplanten Migrationsprozess: Datenübertragung, erneute Integrationstests, DNS-Umstellung, performance-Validierung und Freigabe durch die Stakeholder. 

Keine Plattform macht diesen Aufwand komplett überflüssig.

Was Upsun überflüssig macht, ist die Neugestaltung der Infrastruktur. 

Dein Programm ändert sich nicht. Deine Build-Pipeline ändert sich nicht. Deine Service-Definitionen ändern sich nicht.

Der Migrationsaufwand konzentriert sich auf die operativen Schritte: Daten, Tests und Umstellung, nicht darauf, alles von Grund auf neu aufzubauen. Das ist eine grundlegend andere Ausgangsposition als die Umstellung von einer anbieterspezifischen Architektur.

Ein praktischer Ausgangspunkt

Wenn du ein Finanzinstitut bist, das sich auf die Anforderungen der DORA-Exit-Strategie vorbereitet, fang hier an:

  1. Überprüfe deine aktuellen Abhängigkeiten von Anbietern. Finde heraus, welche Dienste anbieterspezifisch und welche portierbar sind.
  2. Prüfe, wie deine Infrastruktur definiert ist. Ist sie im Programm festgeschrieben oder in einer Konsole gesperrt?
  3. Stell deinem Plattformanbieter eine direkte Frage: Wenn wir im nächsten Quartal auf eine andere cloud umsteigen müssten, was würde das konkret bedeuten?

Bei Upsun beginnt die Antwort mit einer Datei, die sich bereits in deinem Git-Repository befindet.

Erfahre mehr

Bleiben Sie auf dem Laufenden

Abonnieren Sie unseren monatlichen Newsletter.

Ihr größtes Werk
steht vor der Tür

Kostenloser Test