DORA has changed the cloud conversation for banks. Infrastructure is no longer judged only on uptime, performance and price. It is judged on whether the bank can control and provide needed evidence in an effective manner.

Under Articles 28–30, every cloud provider supporting a critical or important function creates a documentation obligation. Banks must maintain a register of ICT provider arrangements, assess concentration and substitutability risk, ensure contractual visibility into subcontracting chains, and hold tested exit plans. All that evidence sits with the bank — not the provider.

DORA does not require banks to use EU cloud providers. But the right EU-based managed cloud provider can make the Article 28–30 evidence file easier to build, maintain and defend. This post explains where the documentation burden comes from and what reduces it.

What Articles 28, 29 and 30 Require: A Quick Reference

Articles 28, 29 and 30 of DORA set out the core cloud-provider obligations for EU banks: risk strategy and register (Article 28), concentration risk assessment (Article 29), and contractual provisions including audit rights and exit support (Article 30).

Three articles create the practical cloud-provider compliance workload. Understanding which obligation sits where avoids mismapping evidence to the wrong regulatory basis:

• Article 28 — ICT third-party risk strategy, register of information (standardised under Implementing Regulation EU 2024/2956), due diligence before contracting, ongoing monitoring, and exit strategies for ICT services supporting critical or important functions. Article 28(8) requires exit plans to be comprehensive, documented, sufficiently tested and periodically reviewed.

• Article 29 — Concentration risk assessment at entity level: substitutability of the provider, risk from multiple arrangements with connected providers, assessment of subcontracting-chain depth and complexity, and third-country considerations where relevant.

• Article 30 — Key contractual provisions: data-location commitments, subcontracting conditions and notification requirements, SLA definitions, audit and access rights (Article 30(3)(e)), regulator cooperation language (Article 30(2)(g)), and exit support obligations.

The compliance obligation remains with the financial institution throughout, regardless of which provider is used and regardless of that provider’s certifications or designation status. Provider-level controls can reduce evidence collection effort. They do not shift the obligation.

Where the Documentation Burden Concentrates

Banks that use complex, multi-layer cloud arrangements carry the heaviest Article 28–30 evidence workload — regardless of provider geography. According to the ESAs’ November 2025 designation list, Amazon Web Services EMEA Sarl, Google Cloud EMEA Limited and Microsoft Ireland Operations Limited are among the entities designated as critical ICT third-party providers under DORA, reflecting their systemic importance and bringing them into the DORA oversight framework. Designation does not reduce the bank’s compliance obligation.

The documentation burden varies by cloud arrangement, not by provider nationality. Three structural factors drive most of it:

Subcontracting Chain Depth and Churn

Providers with large, dynamic sub-processor lists require ongoing tracking. Material changes should be monitored through the bank’s ICT third-party risk process and Article 30 notification clauses, with the Article 29 concentration-risk assessment updated where the change affects substitutability, provider dependence or subcontracting-chain risk. The more providers in the chain, and the more frequently that chain changes, the higher the maintenance cost.

Third-Country Legal Risk Documentation

Providers subject to third-country law — including provisions that can require disclosure of EU-held data — create a documented legal transfer risk that requires analysis under GDPR Article 48 and DORA third-party risk assessment requirements. This is ongoing, not a one-time exercise at contract signing.

Exit Strategy Complexity for Proprietary Service Stacks

Banks that have built dependencies on proprietary managed services — specific database engines, serverless compute, ML pipeline tooling — face a substantive technical programme to build a credible tested exit strategy under Article 28(8). The more proprietary the integration, the harder it is to demonstrate realistic substitutability under Article 29.

The documentation burden is not a function of provider geography. It is a function of how many provider layers exist, how stable the subcontracting structure is, how auditable the contract and data-location arrangements are, and how tractable the exit plan is. Provider models that score better on those dimensions reduce the bank’s ongoing Article 28–30 evidence work.

How an EU-Based Managed Cloud Provider Reduces the Evidence Burden

A single EU-based managed cloud provider with direct infrastructure control can materially reduce the bank’s Article 28–30 documentation workload. According to the EBA’s February 2025 amendment to its ICT and security risk management guidelines, those changes were made specifically to avoid duplication with DORA’s harmonized requirements — confirming that DORA is now the primary ICT risk framework for in-scope financial institutions. Choosing a provider model that fits that framework cleanly reduces ongoing maintenance effort.

The reduction is real when the provider model is genuinely simpler — and conditional on the provider being able to demonstrate the following:

• Direct operational control of infrastructure, not resale or brokerage of third-party capacity.

• Stable subcontracting with clear notification processes for changes affecting critical or important functions.

• EU data-location commitments documented at contract level.

• Contractual audit and access rights satisfying Article 30(3)(e), with regulator cooperation language aligned to Article 30(2)(g).

• Tested business continuity and disaster recovery processes with available test evidence.

• Exit support provisions: data export formats, handover process, transition period commitments and technical runbook.

Where those conditions hold, the practical benefits for the bank’s evidence file are:

• Simpler subcontracting assessment. Fewer provider layers and lower subcontractor churn mean fewer Article 29 reassessments over time.

• Clearer data-location story. EU infrastructure with documented data-location commitments reduces the scope of the GDPR Article 48 third-country risk analysis.

• More tractable exit planning. Standardized service layers on managed infrastructure make Article 28(8) exit plans achievable and testable without a multi-year proprietary migration programme.

• Easier audit preparation. ISO 27001 and ISO 22301 certification coverage where in scope — and controls mapped against EUCS candidate-scheme requirements where relevant — means the bank can reference provider-level evidence rather than building equivalent documentation internally from scratch.

• Cleaner Article 30 contractual evidence. One primary provider relationship means one contract to maintain, one audit rights clause to manage and one SLA structure to present to supervisors. No gaps between infrastructure and application layers create ambiguity about which vendor is responsible for what.

• Stronger Register of Information inputs. A provider that can supply the required data in structured form, aligned to Implementing Regulation (EU) 2024/2956 templates, reduces the bank’s internal effort to populate and maintain the Article 28(3) register.

ASEE Cloud is built for banks that need a defensible Article 28–30 evidence file, not just hosting capacity.

Our managed cloud offer covers EU-located infrastructure under a single contract, with PCI, ISO 27001 and ISO 22301 certification in scope, controls mapped against EUCS candidate-scheme requirements where relevant, and documented subcontracting arrangements designed to support Article 29 and 30 obligations. We provide the evidence pack items listed below as part of the provider relationship — so banks face fewer fragmented evidence requests, clearer contractual accountability and a cloud provider relationship that is easier to explain and defend during a supervisory review.

We work with financial institution clients across Central and Eastern Europe, Southeast Europe and the Middle East, where DORA and equivalent national frameworks require documented, auditable third-party ICT arrangements.

What Your Cloud Provider Should Be Able to Hand You

A DORA-ready cloud provider should supply ten core documentation items covering Articles 28, 29 and 30 obligations. If a provider cannot supply these items, the bank may still be carrying that evidence burden internally — or may have a gap in its Article 28–30 control file.

• Articles 28/29/30 mapping matrix — showing which contractual and operational controls correspond to each regulatory obligation.

• Register of Information data pack — structured to the templates in Implementing Regulation (EU) 2024/2956.

• Subcontractor list — with names, locations, services provided and the notification process for any changes affecting critical or important functions.

• Data-location and data-transfer assessment — documenting where data resides and what third-country transfer risk analysis applies.

• ISO 27001 and ISO 22301 certificates — with scope statements confirming which services are covered.

• BCP and DR test evidence — results from the most recent tested exercise, not just the plan.

• Incident notification and escalation procedure — designed to support the bank’s Article 19 reporting process and timelines.

• SLA and KPI documentation — with defined service levels for critical functions.

• Exit support pack — data export formats, handover process, transition period commitments and technical runbook.

• Audit and access rights wording — contractual provisions satisfying Article 30(3)(e), with regulator cooperation language aligned to Article 30(2)(g).

What Banks Should Action Before the Next Supervisory Review

Banks need to complete three things before their next DORA review: the Article 28(3) register of information, tested Article 28(8) exit strategies, and an updated Article 29 concentration risk assessment.
According to the ECB’s SSM Supervisory Priorities 2025–27, DORA implementation is an active supervisory focus area. Supervisors are collecting data on third-party ICT provider dependencies specifically to identify concentration risks and gaps in outsourcing frameworks. Targeted on-site inspections on operational risk and DORA compliance are explicitly in the program.

Three areas require immediate attention:

–Complete the Article 28(3) register of information using the templates from Implementing Regulation (EU) 2024/2956. Cloud infrastructure will often qualify where it supports core banking, payments, customer-facing digital channels, operational resilience workloads or other critical or important functions. The register must be available to the auditing authority on request.

–Test the Article 28(8) exit strategies. Run a tabletop or technical test of exit procedures, document the results and make those results available. An exit plan that has never been exercised does not satisfy the Article 28(8) standard.

–Assess the Article 29 concentration risk position. For banks running multiple critical workloads on the same provider or provider group, the substitutability and exit-risk analysis needs to be current and documented. A legacy outsourcing risk assessment that predates DORA does not meet the requirement.

FAQ

Does DORA require banks to use EU cloud providers?

No. DORA does not mandate the use of EU-based cloud providers. It requires financial institutions to manage, document and demonstrate control of ICT third-party risk under Articles 28–30, regardless of where the provider is based.

What does DORA Article 28 require from cloud providers?
Article 28 requires financial institutions — not providers — to maintain a documented ICT third-party risk strategy, a register of all ICT provider arrangements, due diligence records before contracting, and tested exit strategies for providers supporting critical or important functions. The detailed concentration risk and contractual requirements sit in Articles 29 and 30.

How does DORA treat cloud concentration risk?

Article 29 requires financial institutions to assess concentration risk at entity level: whether reliance on a single provider or a group of connected providers affects their ability to deliver critical or important functions, whether realistic substitution options exist, and how deep and stable the relevant subcontracting chains are.

What evidence is needed for a DORA cloud exit strategy?

Article 28(8) requires exit plans to be comprehensive, documented, sufficiently tested and periodically reviewed. Evidence expected by supervisors includes the plan itself, a record of testing (tabletop or technical exercise), results of that test and documentation of any gaps identified and remediated.

Are US hyperscalers compliant with DORA?

DORA compliance is an obligation of the financial institution, not the cloud provider. Amazon Web Services EMEA Sarl, Google Cloud EMEA Limited and Microsoft Ireland Operations Limited have been designated as critical ICT third-party providers under DORA by the ESAs, reflecting their systemic importance and bringing them into the DORA oversight framework. Designation does not transfer the bank’s compliance responsibility.

How can an EU-based managed cloud provider reduce DORA documentation work?

A managed cloud provider with direct infrastructure control, a stable subcontracting structure, EU data-location commitments, ISO 27001 and ISO 22301 certification coverage where in scope, and documented contractual provisions aligned to Articles 30(3)(e) and 30(2)(g) supports the bank’s evidence file directly. It reduces the number of evidence items the bank must build internally, simplifies the Article 29 concentration-risk assessment and makes the Article 28(8) exit plan more tractable to test. The bank retains the compliance obligation — but the evidence work is materially lighter.

Key Takeaways

DORA does not require banks to use EU cloud providers. It requires them to prove control. The obligation is evidencing ICT third-party risk management under Articles 28–30: register of information, concentration risk assessment, subcontracting visibility, tested exit plans and contractual audit rights. In-scope EU financial entities have been subject to these requirements since 17 January 2025.

The documentation burden is a function of provider model complexity, not provider geography. Deep subcontracting chains with high churn, third-country legal risk requiring ongoing analysis under GDPR Article 48, and proprietary service dependencies that complicate Article 28(8) exit planning all increase the evidence workload — regardless of where the provider is headquartered.

The right EU-based managed cloud provider can make the Article 28–30 evidence file easier to build, maintain and defend — when specific conditions are met. Direct infrastructure control, stable subcontracting, EU data-location, ISO 27001 and ISO 22301 certification in scope, controls mapped against EUCS candidate-scheme requirements, and contractual provisions satisfying Articles 30(3)(e) and 30(2)(g) are the conditions that make the simplification real.

ECB supervisors are actively running targeted OSIs on DORA compliance and collecting third-party ICT provider data. SSM Priorities 2025–27 include concentration risk reviews, outsourcing framework assessments and on-site inspections. Banks should have the Article 28(3) register, tested exit evidence and an Article 29 concentration-risk assessment ready — not a legacy outsourcing register that predates DORA.

Sources

1. EUR-Lex: Regulation (EU) 2022/2554 (DORA) — official text
2. DORA Article 28 — annotated text
3. DORA Article 29 — annotated text
4. DORA Article 30 — annotated text
5. Implementing Regulation (EU) 2024/2956 — ITS on Register of Information
6. EBA: Amended Guidelines on ICT and Security Risk Management (February 2025)
7. ECB Guide on Outsourcing Cloud Services to Cloud Service Providers (2025)
8. ECB Banking Supervision: SSM Supervisory Priorities 2025-27
9. EIOPA: ESAs designate critical ICT third-party providers under DORA (November 2025)
10. CSSF: DORA application scope and date
11. ENISA: Cybersecurity Certification Framework — EUCS scheme status
12. EDPB: Guidelines 02/2024 on Article 48 GDPR (third-country disclosure requests)