Best Cloud Platforms for DORA Compliance: How EU Fintech Teams Should Actually Choose

Key Points:

• No cloud provider can make you DORA compliant. DORA is Regulation (EU) 2022/2554, in force since 16 January 2023 and applicable since 17 January 2025. It puts the obligation on the financial entity. A provider only hands you contractual clauses, audit rights, subcontracting transparency and technical controls that you then have to turn into evidence.
• AWS, Google Cloud, Microsoft Azure and Scaleway are all workable DORA choices. Each publishes DORA-oriented contractual terms or EU-region controls and self-serve audit artefacts. Choose on EU data residency, exit feasibility and where your team already has operational depth, not on a badge.
• GRC platforms own the paperwork, not the enforcement. LogicGate, Resolver, SureCloud, Vendorica and Legiscope run your register of information, policy mapping, vendor assessments and incident workflows. None of them change how a deploy is approved, how fast you restore, or whether your exit plan actually works. They are complements, not competitors.
• Four DORA requirements land on engineers: traceable change management, tested backup and restore with dated RTO/RPO evidence, resilience and scenario testing (plus threat-led penetration testing for entities in scope), and an exit strategy someone has actually executed.
• Qovery is DORA compliant and runs inside your own cloud. It deploys into your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so the contract, data residency, cloud bill and exit path stay in your name. Every deployment is audit-logged, access is scoped per environment, and environments are reproducible enough to make an exit test real instead of theoretical.

I have interviewed more than 200 CTOs and heads of platform over the past few years, and DORA keeps surfacing the same way in those conversations. The compliance team buys a tool, signs some addenda, and declares victory. Then an auditor asks for a deployment approval log, a dated restore test, and proof that the exit plan has been run once. Every one of those artefacts is produced by engineering, not by the register of information. DORA reads like a legal document, but most of it lands on the people who ship code.

So here is the honest answer to "which cloud is best for DORA," up front: no cloud is DORA compliant on your behalf. Pick the cloud on data residency and the skills you already have, pick a GRC platform for the register and reporting, and pick a delivery layer that produces audit evidence automatically. Then spend 90 days proving three things auditors always ask for: a complete change trail, a dated restore test, and an exit you have actually executed. The rest of this piece is how to make those three choices without getting sold a badge.

One quick disambiguation, because fintech teams googling this hit both: DORA the EU regulation (Digital Operational Resilience Act) is not the same as DORA the DevOps metrics (DevOps Research and Assessment, the Google Cloud research programme behind deployment frequency and lead time). Same acronym, unrelated. This article is about the regulation, though the delivery discipline the DevOps programme measures is exactly what the regulation ends up demanding.

What does DORA actually require from a cloud platform?

DORA certifies no cloud and no vendor. Regulation (EU) 2022/2554 puts every obligation on the financial entity, then extends contractual and oversight requirements to its ICT third-party providers. The only useful question is whether a given cloud gives you the contractual clauses, audit rights and machine-readable evidence you need to prove your own compliance.

The regulation organises into five areas: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information-sharing arrangements. It was published in the Official Journal on 27 December 2022, entered into force twenty days later on 16 January 2023, and has applied since 17 January 2025. Its scope in Article 2 covers around 20 categories of financial entity (credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, insurers and more) plus the ICT third-party providers that serve them.

What a provider owes you contractually is concrete: a DORA addendum, a full description of services and processing locations, subcontracting transparency, audit and access rights, incident notification, and termination plus exit assistance. What no provider can hand you is your own resilience testing, your own change control, your own restore proof, and a documented exit plan someone has run.

There is a structural reason not to lean on a single hyperscaler. DORA created an oversight framework for Critical ICT Third-Party Providers (CTPPs), and in November 2025 the European Supervisory Authorities designated the first 19 critical providers, a list that includes AWS, Microsoft and Google. Concentration risk is a named supervisory concern: the ESRB has long flagged shared third-party providers as systemically important nodes in the financial system. The practical takeaway is that portability and a tested exit plan matter more than which logo you sign.

Which cloud provider is best for a fintech that needs DORA compliance?

For most EU fintechs, AWS, Google Cloud, Microsoft Azure and Scaleway can all support DORA compliance, because each publishes DORA-oriented contractual terms or EU-region controls and self-serve audit artefacts. What actually decides it is EU data residency and sovereignty options, how much evidence you can pull without a support ticket, and how realistically you could leave inside your stated exit window.

• AWS publishes a dedicated DORA page with a Financial Services Addendum, serves audit reports through AWS Artifact, offers AWS Backup and AWS Resilience Hub for restore and resilience evidence, and has launched the AWS European Sovereign Cloud in Brandenburg, Germany as its sovereignty option.
• Google Cloud publishes an EU DORA compliance page, offers Assured Workloads for EU data-boundary and sovereign controls, and gives you Cloud Audit Logs as the evidence trail, where Admin Activity logs are retained 400 days by default and Data Access logs 30 days.
• Microsoft Azure publishes DORA guidance in its Trust Center, completed its EU Data Boundary (the final professional-services-data phase closed in February 2025), and serves audit reports through the Service Trust Portal.
• Scaleway is an EU-headquartered provider with three EU-only regions (Paris, Amsterdam, Warsaw), ISO 27001 and HDS certification, and no US CLOUD Act exposure. It has no dedicated DORA page, but it is a strong sovereignty play or the second provider that lowers concentration risk.
• Bring-your-own-Kubernetes (an existing self-managed, hybrid or on-prem cluster) is a legitimate fifth path when data location or exit obligations are tight and you want the contract entirely in your name.

The selection rule I give every team: pick on residency, team depth and exit feasibility, then keep the delivery layer identical across providers so the choice stays reversible. A second region or a second provider should be a configuration change, not a rewrite.

Are GRC tools like LogicGate, Resolver, SureCloud or Vendorica enough for DORA?

No. GRC platforms cover the documentation half of DORA very well and the operational half not at all. They record that you have change control; they cannot enforce it, and auditors ask for the enforcement evidence, not the policy PDF.

Each earns its place. LogicGate and Resolver run ICT risk workflows and third-party registers. SureCloud handles assessments and reporting. Vendorica and Legiscope map regulatory obligations and vendor documentation. These are the system of record for your register of information, and they are genuinely good at it. I want to be clear that they are complementary to a cloud and to a delivery platform, not competitors to either.

The gap shows up the moment an auditor moves past policy. They ask for deployment and approval logs, IAM and RBAC state per environment, restore test results with timestamps, and evidence of an executed exit or portability test. A GRC tool can hold those artefacts once they exist, but it does not generate them. The clean division of labour: GRC is the system of record, your delivery platform is the system of enforcement, the cloud is the system of location. Wire the three together so evidence flows into the register continuously, instead of being reconstructed the week before an audit.

Which DORA requirements actually land on the engineering team?

Four DORA requirements convert straight into engineering work: traceable change management, tested backup and restore, resilience and scenario testing, and an exit strategy someone can execute on demand. Everything else is paperwork that engineering has to feed with real, dated artefacts.

Change control and traceability come first. You need to answer who deployed what, when, approved by whom, into which environment, with logs retained long enough to reconstruct an incident timeline. That last point is not academic: the ESAs' incident reporting rules require an initial notification within hours of classifying a major incident, an intermediate report within 72 hours, and a final report within a month. You cannot hit those clocks if "what changed and when" takes a day to assemble.

Access control and separation of duties come next: per-environment RBAC, production isolated from everything else, no shared admin credentials. Then backups and restore drills, where the requirement is proving RTO and RPO with dated test results rather than asserting them in a policy. For financial services this is not a paperwork exercise, given that one in five significant outages now costs more than $1 million according to the Uptime Institute.

Resilience testing applies to everyone in scope through scenario-based tests, plus threat-led penetration testing (TLPT) for the subset of larger entities designated for it, which the regulation requires at least every three years. And the exit strategy: Article 28 requires exit plans for ICT services supporting critical or important functions to be documented and sufficiently tested. Can you redeploy the stack into another provider's account or your own cluster inside a defined window, and has anyone ever actually tried?

Where teams quietly fail is not the intent but the scatter. The evidence exists, but it lives across CI logs, Terraform state, Slack threads and three cloud consoles, and the CI logs rotate in 30 days.

How does an internal developer platform help with DORA compliance?

An internal developer platform sits between your cloud account and your developers, which is exactly where most DORA engineering evidence is produced. Every deployment is logged and approved, every environment has scoped access, and every environment is reproducible, which is the property that turns an exit plan from a document into a test you can pass.

Concretely, the value maps one-to-one onto the four engineering requirements:

• Audit-logged git-push deployments plus an approval flow give you change-management evidence without anyone writing it up by hand.
• Per-environment RBAC and separation of duties come built in, so you are not hand-rolling IAM policies per team.
• Reproducible environments let you redeploy the same definition into another account, region or cluster, which is the core of a credible exit and portability test.
• Preview and ephemeral environments plus auto-stop make restore and scenario drills cheap enough that teams actually run them.
• Managed cluster upgrades keep you off unsupported Kubernetes versions. Each Kubernetes minor release is supported for roughly 14 months, and running past that window is an easy audit finding.
• Databases backed by managed cloud services keep backup and retention settings where the provider's own evidence already lives.

This is not free, and the trade-offs are real. Building it in-house with Backstage plus Terraform gives you maximum control and demands the most headcount, which is why only 28% of organisations report a dedicated platform engineering team in the CNCF's 2024 survey. Humanitec orchestrates the platform but still needs a delivery path underneath it. A managed PaaS like Platform.sh or Heroku is fast, but it adds another ICT third party to your register and runs in the vendor's account, which weakens residency control.

Qovery is DORA compliant as a provider and takes a different position: it deploys into your own cloud account. That posture is documented on Qovery's DORA page, backed by SOC 2 Type II, with audit rights and a subprocessor list available through the Qovery Trust Center. A vendor that can evidence its own DORA posture shortens the assessment when it goes into your register of information. It does not, and I want to be exact here, transfer or reduce your obligations.

Why does BYOC (bring your own cloud) matter so much under DORA?

Under DORA the contract, the data location, the audit rights and the exit path all have to be in your name, which is the structural reason regulated fintechs keep landing on BYOC. The workload runs in your own AWS, GCP, Azure or Scaleway account, or your own Kubernetes cluster, so no extra vendor sits between you and your supervisor.

Whoever holds the cloud contract owes the audit rights, the subcontracting disclosure and the exit assistance, so keeping that relationship direct is worth a lot. Data residency, EU boundary and your own encryption keys stay under your control instead of a vendor's. Every provider-hosted PaaS you add, by contrast, is another entry in the register of information, another vendor assessment, and another exit plan to write and test. And when the second region or second provider is a configuration change rather than a rewrite, concentration risk stops being a board-level worry and becomes a Tuesday afternoon.

This is where Qovery fits. Qovery is DORA compliant and deploys and operates applications inside your own cloud account across AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster, so the bill, the discounts, the data and the exit path stay with you. Deployments are audit-logged, access is scoped with per-environment roles, and you can connect your existing cluster rather than hand your workloads to someone else's platform.

The boundary is worth stating plainly, because it is where teams get themselves in trouble. Qovery being DORA compliant does not transfer or reduce your obligations. Qovery is not a GRC tool, does not produce your register of information, does not run your TLPT, and does not file your incident reports. It generates the operational evidence those processes consume. The financial entity still owns the compliance.

How should a fintech team choose, and what does a 90-day DORA plan look like?

Pick the cloud on data residency and existing skills, pick a GRC platform for the register and reporting, and pick a delivery layer that is itself DORA compliant and produces audit evidence automatically. Then spend 90 days producing the three artefacts auditors always ask for: a complete change trail, a dated restore test, and an executed exit test.

Run the decision through a short checklist first: your EU residency requirements, whether you fall in TLPT scope, how many ICT third parties you are willing to carry in the register, whether each vendor can evidence its own DORA posture, your in-house platform capacity, and a realistic exit window. Then execute in three phases.

The common mistakes are predictable: buying a GRC tool and calling it done, assuming a provider certification covers you, writing an exit plan nobody has executed, and letting evidence live only in CI logs that rotate in 30 days. Avoid those four and you are most of the way there.

If you take one thing from this, take this: no cloud, no GRC tool and no platform makes you DORA compliant by itself, but the right combination makes the evidence fall out of your normal workflow instead of a fire drill. Qovery is DORA compliant and gives your team self-service, audit-logged deployments on your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so the contract and the exit path stay yours. Try Qovery free and get your first environment running in under 10 minutes, or come argue the details with us on Discord.