How does DORA apply to DORA cloud providers like AWS, Azure and Google Cloud?
DORA places its duties on the financial entity, not on the cloud provider. If your bank, payment institution or insurer runs workloads on a hyperscale cloud, you remain responsible for ICT risk management, the register of information, contract terms and exit planning for those workloads. The 18 November 2025 list of designated critical ICT third-party service providers names Amazon Web Services EMEA Sarl, Google Cloud EMEA Limited and Microsoft Ireland Operations Limited. That designation brings those providers under direct EU oversight by the ESAs as Lead Overseers. It does not transfer your obligations to them, and it does not certify that a service you buy from them is compliant for your use.
Your own cost and effort depend on three things: the scope of the workloads, how easily each one could move to another provider, and what your contracts already say. A non-critical analytics environment that could be rebuilt elsewhere will need far less work than a payments platform that supports a critical or important function and depends on proprietary managed services. Start by confirming which of your ICT services are provided by these three firms, which of those support critical or important functions, and whether the contract terms meet Article 30. Ask your cloud account team which regions and sub-processors serve your data, because the contract must state where services are provided and data processed, and changes need advance notice.
The designation also changes how supervisors may use their powers. Under Article 42(6), a competent authority can, as a last resort, require you to suspend part or all of a critical provider's service until the risks are addressed, or to terminate the relevant contracts. Plan for that scenario before it happens. Document which workloads would need an alternative, which of them can run on a second provider or on self-hosted open-source platforms in your own environment, and what it would take to move them. Confirm the specific cloud service terms, subsidiary arrangements and any Union subsidiary requirements directly with each provider and with your competent authority, since the detailed obligations are set out in the delegated acts and provider-specific documents.
How concentration risk and substitutability apply to hyperscale workloads
Hyperscale clouds sit underneath many financial services at once, so DORA asks entities to test concentration and substitutability before they commit a critical or important function to one provider. The five decisions below follow the order in which those questions usually arise, from the definition in Article 3(29) to the evidence that shows the assessment was made.
Does the dependency meet the concentration definition
Article 3(29) defines ICT concentration risk as exposure to one or more related critical ICT third-party providers, where their unavailability or failure could endanger critical or important functions, cause large losses or endanger EU financial stability. For AWS, Azure and Google Cloud, the first question is whether the workload's failure would reach that threshold, not whether the provider is large. Record the workload, the function it supports and the provider it runs on, and confirm with the provider whether it appears on the critical list. Keep the analysis that concludes the dependency does or does not meet the definition.
Is the provider easily substitutable
Article 29(1) asks whether contracting a provider that is not easily substitutable would be a risk when the service supports critical or important functions. For hyperscale workloads, substitutability depends on proprietary managed services, data formats, identity integration and the effort needed to rebuild a function elsewhere. An entity running portable containers on a documented Kubernetes distribution will often answer differently from one relying on a single proprietary database service. Keep a written substitutability assessment for each critical workload.
Multiple arrangements with closely connected providers
Article 29(1) also asks whether the entity holds several arrangements with the same provider or with closely connected providers. Splitting a function across two accounts with one cloud group, or using a cloud marketplace vendor that runs on the same hyperscaler, can leave the dependency unchanged. Map the chain of providers beneath each workload, including managed services and subcontractors, and check where separate contracts share a single underlying platform. Record the mapping in the register of information.
Weighing the costs of alternatives
Article 29(1) requires the entity to weigh the costs and benefits of alternative solutions. Options include a second cloud region, a second provider for a subset of workloads, or self-hosted open-source components that can run on either provider or on-premises. Estimate the cost of each option, including migration effort, data egress, staff skills and the time needed to restore service. Ask each provider for its exit and data return terms so the comparison rests on contract facts, not assumptions.
Identifying workloads behind critical functions
The concentration and substitutability analysis only works if the entity knows which AWS, Azure or Google Cloud resources support critical or important functions. Start from the function inventory, then trace the accounts, subscriptions, projects, regions, databases, identity services and backup targets that deliver it. Shared landing zones and central logging accounts often carry dependencies that a function-level view misses. Keep the traced map, the owner for each workload and the date of the last review so an assessor can follow the reasoning.
The Union subsidiary rule for third-country cloud providers
Article 31(12) of DORA sets a condition that matters directly for hyperscale cloud use: a financial entity may use a critical ICT third-party provider established in a third country only if that provider sets up a subsidiary in the Union within 12 months of its designation. The rule is about the provider's legal presence in the EU, not about where your workloads run. Several major cloud providers are on the first list of designated critical providers, dated 18 November 2025, so the question is live for any financial entity that relies on them. Start with the designation list itself and confirm which legal entity appears against each provider, because the designated name is often an EU-established contracting company rather than the US parent.
Verify three things before you assume compliance. First, identify the contracting entity on your cloud agreement and check whether it is the EU-established company named on the designation list. Second, establish where the services are delivered from and where support and administrative access originate, since a provider can be EU-established while depending on a non-EU operating entity. Third, ask the provider in writing how it has met or will meet the 12-month subsidiary requirement, what the subsidiary's role is, and whether any of the Article 31(12) timing applies to your specific services. Keep the answers in your third-party file as evidence.
Some points cannot be settled by the financial entity alone. The timing and status of any subsidiary, and how each designated provider interprets the rule for its own structure, should be confirmed with the provider and checked against the ESAs' published information rather than inferred from marketing material or from the provider's general EU presence. If the answers are unclear, record the gap, raise it in your exit and concentration risk analysis, and ask counsel to review the contract. Consider bringing in outside legal or compliance advisers for this review; an implementation partner can help map the evidence, but the regulatory interpretation and any reporting remain with you and your competent authority.
Which Article 30 contract clauses a cloud agreement must contain
This table maps each Article 30(2) contract element under DORA to what the financial entity should ask a hyperscale cloud provider to commit to in writing. Read each row as a negotiation checklist: the standard terms may not match the requirement, so check each item against the provider's agreement and any addenda before signing.
| Article 30(2) element | What to request from AWS, Azure or Google Cloud | What to check before signing |
|---|---|---|
| Services and permitted subcontracting | A clear service description referencing the specific cloud services in use, and the provider's list of subcontractors that may support them | Whether the service catalogue and subcontractor list are incorporated by reference and how changes are notified |
| Locations of services and data | Named regions or jurisdictions where services are provided and data is processed, with advance notice before any change | Whether region selection is contractually fixed or only a default setting that the customer can change |
| Data protection | Commitments on confidentiality, integrity and availability of data, including security obligations the provider accepts | Whether shared responsibility documents are binding terms or informational only |
| Data return on insolvency or termination | Defined export formats, timelines and assistance for retrieving data and workloads when the contract ends or the provider fails | Whether deletion after termination is automatic and how long the customer has to export data first |
| Incident assistance | Commitments to support the entity during ICT incidents, with assistance provided at no cost or at a pre-agreed cost | Whether incident assistance is limited to support tiers that carry separate fees |
| Cooperation with authorities | Undertaking to cooperate with competent authorities and to give the entity and its auditors access, inspection and information rights | Whether audit rights are limited to shared certification reports or extend to on-site or remote testing |
| Termination rights and notice periods | Termination rights for the entity where DORA requires them, and defined notice periods that allow an orderly exit | Whether termination rights are limited to material breach, and whether notice periods match the exit plan |
| Article 30(3) clauses for critical or important functions | Additional clauses apply where the cloud service supports a critical or important function. These are covered on the sibling page on identifying critical or important functions. | Confirm the function classification before negotiating, since it decides which extra clauses are needed |
Data location clauses for AWS, Azure and Google Cloud workloads
When production workloads run in EU regions, the data location question starts with the contract, then moves to the provider's documentation and finally to the entity's own architecture. Article 30(2) of DORA requires every ICT services contract to state where services are provided and where data is processed, and to require advance notice before those locations change. A region name shown in a console does not meet that requirement on its own, because the contract is the document the entity can enforce.
- Named locations in the contract. List the EU regions and any processing sites, and cover storage, databases, logs and analytics services separately, since managed services can sit in different places.
- Advance notice of changes. Require notice before the provider adds a region or moves processing, with a window long enough for the entity to assess the change and act on it.
- Provider documentation. Confirm in the provider's published data residency documentation which services are region-bound and which replicate or process data outside the chosen region.
- Entity-owned architecture. Enforce approved regions with policy-as-code and restrict management-plane permissions so that new resources cannot appear in unapproved regions.
Check that the regions named in the contract match the regions that actually host production, backups and logs, and keep a dated record of that comparison.
Many hyperscale services need access from outside the EU for support, troubleshooting or operations, and some diagnostic data leaves the region by default. DORA still expects the entity to know these flows, describe them in the contract and assess the risk they create, because provider staff and sub-processors may access data from third countries. The contract should describe those access paths openly. Illustrative example: a support case opened with a non-EU support team may expose a log excerpt that contains customer identifiers.
- Access and sub-processing map. Ask for the locations from which support and operations staff can reach the environment, and for the list of sub-processors involved, with notice before changes.
- Telemetry and diagnostics settings. Identify which diagnostic, usage and crash data goes to the provider, and which tenant or account settings control that flow.
- Customer-managed controls. Confirm whether customer-held encryption keys or access approval controls are available for each service in use, and how they operate.
- Entity-owned logging and sharing rules. Keep the entity's own security logs in EU storage, and remove personal data from tickets and diagnostic bundles before they are shared with anyone.
Ask the provider in writing which of these flows apply to each in-scope service, then confirm the answers against current documentation and record the date you checked.
Backup and disaster recovery designs often copy data to a second region, which may be in another country or on another continent, sometimes without the team making an explicit choice. The contract still has to state where that data is held and how it comes back to the entity if the relationship ends or the provider fails. Article 30(2) covers data return on insolvency or termination, so the contract should set out the mechanics as well as the principle. The entity remains responsible for its recovery design and for whether recovery copies stay in approved locations.
- Backup region list. State in the contract which regions hold backups, snapshots and replicas, including copies that managed services create automatically.
- Cross-region replication controls. Confirm which services replicate across regions by default and whether replication can be limited to EU regions for each service in use.
- Data return and deletion. Specify the format, timing and method for returning data, and for deleting copies on termination, including backup copies kept for a retention period.
- Entity-owned recovery design. Choose recovery regions inside the EU where the service allows it, test restores in the approved region, and record any non-EU recovery point as a deliberate, approved decision.
Confirm each replication and retention setting in the console or infrastructure code, and check that recovery test evidence names the region that was used.
Building a multi-vendor and exit strategy for a cloud dependency
This sequence turns a hyperscale cloud dependency into a documented decision: which workloads carry critical or important functions, how replaceable each provider is, whether a multi-vendor strategy fits, and how the entity would leave if it had to.
Classify workloads by critical or important function
Start by listing every workload that runs on AWS, Azure or Google Cloud, including the managed services, identity layers, data stores and networking that sit underneath them. For each one, the risk owner and the business or compliance function it supports decide whether it supports a critical or important function under the entity's own methodology. Work with business owners and the ICT risk function, not only the cloud platform team. The output is a classified workload inventory with a short rationale for each classification, reviewed and approved by the management body or the delegated committee. The step is done when every cloud workload has a documented classification and no workload is left unassigned.
Map cloud dependencies to the asset inventory
Link each classified workload to the provider, region, account or subscription, managed services and third-party components it depends on. Include the subcontractors and sub-processors the provider uses where the entity can see them in contract documentation. The cloud team usually holds the technical detail, while procurement and legal hold the contract references. The output is a dependency map that feeds the ICT asset inventory and the register of information. The step is complete when a reviewer can trace any critical workload from the business function down to the specific provider service that runs it.
Document substitutability for each provider service
For each critical dependency, assess how easily the workload could move to another provider or be brought back in-house. Consider proprietary APIs, managed databases, identity integrations, data formats, network design, skills in the team, licence terms and the time and cost a migration would need. Article 29(1) asks entities to consider whether they would be contracting a provider that is not easily substitutable and to weigh the costs and benefits of alternatives. The output is a written substitutability assessment per workload, rated and justified, with named open points. The step is done when the assessment has been challenged by someone outside the cloud team and the open points have owners.
Decide whether a holistic multi-vendor strategy fits
Article 6(9) allows, but does not require, a holistic ICT multi-vendor strategy. Decide whether the entity needs one, based on the concentration and substitutability findings, the cost of running a second provider or a second region, and the skills the team has. Where the entity does not adopt a strategy, the rationale must still be recorded. Where it does, the strategy should set which workloads are multi-vendor, which remain single-provider with a tested exit, and how the approach is governed. Independent advice can help here, but the decision sits with the entity's management body. The step is done when a signed decision exists with its reasoning and review trigger.
Write exit plans for critical cloud services
For each critical or important cloud dependency, write an exit plan that states the trigger for leaving, the target arrangement (another provider, a self-hosted alternative or a reduced service), the data that must be returned or migrated, the sequence of technical steps, the roles involved and the decision points. Align the plan with the termination rights, notice periods and data return terms in the contract, which should be checked against Article 30 requirements. The output is a written exit plan per critical service that the business owner accepts. The step is done when no plan relies on terms the contract does not contain.
Test the exit plan and record results
Run a tabletop exercise or a controlled technical test of the exit plan, covering at least the data export, the rebuild of a representative workload elsewhere and the decision path under provider unavailability. Record what worked, what took longer than assumed, which dependencies were missed and what changed as a result. Results should go to the management body and feed the resilience testing programme and the ICT risk assessment. The step is done when the test report shows measured gaps, owners and a date for remediation, and the exit plan has been updated to match what the test found.
Record the decision and set review triggers
Bring the classification, substitutability findings, multi-vendor decision and exit plans into one approved record that the management body signs. Define review triggers such as a material change in provider services, a new contract, a provider's inclusion or change in the designated critical list, a regulatory change or a significant incident. Keep the record consistent with the register of information and the policies the entity must maintain. The output is an approved, dated record with an owner and a review cycle. The step is done when an independent reviewer can follow the chain from business function to exit plan without gaps.
What supervisors can do if a cloud provider creates unacceptable risk
Under Article 42(6) of DORA, a competent authority can require a financial entity to temporarily suspend, in part or in full, its use of a critical ICT third-party provider's services until the risks are addressed, or to terminate the relevant contracts. For a workload running on AWS, Azure or Google Cloud, that could mean a supervisor ordering a bank to stop using a specific cloud region, a managed database service or a set of accounts. The power is a last resort, and it sits with the supervisor. The financial entity does not trigger it, cannot rely on it as a fallback and has no contractual right to expect it.
That distinction shapes what the entity must do in advance. Once a supervisory order arrives, the only question is how quickly the affected functions can keep running without the provider. The answer depends on work done beforehand: an architecture that identifies which critical or important functions depend on which cloud services, a substitutability assessment that Article 29(1) already requires before contracting, and an exit plan that has been tested rather than written and filed. Ask whether your exit plan names the specific cloud services, the target platform for each one, and the data and configuration needed to rebuild them. Ask whether a timed exercise has shown that the rebuild works within the period your continuity plan allows.
Practical steps follow from this. Confirm that your contracts with each hyperscaler contain the Article 30 clauses on data location, data return, cooperation with authorities and termination rights, so that a suspension order can be carried out without a contractual dispute. Keep a current register of which cloud services support each function, so you can answer a supervisor's question within hours. Where a self-hosted or open-source component can run in your own accounts or a second provider's environment, record whether it has been deployed and tested there. Confirm these points with your competent authority and with your legal team, because the practical expectations of each authority may differ.
Questions buyers ask about DORA and hyperscale cloud
Does AWS, Azure or Google Cloud need a DORA certificate?
No. DORA sets no certification scheme, so there is no DORA certificate that a cloud provider can hold or that a financial entity can require as proof of compliance. Competent authorities supervise compliance using their powers under Article 50, and the only authority-issued attestation the Regulation provides for concerns threat-led penetration testing under Article 26(7). What a financial entity can ask for is contractual evidence: the provider's contract terms under Article 30, its security documentation, and independent audit reports that the provider already produces for other customers. Those reports are inputs to the entity's own assessment. They do not discharge the entity's obligations, and the entity should confirm with the provider which reports cover the specific services it uses.
Who pays for DORA work on cloud workloads?
The financial entity pays for its own DORA work, and the cloud provider's standard terms are not a substitute for it. Costs fall into a few groups: internal staff time for the ICT third-party risk policy, register of information entries and exit planning; external advisers for gap analysis, architecture review and documentation; engineering effort to build controls such as encryption, logging, backup and data location settings in the entity's accounts; and contract negotiation, where the entity may need legal support. Some costs recur, such as register upkeep, assurance reviews and exit tests, while others are one-time, such as the initial design. Cost rises with the number of accounts, regions and critical functions in scope. Ask any implementation partner for a fixed-scope quote that lists these items separately.
Does being on the critical provider list remove our DORA duties?
No. The list of designated critical ICT third-party service providers, dated 18 November 2025, names providers such as Amazon Web Services EMEA Sarl, Google Cloud EMEA Limited and Microsoft Ireland Operations Limited. Designation moves direct oversight of the provider to the ESAs as Lead Overseers, but the financial entity remains responsible for its own ICT risk management, its register of information, its contract terms under Article 30 and its exit strategy. Article 6(10) confirms that an entity may outsource verification of compliance but stays fully responsible. Designation also does not mean the provider is free of concentration concerns, which an entity must still assess under Article 29.
How long does a DORA review of cloud workloads take?
No supplied timeline exists for this work, so no duration can be stated. The length depends on the number of accounts, regions and services in scope, whether the workloads support critical or important functions, how complete the existing inventory and register entries are, how many contracts need renegotiation, and how many teams must review the evidence. A narrow review of one critical function on a single provider will differ greatly from a group-wide review. Ask any provider of this work for a written timeline tied to a defined scope, and ask what dependencies, such as legal review or access to cloud accounts, could extend it.
Can our internal team handle DORA work on cloud workloads?
Often yes for the policy and governance parts, and sometimes for the technical parts, but it depends on capacity and skills. An internal team usually already owns the asset inventory, access reviews and backup routines, which are inputs to DORA. Gaps tend to appear in the ICT third-party risk documentation, the exit plans for critical services, contract clause review under Article 30, and testing that involves providers. Ask the team to check whether it can produce evidence for each Article 30 clause and each critical function within the timeline the entity needs. Where it cannot, an external partner can prepare systems and evidence, while the organization keeps ownership of its controls and decisions.
What should we ask for in a DORA cloud quote?
Ask for a written, fixed scope that names the entities, cloud accounts, regions, workloads and critical or important functions covered. The quote should list deliverables separately, such as the gap analysis, the register inputs, contract clause review against Article 30, exit plan documentation, and any testing. It should state what the entity must provide, such as account access, contract copies and staff time, and what is excluded, such as legal opinions or audit reports. Confirm the timeline, the assumptions behind it, how change requests are priced, and whether ongoing support is a separate retainer. Also confirm that the partner prepares evidence but does not issue audit reports or attestations, which independent assessors provide.
How DeployOpen prepares cloud workloads for DORA review
DeployOpen plans and implements self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, so the workloads, configurations and records that a DORA review will examine are built to be inspected. We prepare systems, controls and evidence for the financial entity, while the entity owns its controls and independent assessors make any judgment on them.
How we scope
- Each engagement starts with a written scope that names the cloud accounts, regions and workloads in play across AWS, Azure or Google Cloud.
- We map which workloads support critical or important functions, so the review focuses on the systems that carry the most dependency.
- We confirm with your team which provider contracts, data locations and subcontractors the scope touches before any build work begins.
How we build
- We configure self-hosted platforms with documented dependencies on hyperscale services, so substitutability and exit questions can be answered from the design.
- We set up logging, backup and recovery for workloads, and record where data is stored and processed for each cloud region in use.
- We document provider-specific configuration choices so the entity can show how a single cloud dependency is contained or kept portable.
How we hand over
- We deliver architecture records, dependency maps, configuration baselines and evidence packs that map to the entity's own DORA documentation.
- We run the testing agreed in scope and deliver findings with remediation status, so the entity can decide what its risk owners accept.
- We hand over runbooks and an exit-related description of each platform, so the entity's own staff can operate and review it after the engagement.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers that follow the agreed scope.
- We can keep dependency maps and evidence packs current as cloud services, regions and contracts change over time.
- Independent auditors and competent authorities assess the result. DeployOpen does not issue reports, attestations or certifications.
