Der DORA-Stichtag am 17. Januar 2025 ist vorbei. Trotzdem gelten viele Cloud- und Kubernetes-Plattformen in deutschen Finanzinstituten intern noch nicht als vollständig auditfest. 2026 wird deshalb zum Prüfjahr: BaFin-Audits, DORA-Nachweise und Exit-Strategien treffen auf eine IT-Landschaft, die in den vergangenen Jahren oft schneller migriert als dokumentiert wurde.

Vor fünf Jahren war die Botschaft eindeutig: Public Cloud ist die Zukunft, wer nicht mitzieht, verliert. Deutsche Banken, Versicherer und Finanzdienstleister haben darauf reagiert und große Teile ihrer Entwicklungs-, Daten- und Plattformarchitekturen in Richtung Azure, AWS oder Google Cloud verschoben. Der Nutzen bleibt unbestritten: schnellere Entwicklungszyklen, moderne Datenplattformen, elastische Infrastruktur und bessere Voraussetzungen für Künstliche Intelligenz.

Doch die nächste Phase sieht anders aus. Es geht nicht mehr um „Cloud first“, sondern um „Cloud kontrolliert“. Kritische Workloads müssen so betrieben werden, dass Datenhaltung, Auslagerungssteuerung, Exit-Fähigkeit und Auditierbarkeit nicht erst im Nachgang dokumentiert werden. Genau hier entsteht der neue Markt für Cloud-Souveränität im Banking.

Was DORA technisch von Banken verlangt

DORA, der Digital Operational Resilience Act der EU, ist kein reines Compliance-Papier. Für IT-Organisationen in Banken bedeutet DORA vor allem: technische Resilienz muss nachweisbar sein.

Besonders relevant sind vier Anforderungsfelder. Erstens müssen Institute ihre ICT-Risiken aktiv steuern und dokumentieren. Zweitens müssen kritische Systeme so gebaut sein, dass Störungen, Sicherheitsvorfälle und Wiederanläufe nachvollziehbar beherrscht werden. Drittens braucht es belastbare Incident-Prozesse mit klaren Meldewegen. Viertens müssen Drittanbieter, darunter Cloud-Provider und Plattformdienstleister, so gesteuert werden, dass die Bank jederzeit auskunfts- und handlungsfähig bleibt.

Für Cloud-Architekturen ist das ein Paradigmenwechsel. Eine Bank kann nicht einfach einen Kubernetes-Cluster in Azure aufsetzen, Workloads migrieren und die regulatorische Dokumentation später ergänzen. DORA, MaRisk AT 9, BAIT, die EBA-Leitlinien zu Auslagerungen, NIS2 sowie ISO 27001 und der BSI-C5-Kriterienkatalog greifen ineinander. Cloud-Auslagerung wird damit nicht nur zur technischen, sondern zur aufsichtsrelevanten Architekturentscheidung.

Besonders wichtig ist dabei § 25b KWG. Er regelt Auslagerungen bei Instituten und ist für Cloud- und Plattformbetrieb wesentlich relevanter als allgemeine Verweise auf das Bankgeheimnis. Das Bankgeheimnis selbst ergibt sich vor allem aus zivilrechtlichen Nebenpflichten, den AGB der Banken und datenschutzrechtlichen Anforderungen. In der Praxis heißt das: Kundendaten, Protokolldaten und operative Bankprozesse dürfen nicht unkontrolliert in Drittland- oder Hyperscaler-Abhängigkeiten geraten.

Warum Cloud Repatriation im Banking kein Rückschritt ist

Diesen Trend bezeichnen Analysten und Plattformteams zunehmend als Cloud Repatriation: bestimmte Workloads werden aus der Public Cloud zurück in eigene, private oder stärker kontrollierte Infrastrukturen verlagert. In Deutschland ist diese Entwicklung besonders im Banking sichtbar, weil regulatorische Anforderungen, Datenkritikalität und Kostenkontrolle gleichzeitig wirken.

Wichtig ist: Repatriation bedeutet nicht, dass Banken die Public Cloud verlassen. Das wäre wirtschaftlich und technisch kaum sinnvoll. Entwicklungsumgebungen, Analytics, KI-Experimente und skalierende Plattformdienste bleiben häufig in der Cloud. Aber Workloads mit hoher Datenkritikalität, starken Auslagerungsanforderungen oder begrenztem Cloud-Mehrwert werden neu bewertet.

Die eigentliche Zielarchitektur ist hybrid. Sie verbindet Public-Cloud-Fähigkeiten mit kontrollierter Datenhaltung, portablen Anwendungen und auditierbarer Infrastruktur. Genau an dieser Stelle wird Kubernetes für Banken strategisch relevant.

Warum Kubernetes zur Exit-Strategie wird

Kubernetes ist im Banking nicht nur ein Container-Werkzeug. Richtig aufgebaut, wird es zur technischen Grundlage für DORA-konforme Exit-Fähigkeit.

Eine Anwendung, die sauber containerisiert ist, über standardisierte Images ausgeliefert wird und ihre Infrastruktur über Infrastructure-as-Code erhält, kann deutlich leichter zwischen Azure Kubernetes Service, einer Private Cloud oder einem eigenen Rechenzentrum verschoben werden. Das bedeutet nicht, dass ein Plattformwechsel trivial ist. Aber er wird technisch möglich, planbar und dokumentierbar.

Damit wird aus einer regulatorischen Pflicht eine echte Option. DORA verlangt, dass kritische Drittanbieter-Abhängigkeiten beherrscht und Exit-Szenarien belastbar geplant werden. Kubernetes liefert dafür die technische Abstraktion: Container-Portabilität, standardisierte Deployments, GitOps-Prozesse, Policy-as-Code und reproduzierbare Plattformkonfigurationen.

Genau deshalb investieren viele Banken nicht mehr nur in Cloud-Migration, sondern in Plattform-Engineering. Der Unterschied ist entscheidend. Cloud-Migration verschiebt Workloads. Plattform-Engineering schafft ein Betriebsmodell, das Compliance, Security und Delivery dauerhaft verbindet.

Wie eine BaFin-konforme AKS-Plattform technisch aussehen kann

Eine souveräne Banking-Cloud entsteht nicht dadurch, dass ein Cluster in einer europäischen Region betrieben wird. Entscheidend ist die Architektur darunter.

Ein belastbares AKS-Setup für regulierte Banken beginnt typischerweise mit privaten Clustern, klar segmentierten Netzwerken und kontrolliertem Egress. AKS Private Clusters mit Azure CNI Cilium schaffen die Grundlage, um Netzwerkpfade granular zu steuern. Eine Default-Deny-Policy und dokumentierte Egress-Allowlists sind dabei kein Nice-to-have, sondern Mindeststandard für auditfähige Plattformen.

Security muss ebenfalls in die Plattform eingebaut werden. Defender for Containers, Azure Policy, OPA Gatekeeper und zentralisierte Audit-Logs helfen, Abweichungen früh zu erkennen und regulatorisch nachvollziehbar zu machen. Entscheidend ist, dass jede Konfiguration einem Kontrollziel zugeordnet wird: DORA Artikel 9 für ICT-Risikomanagement, Artikel 11 für Wiederherstellung, Artikel 12 für Backup und Wiederanlauf sowie Artikel 28 für Drittparteienrisiken.

Für Auditoren zählt am Ende nicht, ob ein Cluster modern wirkt. Sie müssen nachvollziehen können, warum eine Konfiguration gesetzt wurde, welches Risiko sie reduziert und wie die Bank im Störfall handlungsfähig bleibt. AKS Long-Term Support kann zusätzlich helfen, Plattformversionen stabiler zu halten und Update-Zyklen besser mit Prüf- und Freigabeprozessen zu verbinden.

Pexon Consulting begleitet Banken und regulierte Unternehmen bei solchen Azure- und Kubernetes-Architekturen mit einem Ansatz, der Compliance nicht als nachträgliche Checkliste behandelt, sondern als Architekturprinzip. Genau daraus entsteht der Unterschied zwischen einem technisch funktionierenden Cluster und einer Plattform, die auch im BaFin-Kontext bestehen kann.

Was Banken bei KI-Daten zusätzlich beachten müssen

Die Diskussion um Cloud-Souveränität wird durch Künstliche Intelligenz verschärft. Banken wollen KI produktiv nutzen: in der Dokumentenprüfung, im Risikomanagement, in der Kundenkommunikation, im internen Wissensmanagement oder bei regulatorischen Prüfprozessen. Gleichzeitig sind viele KI-Modelle, APIs und Plattformdienste eng mit US-Hyperscalern verbunden.

Das ist nicht automatisch verboten. Aber es erzeugt Prüfpflichten. Kundendaten, Transaktionsdaten, Geldwäscheinformationen und interne Bankdokumente dürfen nicht ohne belastbare Rechtsgrundlage, technische Kontrolle und klare Datenverarbeitungsgrenzen an externe Modellanbieter fließen. Besonders kritisch wird es, wenn Modell-Telemetrie, Prompt-Inhalte oder Trainingsdaten nicht vollständig kontrollierbar sind.

Deshalb wächst das Interesse an Private AI. Gemeint ist ein KI-Stack, bei dem Modelle, Gateways und Datenflüsse so betrieben werden, dass sensible Informationen unter Kontrolle des Instituts bleiben. Das kann On-Premise, in einer Private Cloud oder in klar abgegrenzten europäischen Cloud-Strukturen geschehen. Konstrukte wie die Microsoft EU Data Boundary können dabei ein Baustein sein, ersetzen aber keine eigene Architekturentscheidung.

Für Banken ist die Grundfrage einfach: Welche KI-Workloads dürfen skalieren, ohne dass Datenhoheit, Bankgeheimnis, DSGVO oder Auslagerungssteuerung geschwächt werden? Die Antwort liegt selten in einem einzelnen Tool. Sie liegt in einer Plattformarchitektur, die Datenklassifizierung, Modellzugriff, Logging, Identity und Betrieb gemeinsam denkt.

Praxisbeispiel: Acht Wochen bis zur produktiven Banking-Plattform

Ein Beispiel aus einem anonymisierten Projekt zeigt, wie konkret diese Anforderungen werden. Pexon Consulting hat eine deutsche Genossenschaftsbank mit 51,8 Milliarden Euro Bilanzsumme bei der Umsetzung einer BaFin-konformen AKS-Plattform begleitet. Die Plattform war nach acht Wochen produktiv, inklusive dokumentiertem Mapping zentraler DORA-Anforderungen auf konkrete Plattformkonfigurationen.

Der entscheidende Punkt war kein einzelnes Tool. Der Hebel lag in einem geprüften Architektur-Blueprint: Netzwerk, Identity, Logging, Policy, Deployment-Prozesse und Betriebsdokumentation wurden nicht getrennt entwickelt, sondern als zusammenhängendes Kontrollsystem aufgebaut.

In einem weiteren Projekt bei einem deutschen Versicherer aus den Top 10 führte die Migration eines monolithischen Systems auf AKS zu deutlich geringeren Infrastruktur- und Betriebskosten. Solche Effekte entstehen allerdings nicht durch „Lift and Shift“. Sie entstehen, wenn Anwendungen modernisiert, Plattformen standardisiert und Compliance-Anforderungen von Beginn an mitentwickelt werden.

Was Pexon anders macht

Viele Cloud-Projekte in regulierten Branchen scheitern nicht an fehlender Strategie. Sie scheitern an der Lücke zwischen Strategie und umsetzbarer Architektur.

Pexon Consulting positioniert sich deshalb als deutscher Implementierungspartner für DORA- und BaFin-konforme Azure- und Kubernetes-Plattformen. Das Team verbindet Cloud-Engineering, Plattformbetrieb und regulatorisches Mapping. Der Anspruch ist nicht, ein weiteres Strategiepapier zu liefern, sondern eine Plattform zu bauen, die produktiv, auditierbar und weiterentwickelbar ist.

Was Pexon bewusst nicht macht: reine PowerPoint-Strategie ohne technische Umsetzung, Offshore-Delivery für BaFin-kritische Workloads ohne deutsche Projektverantwortung oder Plattformen, bei denen Compliance erst nach dem Go-live ergänzt wird. Für Banken ist genau diese Haltung relevant. Denn eine Cloud-Plattform, die regulatorisch nachgerüstet werden muss, wird am Ende fast immer teurer als eine, die von Anfang an korrekt gebaut wurde.

Für Institute, die ihre Azure- und Kubernetes-Landschaft überprüfen wollen, hat sich eine spezialisierte Azure-Beratung für regulierte Branchen als eigener Projektansatz etabliert: zuerst Gap-Analyse gegen DORA, BAIT und MaRisk, danach priorisierte Architekturmaßnahmen, dann produktionsfähiger Blueprint.

Die wirtschaftliche Rechnung

Souveräne Cloud-Architekturen wirken auf den ersten Blick teurer als generische Cloud-Setups. Private Cluster, Security Policies, Audit-Logging, Dokumentation, Betriebsmodelle und Exit-Fähigkeit kosten Zeit. Doch die relevante Rechnung beginnt nicht beim Setup, sondern beim gesamten Lebenszyklus.

Banken, die Compliance nachträglich ergänzen, zahlen meist doppelt: erst für die schnelle Migration, später für Sicherheitsnachrüstung, Audit-Dokumentation, Prozesskorrekturen und ungeplante Plattformumbauten. Hinzu kommen Verzögerungen, weil produktive Workloads nicht freigegeben werden oder regulatorische Fragen ungeklärt bleiben.

Wer dagegen mit einer Compliance-by-Design-Architektur startet, investiert früher, reduziert aber spätere Reibung. Audits laufen strukturierter, Plattformteams arbeiten mit klareren Leitplanken und Fachbereiche erhalten schneller eine Umgebung, in der kritische Anwendungen tatsächlich produktiv gehen dürfen.

Für viele Institute ist deshalb ein kleines Assessment der bessere Startpunkt als ein großer Migrationsplan. Ein AKS Security Assessment kann in wenigen Tagen zeigen, wo die größten Lücken gegen DORA, BAIT und MaRisk liegen. Eine DORA-ready AKS-Plattform lässt sich danach in einem klar begrenzten Zeitraum aufbauen, statt über Monate in Workshops zu verharren.

Mini-FAQ: Cloud-Souveränität im Banking

Was bedeutet Cloud-Souveränität für Banken?

Cloud-Souveränität bedeutet, dass eine Bank Kontrolle über Datenhaltung, Anbieterabhängigkeiten, Exit-Fähigkeit, Sicherheitskonfigurationen und regulatorische Nachweise behält. Es geht nicht darum, Public Cloud zu vermeiden, sondern kritische Workloads so zu betreiben, dass DORA, MaRisk, BAIT, DSGVO und interne Risikosteuerung erfüllt werden.

Ist Cloud Repatriation im Banking ein Rückzug aus der Public Cloud?

Nein. Cloud Repatriation bedeutet meist eine selektive Rückverlagerung einzelner Workloads. Banken behalten Public-Cloud-Dienste dort, wo Skalierung, Entwicklungsgeschwindigkeit oder Analytics klare Vorteile bringen. Kritische Daten- und Kernprozesse werden jedoch häufiger auf private, hybride oder stärker kontrollierte Plattformen verschoben.

Warum ist Kubernetes für DORA relevant?

Kubernetes kann Anwendungen portabler machen und damit technische Exit-Strategien unterstützen. Wenn Container-Images, Infrastructure-as-Code, GitOps und Policies sauber umgesetzt sind, lassen sich Workloads besser zwischen Cloud, Private Cloud und Rechenzentrum verschieben. Das hilft Banken, Drittanbieterabhängigkeiten nicht nur vertraglich, sondern technisch zu beherrschen.

Warum reicht ein normaler AKS-Cluster für Banken nicht aus?

Ein Standard-AKS-Cluster erfüllt nicht automatisch Banking-Anforderungen. Regulierte Institute brauchen private Netzwerke, kontrollierten Egress, Policy-as-Code, Audit-Logging, Identity-Governance, Backup- und Wiederanlaufkonzepte sowie ein dokumentiertes Mapping auf DORA, BAIT und MaRisk. Erst diese Kombination macht eine Plattform auditfähig.

Fazit: 2026 ist das Jahr der Architekturentscheidung

Deutsche Banken werden ihre Cloud-Landschaft 2026 und 2027 neu sortieren. Nicht, weil die Public Cloud gescheitert wäre. Sondern weil die Anforderungen an Resilienz, Datenhoheit, Auslagerungssteuerung und Exit-Fähigkeit deutlich konkreter geworden sind.

Die Institute, die jetzt hybride Plattformen mit Kubernetes, Compliance-by-Design und klarer Datenklassifizierung aufbauen, gewinnen Handlungsspielraum. Sie können Public Cloud dort nutzen, wo sie Wert schafft, und kritische Workloads dort betreiben, wo Kontrolle wichtiger ist als maximale Elastizität.

Die Entscheidung ist deshalb keine rein technische. Sie ist strategisch. Aber sie wird am Ende an der Architektur entschieden.

---

Bild: Gemini

Artikel per E-Mail verschicken