Von Hyperscaler-Abhängigkeit zu DORA-nachweisbarer Souveränität: Wie ayedo eine Fintech-Plattform auditierbar migriert hat

In den letzten Jahren sind viele Fintechs auf US-Hyperscalern schnell groß geworden. Managed Kubernetes, Managed Databases, Identity-Dienste, Monitoring – das beschleunigt Produktentwicklung enorm. Technisch funktioniert das fast immer. Regulatorisch wird es zunehmend zur Sollbruchstelle.

Seit dem Inkrafttreten von DORA im Januar 2025 ist genau diese Sollbruchstelle für viele Finanzdienstleister und deren kritische IT-Dienstleister nicht mehr hypothetisch, sondern prüfungsrelevant. Konzentrationsrisiken, Exit-Strategien, Lieferkettensicherheit, Auditierbarkeit: Wer hier keine belastbaren Antworten liefert, verliert nicht nur Vertrauen, sondern Geschäftsgrundlagen.

In diesem Beitrag zeigen wir anhand eines anonymisierten Projekts, wie ayedo eine cloud-native Fintech-Plattform von einer tiefen Hyperscaler-Integration auf eine souveräne, zertifizierte Managed-Kubernetes-Infrastruktur migriert hat – so, dass DORA-, NIS-2- und DSGVO-Anforderungen nicht „dokumentiert", sondern im Betrieb nachweisbar werden. Der Kunde bleibt anonym. Der Ansatz ist reproduzierbar.

Ausgangslage: Technisch stabil – regulatorisch unhaltbar

Der Kunde entwickelt eine Plattform für automatisiertes Forderungsmanagement, genutzt von Banken, Versicherungen und öffentlichen Kreditinstituten. Täglich werden sensible Finanzdaten verarbeitet – im Kontext von Millionen Endkunden. Damit ist die Plattform indirekt im Spannungsfeld der bankaufsichtlichen Anforderungen: DORA, MaRisk, BAIT – und in der Lieferkette NIS-2.

Die Plattform war über mehrere Jahre konsequent beim US-Hyperscaler aufgebaut worden. Das Architekturprinzip war „Managed first": Managed Kubernetes als Laufzeit, dazu Managed Database, Object Storage, Identity/Secrets, Logging und Monitoring als proprietäre Dienste. Aus Engineering-Sicht ist das nachvollziehbar: weniger Betriebsaufwand, schnelleres Delivery, einheitliche Plattform.

Das Problem begann dort, wo Banken aufhören, in „Engineering-Sinn" zu denken, und anfangen, in „Prüfungsfähigkeit" zu denken. Der Hyperscaler war plötzlich nicht mehr nur ein technischer Provider, sondern ein wesentliches Auslagerungsrisiko. Und diese Einstufung kam nicht aus Bauchgefühl, sondern aus Revision und Aufsichtsdynamik.

Was DORA in der Praxis auslöst: Konzentrationsrisiko und Exit-Zeit als harte Kenngrößen

DORA verlangt von Finanzunternehmen und ihren kritischen IKT-Drittdienstleistern, dass sie digitale operationale Resilienz nachweisen können. In der Praxis heißt das: Man muss Risiken identifizieren, kontrollieren, testen – und zwar so, dass es auditierbar ist. Dazu gehört explizit das Konzentrationsrisiko bei Cloud-Anbietern und die Fähigkeit, den Provider zu wechseln.

Genau hier war der Kunde verwundbar. Mehrere Bankkunden signalisierten, dass die Abhängigkeit von einem einzelnen US-Hyperscaler als Konzentrationsrisiko bewertet wird. Parallel wurde die Exit-Fähigkeit kritisch: Die Plattform war so tief in proprietäre Dienste integriert, dass ein Wechsel auf einen alternativen Anbieter intern auf sechs bis zwölf Monate geschätzt wurde.

Für DORA ist das nicht nur „ungünstig", sondern ein Problem, weil Exit-Strategien nicht aus PowerPoint bestehen dürfen. Banken fordern dokumentierte und realistisch umsetzbare Exit-Pläne – und einige definieren inzwischen Zeithorizonte, die mit klassischen Hyperscaler-Architekturen kaum erreichbar sind.

Hinzu kam die geopolitische und juristische Dimension: Der US CLOUD Act ist nicht neu, aber die Wahrnehmung in regulierten Umfeldern hat sich deutlich verschärft. Für sensible Finanzdaten und öffentliche Institute wurde „US-Konzern-Infrastruktur" zunehmend nicht mehr vermittelbar. Zwei öffentliche Kreditinstitute stellten die Zusammenarbeit in Frage; ein Verband machte souveräne europäische Datenhaltung zur Voraussetzung.

Das dritte Problem war Nachweisbarkeit. Zertifikate und Compliance-Reports des Hyperscalers helfen nur bis zu einem gewissen Punkt. In Prüfungen ist die zentrale Lücke fast immer dieselbe: „Die Infrastruktur ist zertifiziert" beantwortet nicht „Wie sicher und kontrolliert ist eure Anwendung auf dieser Infrastruktur betrieben?". Genau dort entstehen Auditorenfragen: Wer hatte wann Zugriff? Wie werden Secrets rotiert? Welche Schwachstellen stecken in Images? Wie funktionieren Backup und Restore – konkret, getestet, dokumentiert?

Diese Fragen waren nicht grundsätzlich unbeantwortbar – aber die Nachweise waren teilweise manuell gepflegt und nicht an die echte Betriebsrealität gekoppelt. Und alles, was manuell ist, ist in Prüfungen angreifbar.

Der Wendepunkt: „Wesentliches Auslagerungsrisiko" mit 12-Monats-Frist

Der konkrete Auslöser war die Revision eines großen Bankkunden, die die Hyperscaler-Abhängigkeit formal als wesentliches Auslagerungsrisiko einstufte und eine Frist von zwölf Monaten für eine Migration setzte – auf eine Infrastruktur, die DORA-konform Exit-Strategien und Konzentrationsrisikomanagement ermöglicht.

Damit war klar: Es geht nicht um „Cloud-Optimierung". Es geht um eine strategische Re-Platforming-Migration, die regulatorische Sicherheit herstellt – ohne die Produktentwicklung zu stoppen und ohne einen monatelangen Big-Bang.

An diesem Punkt kam ayedo ins Projekt.

ayedos Ansatz: Souveräne Plattform, offene Bausteine, Nachweise als Nebenprodukt des Betriebs

In solchen Migrationen ist der häufigste Fehler, Compliance als Dokumentationsprojekt zu behandeln. Das führt zu Papier, aber nicht zu Audit-Fähigkeit. Unser Ansatz ist grundsätzlich anders: Wir bauen das Betriebsmodell so, dass Nachweise automatisch entstehen – aus Logs, Policies, Scans, Backup-Protokollen und Git-Historien.

Der zweite Grundsatz: Exit-Fähigkeit entsteht nicht durch „wir könnten theoretisch", sondern durch Architektur ohne proprietäre Abhängigkeiten. Das bedeutet: Open-Source-Komponenten, Kubernetes-nativ, standardisierte Schnittstellen, identische Prozesse in Cloud und On-Premises.

Und der dritte Grundsatz: Zertifizierte Infrastruktur ist notwendig, aber nicht ausreichend. Sie ist das Fundament. Die Compliance-Lücke schließt man erst auf Plattform- und Anwendungsebene: IAM, Secrets, Supply-Chain-Security, Observability, Backup/DR, Change-Management.

Infrastruktur: Zertifiziert, europäisch, wahlfrei – ohne Hyperscaler-Fixierung

Die Zielplattform wurde auf Infrastruktur in deutschen Rechenzentren umgesetzt, mit der Möglichkeit, zwischen mehreren zertifizierten Anbietern zu wählen – je nach Kundenanforderung und Prüfkontext. Entscheidend war: Daten verbleiben in der EU. Kein US-Hyperscaler als notwendiger Bestandteil der Lieferkette, kein Cloud-Act-Risiko, kein Konzentrationsrisiko bei einem einzigen Anbieter.

Zusätzlich wurde von Beginn an eine On-Premises-Option vorgesehen. Nicht als Sonderlösung, sondern als gleichwertiger Betriebsmodus: gleiche Plattform, gleiche Manifeste, gleiche Prozesse – nur ein anderer Standort. Genau das war für Banken wichtig, die „hinter der eigenen Firewall" fordern: Nicht eine zweite Codebasis, nicht ein separater Betrieb, sondern ein konsistenter Betriebsstandard.

Mandantentrennung: Isolation, die sich prüfen lässt

Bankkunden erwarten nicht nur Mandantentrennung, sondern nachvollziehbare Mandantentrennung. In Kubernetes ist „Namespace pro Kunde" schnell gesagt – aber prüfbar wird es erst, wenn Policies und Kontrollen konsequent sind.

Wir haben Mandanten über dedizierte Namespaces abgebildet, ergänzt um Cilium Network Policies, strikte RBAC-Regeln und Resource Quotas. Der Punkt ist nicht, dass das technisch möglich ist. Der Punkt ist, dass es als Policy-Set versioniert ist und im Audit reproduzierbar nachgewiesen werden kann: welche Kommunikation ist erlaubt, wer darf was sehen, wie werden Ressourcen begrenzt, wie wird seitlicher Zugriff verhindert.

Secrets: Vault statt impliziter Geheimnisse – Rotation als Default, Audit als Output

Ein häufiger Auditoren-Fokus ist Secrets-Handling. In Hyperscaler-Stacks landen Secrets gerne in proprietären Managers, in CI/CD-Variablen oder als „temporäre Lösung" im Code. Das ist spätestens in BAIT-/DORA-Kontexten ein Risiko.

Wir haben HashiCorp Vault als zentrale Secret-Management-Schicht etabliert – inklusive automatischer Rotation für Datenbank-Credentials, API-Keys und Zertifikate. Dadurch entsteht nicht nur bessere Sicherheit, sondern auch ein Audit-Trail: jeder Zugriff auf Secrets wird protokolliert. Secrets sind damit keine implizite Annahme mehr, sondern ein kontrollierter, nachvollziehbarer Prozess.

Identitäten und Zugriffe: Authentik mit MFA und nachvollziehbaren Rollen

In Prüfungen zählt nicht, dass ein Login möglich ist, sondern dass Zugriffskontrollen nachvollziehbar sind. Wer darf deployen? Wer darf Logs sehen? Wer darf in welcher Umgebung administrieren? Und wie wird MFA durchgesetzt?

Wir haben Authentik als zentrales Identity- und Access-Management eingeführt, mit SSO, MFA und rollenbasierten Zugriffen. Zusätzlich wurde die Integration in Verzeichnisdienste der Bankkunden über OIDC und LDAP vorgesehen, damit Kunden ihre Identity-Prozesse nicht „außerhalb" ihrer Governance betreiben müssen. Damit wird Zugriff nicht nur technisch gelöst, sondern organisatorisch anschlussfähig.

Software Supply Chain: Harbor, CVE-Gates und SBOM als regulatorische Sprache

DORA und NIS-2 verschieben den Fokus stark in Richtung Lieferkettensicherheit. Für Plattformen heißt das praktisch: Man muss zeigen können, welche Komponenten man betreibt, welche Schwachstellen bekannt sind, welche Maßnahmen man ergreift – und dass man nicht blind deployt.

Wir haben Harbor als private Container-Registry aufgebaut, inklusive automatisiertem CVE-Scanning und SBOM-Generierung. Entscheidend war das Gatekeeping: Images mit Schwachstellen oberhalb definierter Schwellenwerte werden nicht ausgerollt. Das klingt wie ein Security-Feature, ist aber vor allem ein Compliance-Mechanismus: Aus einem diffusen „wir patchen regelmäßig" wird ein messbarer Prozess mit Policies und Reports.

Observability und Audit-Logging: Nachweise entstehen aus dem Betrieb, nicht aus Excel

Ein Kernproblem des bisherigen Betriebs war die fehlende lückenlose Audit-Fähigkeit. In der neuen Plattform wurde Observability deshalb nicht als „Monitoring" gedacht, sondern als Nachweis- und Steuerungsebene.

Mit VictoriaMetrics, VictoriaLogs, Grafana und Tempo wurde ein vollständiger Observability-Stack implementiert, der Systemereignisse, Logs, Traces und Metriken zentral erfasst. Kritisch ist dabei die Behandlung von Audit-Logs: Zugriffe, Konfigurationsänderungen, Deployments und sicherheitsrelevante Events werden unveränderlich gespeichert und sind für Prüfer exportierbar. Damit wird die Frage „Wer hat wann was getan?" nicht beantwortet, indem jemand in Tickets sucht, sondern indem man einen belastbaren Audit-Trail vorlegt.

Backup und Disaster Recovery: PITR, georedundant, getestet – mit RTO/RPO als Kennzahlen

In regulierten Umfeldern sind Backups keine Technikfrage, sondern eine Resilienzfrage. Es reicht nicht, dass Backups laufen. Man muss Restore-Fähigkeit testen und dokumentieren. Und man muss RTO/RPO nicht nur definieren, sondern belegen.

Wir haben tägliche Backups aller Datenbanken und persistenten Volumes etabliert, ergänzt um Point-in-Time Recovery. Backups werden georedundant auf separatem Storage gespeichert, physisch getrennt von den Produktionssystemen. Und entscheidend: wöchentliche automatisierte Restore-Tests erzeugen dokumentierte Ergebnisse. Damit wird Disaster Recovery von einem „Plan" zu einer regelmäßig verifizierten Fähigkeit.

Change Management: GitOps mit ArgoCD als Audit-Grundlage

Ein weiterer DORA-Kernbereich ist IKT-Change-Management. In vielen Umgebungen ist genau das die Lücke zwischen „wir deployen" und „wir können erklären, was passiert ist". Je mehr Automatisierung, desto wichtiger wird Nachvollziehbarkeit.

Mit ArgoCD wurde GitOps als Standard eingeführt. Jede Änderung an Infrastruktur und Anwendung wird als Git-Commit erfasst, reviewed und nachvollziehbar ausgerollt. Health Checks und automatische Rollbacks reduzieren zusätzlich das Risiko, dass Änderungen unkontrolliert Schaden anrichten. Für Audits ist GitOps eine starke Antwort, weil es Change-Historien nicht „rekonstruiert", sondern sie systemisch erzeugt.

Ergänzend wurde das Entwicklungs- und Pipeline-Setup so gestaltet, dass Branch Protection, Merge-Request-Approvals und Security-Scans fester Bestandteil des Delivery-Prozesses sind. Das Ziel war nicht „mehr Tools", sondern ein durchgängiger, prüfbarer Prozess von Code bis Betrieb.

On-Premises als gleichwertige Option: Gleiche Plattform, gleicher Prozess, anderer Ort

Der vielleicht strategisch wichtigste Teil war die Fähigkeit, das gleiche Betriebsmodell auch On-Premises zu liefern. Einige Großbanken wollten die Plattform im eigenen Rechenzentrum – aus Gründen, die nicht verhandelbar sind: interne Policies, Datenklassifikation, Souveränität.

Statt ein separates On-Prem-Produkt zu bauen, wurde das Betriebsmodell so standardisiert, dass es in beiden Welten identisch funktioniert. Damit kann der Anbieter Cloud- und On-Prem-Kunden bedienen, ohne doppelte Engineering-Aufwände zu erzeugen. Und für DORA ist das ein zentraler Exit-Baustein: Wer eine Plattform On-Prem betreiben kann, hat die Abhängigkeit von einem einzelnen Provider strukturell reduziert.

Ergebnis: Regulatorische Risiken eliminiert – und neue Märkte erschlossen

Nach der Migration konnte der Kunde gegenüber Bankkunden und Prüfern nachvollziehbar darlegen, wo Daten liegen, wie Zugriffe kontrolliert werden, wie Secrets gehandhabt werden, wie Schwachstellenmanagement erfolgt und wie Backup/Restore funktioniert – nicht als „Konzept", sondern als Export aus laufenden Systemen.

Das Konzentrationsrisiko wurde durch Anbieterwahl in zertifizierten europäischen Rechenzentren und die Entkopplung von proprietären Hyperscaler-Diensten reduziert. Eine Exit-Strategie wurde nicht nur beschrieben, sondern praktisch realisierbar gemacht – mit einem Migrationsfenster, das deutlich unter den zuvor geschätzten sechs bis zwölf Monaten liegt.

NIS-2-Anforderungen in der Lieferkette wurden durch messbares Schwachstellenmanagement (CVE/SBOM), strukturiertes Incident-Management und lückenloses Logging adressiert. Öffentliche Kundenanforderungen im Kontext von DSGVO und BSI-konformer Betriebsumgebung wurden erfüllbar, weil die Plattform auf zertifizierter Infrastruktur läuft und die Anwendungsebene auditierbar gestaltet ist.

Und das vielleicht Wichtigste aus Geschäftssicht: Die Migration war nicht nur Risikoreduktion. Sie wurde zum Enablement für neue Kunden. Zwei Großbanken gingen On-Premises live, ein Rahmenvertrag im öffentlichen Umfeld wurde möglich, weil Souveränität nicht mehr Behauptung, sondern Architektur war.

Der Audit-Aufwand sank deutlich, weil Nachweise nicht mehr manuell zusammengesucht werden mussten. Compliance wurde vom Projekt zur Eigenschaft.

Warum dieser Ansatz funktioniert: DORA verlangt keine Cloud-Abkehr – sondern Exit-Fähigkeit und Nachweisbarkeit

DORA zwingt niemanden, Cloud zu verlassen. DORA zwingt Organisationen, Risiken in der Cloud beherrschbar zu machen. Dazu gehören Exit-Fähigkeit, Konzentrationsrisiko-Management und operational resiliente Prozesse.

Das erreicht man nicht, indem man Zertifikate sammelt. Man erreicht es, indem man Plattformen so baut, dass sie:

auf offenen Bausteinen basieren, in mehreren Betriebsmodellen funktionieren, und ihre Nachweise automatisch erzeugen.

Genau das ist der Kern souveräner Plattformen: weniger Abhängigkeit, mehr Kontrolle, mehr Beweisbarkeit.

Call to Action

Wenn ihr als Fintech oder als kritischer IT-Dienstleister merkt, dass eure Hyperscaler-Architektur technisch stark, aber regulatorisch angreifbar ist, dann braucht ihr keine kosmetischen Anpassungen. Ihr braucht ein Betriebsmodell, das DORA, NIS-2 und bankaufsichtliche Anforderungen nicht „erklärt", sondern belegt.

ayedo unterstützt bei genau diesen Transformationen: Migration auf souveräne, zertifizierte Managed-Kubernetes-Infrastrukturen, Aufbau auditierbarer Plattformbausteine und – wo erforderlich – Betrieb derselben Plattform On-Premises hinter der Kunden-Firewall.

Wenn ihr eure Exit-Strategie realistisch machen und Audit-Aufwände drastisch senken wollt, sprechen wir gern über eure Ausgangslage.