From Hyperscaler Dependency to DORA-Proven Sovereignty: How ayedo Migrated a Fintech Platform to Be Auditable

In recent years, many fintechs have rapidly grown on US hyperscalers. Managed Kubernetes, Managed Databases, Identity services, Monitoring – these accelerate product development significantly. Technically, this almost always works. Regulatively, it increasingly becomes a breaking point.

Since the implementation of DORA in January 2025, this breaking point is no longer hypothetical for many financial service providers and their critical IT service providers, but audit-relevant. Concentration risks, exit strategies, supply chain security, auditability: Those who cannot provide reliable answers here not only lose trust but also business foundations.

In this post, we demonstrate through an anonymized project how ayedo migrated a cloud-native fintech platform from deep hyperscaler integration to a sovereign, certified managed Kubernetes infrastructure – making DORA, NIS-2, and GDPR requirements not just “documented” but demonstrable in operation. The client remains anonymous. The approach is reproducible.

Initial Situation: Technically Stable – Regulatorily Unsustainable

The client develops a platform for automated receivables management, used by banks, insurance companies, and public credit institutions. Sensitive financial data is processed daily – in the context of millions of end customers. Thus, the platform is indirectly in the tension field of banking supervisory requirements: DORA, MaRisk, BAIT – and in the supply chain NIS-2.

The platform had been consistently built on the US hyperscaler over several years. The architectural principle was “Managed first”: Managed Kubernetes as runtime, along with Managed Database, Object Storage, Identity/Secrets, Logging, and Monitoring as proprietary services. From an engineering perspective, this is understandable: less operational effort, faster delivery, uniform platform.

The problem began where banks stop thinking in “engineering sense” and start thinking in “auditability”. The hyperscaler suddenly was not just a technical provider but a significant outsourcing risk. And this classification did not come from gut feeling but from revision and supervisory dynamics.

What DORA Triggers in Practice: Concentration Risk and Exit Time as Hard Metrics

DORA requires financial companies and their critical ICT third-party providers to demonstrate digital operational resilience. In practice, this means identifying, controlling, and testing risks – in a way that is auditable. This explicitly includes the concentration risk with cloud providers and the ability to switch providers.

This is where the client was vulnerable. Several bank customers indicated that the dependency on a single US hyperscaler is assessed as a concentration risk. Simultaneously, the exit capability was critical: The platform was so deeply integrated into proprietary services that a switch to an alternative provider was internally estimated at six to twelve months.

For DORA, this is not just “unfavorable” but a problem because exit strategies cannot consist of PowerPoint slides. Banks demand documented and realistically implementable exit plans – and some now define time horizons that are hardly achievable with classic hyperscaler architectures.

Additionally, there was the geopolitical and legal dimension: The US CLOUD Act is not new, but the perception in regulated environments has significantly intensified. For sensitive financial data and public institutions, “US corporate infrastructure” was increasingly no longer justifiable. Two public credit institutions questioned the collaboration; an association made sovereign European data retention a prerequisite.

The third problem was verifiability. Certificates and compliance reports from the hyperscaler help only up to a certain point. In audits, the central gap is almost always the same: “The infrastructure is certified” does not answer “How securely and controlled is your application operated on this infrastructure?” This is where auditor questions arise: Who had access when? How are secrets rotated? What vulnerabilities are in images? How do backup and restore work – concretely, tested, documented?

These questions were not fundamentally unanswerable – but the proofs were partly maintained manually and not linked to the real operational reality. And anything manual is vulnerable in audits.

The Turning Point: “Significant Outsourcing Risk” with a 12-Month Deadline

The specific trigger was the audit of a major bank customer, which formally classified the hyperscaler dependency as a significant outsourcing risk and set a twelve-month deadline for migration – to an infrastructure that enables DORA-compliant exit strategies and concentration risk management.

It was clear: It is not about “cloud optimization”. It is about a strategic re-platforming migration that establishes regulatory security – without stopping product development and without a months-long big bang.

At this point, ayedo joined the project.

ayedo’s Approach: Sovereign Platform, Open Building Blocks, Proofs as a Byproduct of Operations

In such migrations, the most common mistake is treating compliance as a documentation project. This leads to paper, but not to auditability. Our approach is fundamentally different: We build the operational model so that proofs automatically arise – from logs, policies, scans, backup protocols, and Git histories.

The second principle: Exit capability does not arise from “we could theoretically”, but from architecture without proprietary dependencies. This means: Open-source components, Kubernetes-native, standardized interfaces, identical processes in cloud and on-premises.

And the third principle: Certified infrastructure is necessary but not sufficient. It is the foundation. The compliance gap is only closed at the platform and application level: IAM, Secrets, Supply-Chain-Security, Observability, Backup/DR, Change-Management.

Infrastructure: Certified, European, Optional – Without Hyperscaler Fixation

The target platform was implemented on infrastructure in German data centers, with the option to choose between several certified providers – depending on customer requirements and audit context. The key was: Data remains in the EU. No US hyperscaler as a necessary part of the supply chain, no Cloud Act risk, no concentration risk with a single provider.

Additionally, an on-premises option was provided from the beginning. Not as a special solution, but as an equivalent operating mode: same platform, same manifests, same processes – just a different location. This was exactly what banks wanted, who demand “behind their own firewall”: Not a second codebase, not separate operations, but a consistent operational standard.

Tenant Isolation: Isolation That Can Be Audited

Bank customers expect not only tenant isolation but traceable tenant isolation. In Kubernetes, “namespace per customer” is quickly said – but it only becomes auditable when policies and controls are consistent.

We mapped tenants over dedicated namespaces, supplemented by Cilium Network Policies, strict RBAC rules, and Resource Quotas. The point is not that this is technically possible. The point is that it is versioned as a policy set and can be reproducibly proven in an audit: what communication is allowed, who can see what, how resources are limited, how lateral access is prevented.

Secrets: Vault Instead of Implicit Secrets – Rotation as Default, Audit as Output

A common auditor focus is secrets handling. In hyperscaler stacks, secrets often end up in proprietary managers, in CI/CD variables, or as a “temporary solution” in the code. This is a risk, especially in BAIT/DORA contexts.

We established HashiCorp Vault as the central secret management layer – including automatic rotation for database credentials, API keys, and certificates. This not only creates better security but also an audit trail: every access to secrets is logged. Secrets are thus no longer an implicit assumption but a controlled, traceable process.

Identities and Access: Authentik with MFA and Traceable Roles

In audits, it is not about whether a login is possible, but whether access controls are traceable. Who can deploy? Who can see logs? Who can administer in which environment? And how is MFA enforced?

We introduced Authentik as the central identity and access management, with SSO, MFA, and role-based accesses. Additionally, integration into the directory services of the bank customers was provided via OIDC and LDAP, so that customers do not have to operate their identity processes “outside” their governance. Thus, access is not only technically solved but also organizationally connectable.

Software Supply Chain: Harbor, CVE Gates, and SBOM as Regulatory Language

DORA and NIS-2 shift the focus strongly towards supply chain security. For platforms, this practically means: You have to be able to show which components you operate, which vulnerabilities are known, what measures you take – and that you do not deploy blindly.

We set up Harbor as a private container registry, including automated CVE scanning and SBOM generation. The key was the gatekeeping: Images with vulnerabilities above defined thresholds are not rolled out. This sounds like a security feature but is primarily a compliance mechanism: From a vague “we patch regularly” to a measurable process with policies and reports.

Observability and Audit Logging: Proofs Arise from Operations, Not from Excel

A core problem of the previous operations was the lack of seamless auditability. In the new platform, observability was therefore not thought of as “monitoring” but as a proof and control layer.

With VictoriaMetrics, VictoriaLogs, Grafana, and Tempo, a complete observability stack was implemented, capturing system events, logs, traces, and metrics centrally. Critical is the handling of audit logs: accesses, configuration changes, deployments, and security-relevant events are stored immutably and can be exported for auditors. Thus, the question “Who did what when?” is not answered by someone searching in tickets, but by presenting a reliable audit trail.

Backup and Disaster Recovery: PITR, Georedundant, Tested – with RTO/RPO as Metrics

In regulated environments, backups are not a technical question but a resilience question. It is not enough that backups run. You have to test and document restore capability. And you have to not only define RTO/RPO but also prove them.

We established daily backups of all databases and persistent volumes, supplemented by point-in-time recovery. Backups are stored georedundantly on separate storage, physically separated from the production systems. And crucially: weekly automated restore tests produce documented results. Thus, disaster recovery becomes a regularly verified capability instead of a “plan”.

Change Management: GitOps with ArgoCD as Audit Basis

Another core area of DORA is ICT change management. In many environments, this is the gap between “we deploy” and