The DORA Deadline: Why Hyperscaler Certificates Are No Longer Enough for Audits

In recent years, the strategy for many fintechs was clear: “Managed first.” Those looking to grow quickly used the ready-made building blocks of the major US hyperscalers—from Kubernetes to databases to identity management. Technically, this is brilliant as it massively accelerates product development. However, with the enforcement of DORA (Digital Operational Resilience Act) in January 2025, the regulatory landscape has fundamentally changed.

Many companies are lulled into a false sense of security because their cloud provider presents hundreds of certificates (ISO, SOC2, etc.). But for regulators, that’s only half the truth.

1. The Responsibility Gap

A common misconception is that a certified infrastructure provider automatically means a certified application. However, DORA focuses on the digital operational resilience of the financial institution itself.

Auditors today no longer just ask, “Is the data center secure?” but:

• “How do you ensure that you can be operational again within hours if the provider fails?” (Exit Strategy)
• “How do you prevent a technical error at the provider from crippling your entire business?” (Concentration Risk)
• “Can you provide seamless evidence of who made what changes to the production environment and when?” (Auditability)

Hyperscaler certificates confirm that the “hardware and data center” are in order. They say nothing about whether your specific setup is resilient or even migratable.

2. The Problem of “Proprietary Shackles”

Those who dive deep into the ecosystems of hyperscalers often use services that are unique to them. The result is a vendor lock-in, making a real exit strategy (as required by DORA) impossible. If switching to another provider would take twelve months, there is effectively no exit plan—and that is a significant audit risk.

To be DORA-compliant, the architecture must become “choice-free.” This means using open standards (Kubernetes, open source databases, vendor-neutral IAM) that work both in the cloud and on-premises.

3. Verifiability Instead of Documentation

Previously, it was often enough to describe compliance concepts in PDFs. However, DORA demands proof in operation.

• It’s not enough to say you do backups; you must demonstrate automated restore tests.
• It’s not enough to say you apply patches; you must prove an unbroken software supply chain (SBOM/CVE scans).

In an audit today, the central question is: “Show me the system log for that” instead of “Show me the concept for that.”

Conclusion: Sovereignty as a New Business Metric

For fintechs, sovereignty is no longer an ideological issue but a hard business foundation. Those who reduce their dependencies and automate their processes so that audit evidence is almost a byproduct of operations not only save time at the next review but also regain the trust of major banking partners.

In the next part, we’ll look at how an architecture must be designed to enable a real exit strategy without sacrificing the agility of the cloud.

FAQ

Does DORA only apply to banks? No. DORA applies to almost all financial companies in the EU as well as their critical ICT third-party providers. This means: If you supply software to banks or insurance companies, you are directly affected through the supply chain.

Do I have to leave the hyperscaler now? Not necessarily. But you need to change the way you use it. You must regain control over the platform layer (Kubernetes, database management, security) to be “movable” at any time.

What is the biggest risk in a DORA audit? Lack of traceability in changes (Change Management). Anyone who “quickly makes manual” adjustments in the cloud console has lost in the audit. GitOps is the technological answer here.

How does ayedo support DORA compliance? We build a sovereign infrastructure backbone for you based on open standards. We automate the audit trails (logging, secrets, deployments) so that you can export the required evidence at the push of a button instead of manually compiling it.