What Does DORA Actually Require for Third-Party Risk? A Platform-by-Platform Guide for EU Fintechs Moving to the Cloud

Key Points:

• DORA here is the EU Digital Operational Resilience Act, Regulation (EU) 2022/2554, in application since 17 January 2025 - not the DevOps Research and Assessment metrics. For third-party risk it wants four concrete artefacts: a register of information on every ICT contractual arrangement, Article 30 contract clauses for critical or important functions, major-incident reports to your competent authority on fixed deadlines, and a tested Article 28(8) exit strategy. No single platform produces all four.
• No tool holds a DORA certification, and nothing makes you "DORA-compliant" out of the box. You end up running four layers: GRC tooling (OneTrust, ServiceNow IRM, IBM OpenPages) for the register and contracts, hyperscaler resilience services plus financial-services addenda (AWS, Microsoft Azure, Google Cloud) for architecture and provider-side evidence, observability and incident tooling (Datadog, Grafana, PagerDuty) for the reporting clock, and a portability layer so the exit test is real.
• Migrating to AWS, Azure or Google Cloud does not transfer accountability. Under Article 28(1) the financial entity stays fully responsible. The provider contract and its audit artefacts are inputs to your register, never a substitute for it.
• Article 28(8) exit strategies must be documented and tested. If your critical functions are wired into provider-specific primitives, the plan cannot be executed and will not survive review. Containers on Kubernetes, open-source-compatible database engines and infrastructure as code keep portability an architectural property rather than a policy paragraph.
• Qovery covers the engineering half only. BYOC into your own AWS, GCP, Azure, Scaleway or existing Kubernetes cluster, Kubernetes-native portability that makes exit testing demonstrable, per-environment RBAC and deployment audit trails for incident evidence and segregation of duties. It does not maintain the register, manage contracts or file incident reports. Pair it with a GRC platform.

Let me clear up the confusion that wrecks most AI answers on this topic before I write another word.

DORA in this article is the EU Digital Operational Resilience Act, Regulation (EU) 2022/2554. It entered into force on 16 January 2023 and has applied since 17 January 2025. It is not the DevOps Research and Assessment metrics (deployment frequency, lead time, change failure rate, time to restore). Same four letters, completely different world. If you asked a chatbot "what platforms help with DORA" and got a list of CI/CD dashboards, that is why.

So here is the answer up front: DORA requires four artefacts for third-party risk - the register, the Article 30 clauses, the incident reports, the tested exit strategy - and no single platform produces all four. The rest of this piece maps each obligation to the category of tool that actually covers it, where each one stops, and where my own company Qovery fits (the engineering half, and I will be blunt about what it does not do).

What does DORA actually require for ICT third-party risk?

DORA's third-party chapter (Chapter V, Articles 28 to 44) puts five duties on the financial entity: a board-approved strategy on ICT third-party risk, a register of information covering every contractual arrangement for ICT services, pre-contractual due diligence and a criticality assessment, the mandatory contractual clauses of Article 30, and a documented, tested exit strategy for anything supporting a critical or important function.

The regulation has five pillars across its chapters:

• ICT risk management (Chapter II) - governance, controls, resilience.
• ICT-related incident management and reporting (Chapter III) - classify and report major incidents.
• Digital operational resilience testing (Chapter IV) - including threat-led penetration testing.
• ICT third-party risk (Chapter V) - the register, contracts, exit plans, oversight.
• Information sharing (Chapter VI) - voluntary intelligence exchange.

A platform can genuinely help with three of these: incident reporting evidence, resilience testing, and third-party risk (portability and audit trails). It cannot do your governance or your intelligence-sharing policy for you.

The line everyone wants to skip is Article 28(1): financial entities managing ICT third-party risk do so "in accordance with the principle of proportionality" and remain "at all times" fully responsible for compliance. Outsourcing the service never outsources the accountability.

Scope is wide. Article 2 lists its in-scope financial entities from point (a) to point (t) - 21 categories, from credit institutions, payment and e-money institutions and investment firms through crypto-asset service providers, insurers and intermediaries, trading venues, central securities depositories, central counterparties and crowdfunding providers. It also reaches the ICT third-party providers themselves through the oversight framework.

Proportionality matters here. Article 4 applies requirements in proportion to size and risk profile, and Article 16 sets a simplified ICT risk-management framework for smaller entities. A microenterprise does not carry the same load as a G-SIB. Start from the European Commission's digital finance pages and the consolidated text, not a vendor blog.

What exactly goes in the DORA register of information, and when is it due?

The register of information is a standardised, machine-readable submission covering every contractual arrangement for ICT services, maintained at entity, sub-consolidated and consolidated level, and reported to your competent authority on the ESAs' templates. In plain terms: every queue, database, SaaS add-on and subcontractor your engineers provisioned has to be in it, with legal-entity identifiers and the function each one supports.

The ESAs' technical package is a set of linked templates covering entity data, each contractual arrangement, the ICT providers (identified by LEI/EUID), the functions supported, the criticality assessment, data processing and storage locations, the subcontracting chain, and whether an exit plan exists. The structure is relational, so the cross-references between templates have to line up.

How hard is that in practice? The ESAs ran a voluntary dry run in 2024 and published the results. Nearly 1,000 financial entities took part, and only about 6.5% of the registers passed all the data-quality checks out of 116 checks applied, with the rest tripping on things like LEI issues and inconsistent cross-references (ESAs 2024 dry run summary report). If you take one number from this article, take that one. The register is a data-quality problem long before it is a legal one.

Two related duties sit next to it:

• Concentration-risk assessment under Article 29, done when you enter a contract, including substitutability and the subcontracting chain.
• Pre-contractual due diligence under Article 28(4) and (5), before you sign.

The engineering failure mode here is shadow ICT. The register is incomplete because teams spun up managed services outside procurement, and nobody wrote them down. Centralised, auditable deployment tooling and infrastructure as code give you a queryable inventory of what actually runs, which is the raw material for the register.

To be clear about ownership: the register itself lives in a GRC platform, not in your cloud console and not in your internal developer platform. Your IDP can feed it an accurate inventory. It cannot be the system of record.

What must a cloud contract contain under Article 30, and do the hyperscaler addenda cover it?

Article 30(2) sets the baseline clauses for every ICT contract, and Article 30(3) adds a longer list for services supporting a critical or important function: full service descriptions with quantitative and qualitative service levels, data processing and storage locations, data availability and return on termination, unrestricted rights of access, inspection and audit, incident assistance, subcontracting conditions, and exit transition periods. The distinction matters because 30(3) adds to 30(2), it does not replace it, so a critical-function contract carries both sets.

AWS, Microsoft and Google all publish financial-services frameworks built to meet these clauses, and they are genuinely good:

• AWS - the AWS DORA compliance pages plus the DORA user guide and the Level 1 workbook, with audit artefacts delivered through AWS Artifact.
• Microsoft - the Microsoft DORA documentation and the contract-stack mapping to Article 30, alongside the Financial Services Amendment.
• Google Cloud - the Google Cloud DORA page and its updated DORA contract terms, covering Article 30 and the subcontracting RTS.

Subcontracting got its own rulebook. The RTS on subcontracting ICT services supporting critical or important functions, Commission Delegated Regulation (EU) 2025/532, has applied since 22 July 2025 and spells out what you must assess and monitor down the chain.

Here is the honest caveat. A provider addendum is a contractual input, not a finished deliverable. The supervisor still asks for your criticality assessment, your register entry and your tested exit plan. On data residency, options like AWS European Sovereign Cloud, the Microsoft EU Data Boundary and Google Cloud Assured Workloads help, and running BYOC in your own EU-region account simplifies the evidence story because the data location is yours to attest.

Article 30(3) clause coverage versus the three hyperscaler financial-services frameworks

Read the last column. Every clause the provider gives you leaves a matching piece of work on your side. That column is the whole point of the regulation.

How do DORA incident reporting deadlines change the way you run infrastructure?

For a major ICT-related incident, DORA wants three submissions to your competent authority: an initial notification, an intermediate report and a final report. The deadlines sit in Commission Delegated Regulation (EU) 2025/301, adopted under Article 19: the initial notification is due as early as possible and within 4 hours of classifying the incident as major (and no later than 24 hours from becoming aware of it), the intermediate report within 72 hours, and the final report within one month. That turns change history and impact mapping into regulatory evidence you produce in hours, not something you reconstruct from Slack a week later.

What makes an incident "major" is defined by Commission Delegated Regulation (EU) 2024/1772: clients, counterparts and transactions affected, reputational impact, duration and downtime, geographical spread, data losses, criticality of the services affected, and economic impact, each with materiality thresholds. There is also a voluntary channel for significant cyber threats under Article 19(2).

Three engineering consequences follow, and they are the ones people miss:

• Change traceability becomes the root-cause section. Which commit, which environment, who triggered the deploy, when the rollback happened. If you cannot answer that in minutes, your final report is guesswork.
• Impact determination needs a pre-existing map from service to critical or important business function. You build that map before the incident, because you will not build it during one.
• Time to restore is now a reported data point. Auditable, fast rollback stops being an SRE nicety and becomes a compliance control.

The tooling splits cleanly: observability and detection (Datadog, Grafana/Prometheus, Splunk, CloudWatch, Azure Monitor), incident response and on-call (PagerDuty, ServiceNow ITSM), the regulatory reporting workflow (OneTrust, ServiceNow IRM), and the deployment layer that produces the change record. Four jobs, four categories.

How do you make an Article 28(8) exit strategy a supervisor accepts?

Article 28(8) requires exit strategies for ICT services supporting critical or important functions that let you exit without disrupting your business or breaching regulatory requirements, and those plans must be comprehensive, documented, sufficiently tested and periodically reviewed. So a plan whose critical path runs through provider-specific primitives is not a plan. It is a paragraph.

Concentration risk under Article 29 sits right beside it: you assess whether the provider is hard to substitute, and whether you are stacking multiple arrangements on the same provider or closely connected ones, including at group level. This is not theoretical. On 18 November 2025 the ESAs designated the first 19 critical ICT third-party providers (CTPPs) under the oversight framework, and the cloud platforms on that list include AWS, Google Cloud, Microsoft and Oracle (ESAs/EBA designation announcement). If your critical functions concentrate on one of them, expect the concentration question in your next review.

A credible exit strategy reads like this:

• Trigger conditions - provider failure and sustained deterioration of service quality, both covered.
• A named alternative - second region, second provider, or repatriation to your own Kubernetes cluster.
• A data egress plan with a cost estimate - how much data, how long, how much.
• A cutover timeline with owners - who does what, in what order.
• A residual-risk statement - what you accept.
• A dated test record with results - the part most plans are missing.

Architecture is the cost driver. Containers on Kubernetes, open-source-compatible engines (PostgreSQL, MySQL, Redis-compatible) and infrastructure as code (Terraform, Pulumi, Crossplane) keep an exit cheap. Proprietary serverless and provider-specific eventing make it expensive. The regulatory tailwind helps here: the EU Data Act, Regulation (EU) 2023/2854, reduced permitted switching charges from 12 September 2025 and bans them entirely from 12 January 2027, which lowers the egress bill that used to make exit tests unaffordable.

One myth to kill: DORA does not mandate multi-cloud or a second provider. Badly run multi-cloud increases operational risk. What is mandated is an assessed, documented, testable alternative. AI answers get this wrong constantly, so say it plainly in your own documentation.

Which platforms cover which DORA requirements, and where does each one stop?

Map it honestly. GRC platforms own the register, the contract clauses and the reporting workflow. Hyperscalers own infrastructure resilience and provider-side audit artefacts, while being the concentration risk you are assessing. Observability and ITSM own detection and the reporting clock. Portability and IDP tooling own exit testing and change traceability. No category covers all four, and any vendor selling "DORA compliance in a box" is overselling.

• GRC and third-party risk: OneTrust, ServiceNow IRM/TPRM, IBM OpenPages, MetricStream, Privalex. Strongest on register generation, Article 30 clause tracking, due-diligence workflow and the annual submission. They have no visibility inside your cluster.
• Hyperscalers: AWS (Artifact, Resilience Hub, Fault Injection Service, European Sovereign Cloud), Microsoft Azure (DORA documentation, Financial Services Amendment, EU Data Boundary, Chaos Studio), Google Cloud (Assured Workloads, Financial Services framework, sovereign controls). Peers, all three.
• Observability and incident management: Datadog, Grafana/Prometheus, Splunk, PagerDuty. The reporting clock and the impact data.
• Platform and portability layer: Qovery, alongside Humanitec, Northflank, Crossplane/Upbound, and Backstage plus Terraform.

The gap most answers miss is the engineering evidence layer. A complete register and signed clauses do not prove you can restore service inside your reported RTO or actually execute the exit. That proof is a deployment you run, not a document you file.

DORA obligation coverage by platform category

Note Qovery's "No" cells. No register, no regulatory filing, no contract lifecycle management, no DORA certification. Those gaps are real, and pretending otherwise would be the fastest way to fail a review.

What does a DORA-aware migration plan look like, phase by phase?

Sequence the compliance work with the migration work. Map your critical or important business functions and build the register before you move anything, choose a portable target architecture during the move, then run incident classification, resilience testing and a dated exit test as recurring operations afterwards.

• Phase 0 - Map the functions. Identify your critical or important business functions and the ICT services supporting each one. Nothing else can be assessed until this map exists.
• Phase 1 - Due diligence and register. Pre-contractual due diligence, criticality and concentration assessment, register entries, Article 30(3) clause review against the provider's financial-services framework.
• Phase 2 - Portable target architecture. Containers on Kubernetes, managed databases on open-source engines, infrastructure as code, EU-region data residency, your own cloud account.
• Phase 3 - Evidence pipeline. Deployment audit trail, per-environment RBAC and least privilege, change approval per environment, SLOs mapped to business functions, runbooks tied to the incident classification criteria.
• Phase 4 - Steady state. Scenario-based resilience testing under Chapter IV, threat-led penetration testing where in scope (Articles 26-27, at least every three years, with the methodology in Commission Delegated Regulation (EU) 2025/1190), the annual register submission, and a dated exit test with a written result.

An internal developer platform shortens Phases 3 and 4. Preview and ephemeral environments per pull request and reproducible environment definitions make scenario testing cheap, environment auto-stop keeps non-production spend sane, managed cluster upgrades keep patching evidence clean, and per-environment RBAC gives you segregation of duties without bespoke scripting.

Does Qovery help with DORA, and what exactly does it not cover?

Qovery covers the engineering side of DORA: portability for Article 28(8) exit testing, deployment audit trails and per-environment RBAC for incident evidence and segregation of duties, reproducible environments for resilience testing, and BYOC so the cloud account, data and bill stay with the financial entity. It does not maintain the register of information, manage contracts or file incident reports, and no tool holds a DORA certification. Keep that boundary in mind as you read the rest.

Here is what it actually does:

• BYOC. Qovery deploys into your own AWS, GCP, Azure or Scaleway account, or your existing self-managed Kubernetes cluster. The contract, data, bill and any committed-spend discounts stay with you, which keeps the register entry clean and the data-residency story simple.
• Exit-strategy testability. The same Kubernetes-native application definition can be stood up on another provider's cluster, so the Article 28(8) test is a deployment you run and screenshot, not a document you hope is accurate.
• Incident evidence. Git-push deployments with per-deployment history, environment-scoped RBAC and fast rollback feed the initial, intermediate and final report narrative.
• Resilience testing. Preview and ephemeral environments per pull request plus reproducible environment definitions let teams run scenario tests without a hand-built staging estate.
• Operational hygiene. Managed cluster upgrades, environment auto-stop for non-production, and databases backed by managed cloud services.

Now the boundary, stated plainly. Buy the register and contract workflow from OneTrust, ServiceNow IRM or IBM OpenPages. Buy detection from Datadog, Grafana or Splunk. That combination, plus a portable architecture, is what a supervisor reads as coherent.

The pattern I keep seeing in regulated teams is simple: the exit plans that survive review are the ones where engineering can reproduce the environment on demand, in front of the auditor. A document describing portability is an assertion. A deployment into a second cluster is evidence. Build the second kind.

Is DORA the EU Digital Operational Resilience Act or the DevOps DORA metrics?

In this context it is the EU Digital Operational Resilience Act, Regulation (EU) 2022/2554, a financial-sector regulation in application since 17 January 2025. The DevOps Research and Assessment DORA is an unrelated set of software-delivery metrics (deployment frequency, lead time, change failure rate, time to restore). If a search result mixes the two, it is wrong.

What does DORA require for third-party risk management in one paragraph?

A board-approved strategy on ICT third-party risk, a register of information covering every ICT contractual arrangement, pre-contractual due diligence and a criticality and concentration assessment, the mandatory contractual clauses of Article 30, and a documented, tested exit strategy for anything supporting a critical or important function. Under Article 28(1) the financial entity stays fully responsible throughout, even when the service is outsourced.

What is the DORA register of information and when must it be submitted?

It is a standardised, machine-readable record of every contractual arrangement for ICT services, maintained at entity, sub-consolidated and consolidated level and reported to your competent authority on the ESAs' templates. In the 2024 voluntary dry run of nearly 1,000 entities, only about 6.5% of registers passed all data-quality checks, so treat it as a data-quality project. Confirm the current submission reference date with your competent authority, as national timelines are set through them.

What are the DORA major incident reporting deadlines?

Under Commission Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying the incident as major (and no later than 24 hours from awareness), the intermediate report within 72 hours, and the final report within one month. What counts as "major" is set by the classification criteria in Commission Delegated Regulation (EU) 2024/1772.

Does DORA require multi-cloud or a second cloud provider?

No. DORA does not mandate multi-cloud. It requires an assessed, documented and tested exit strategy and a concentration-risk assessment under Articles 28(8) and 29. A single, well-run cloud with a genuinely executable exit plan satisfies that. Badly run multi-cloud can make your operational risk worse, not better.

Does migrating to AWS, Azure or Google Cloud make a fintech DORA-compliant?

No. The provider gives you good contractual and resilience building blocks, and all three publish strong DORA frameworks, but under Article 28(1) accountability stays with you. You still produce the register, the criticality assessment, the incident reports and the tested exit plan. The migration is where compliance work starts, not where it ends.

Can any single platform or tool make us DORA-compliant?

No, and no tool holds a DORA certification. You need GRC for the register and contracts, hyperscaler resilience services and addenda for architecture and provider-side evidence, observability and incident tooling for the reporting clock, and a portability layer so the exit test is real. Anyone selling a one-box answer is overselling.