DORA and cloud: exit strategies, the register of information and concentration risk

Where DORA stands in October 2026

According to the Czech National Bank, Regulation (EU) 2022/2554 on digital operational resilience for the financial sector has applied since 17 January 2025. The “we are getting ready” phase is therefore over, and supervisors now have their first data to work from.

Three events deserve attention:

• On 18 November 2025, the European Supervisory Authorities (EBA, EIOPA, ESMA) published the first list of critical ICT third-party providers (CTPPs). They assessed the provider's systemic importance, its role in supporting critical or important functions, and the degree to which its services can be substituted.
• On 2 March 2026, the deadline passed for Czech financial entities to submit their register of information to the ČNB in the second collection round; the first took place in 2025.
• On 3 June 2026, the ESAs' first annual report on major incidents was published: financial entities in the EU reported 3,383 of them for 2025; roughly a third originated in a third-party failure and approximately a third had a cross-border impact.

That last figure is key for this article. Dependence on suppliers is not a theoretical risk from a regulatory handbook – it is the origin of roughly one in three major incidents.

What Articles 28 to 30 actually say

The chapter on third-party risk has three articles that translate directly into architecture. The text of each paragraph is available on EUR-Lex, and in a clear article-by-article layout, for example, here.

Article 28: the register and exit strategies

• Paragraph 3 requires maintaining and updating a register of information on all contractual arrangements for the use of ICT services, at entity level as well as at sub-consolidated and consolidated levels. So it is not just about cloud, nor just about critical services.
• Paragraph 4 requires assessing, before a contract is concluded, whether the service supports a critical or important function, and evaluating the risks, including concentration risk.
• Paragraph 8 requires exit strategies for ICT services supporting critical or important functions. The entity must be able to leave the contractual relationship without disrupting its business, without limiting compliance with regulatory requirements, and without detriment to the continuity and quality of services to clients. Exit plans are to be comprehensive, documented, sufficiently tested and periodically reviewed; the entity must identify alternative solutions and have a transition plan enabling it to move the service and data to another provider or back in-house.

Article 29: concentration risk

For critical or important functions, the entity must assess whether it is entering into a relationship with a provider that is not easily substitutable, and whether it has multiple contracts with the same provider or with closely connected providers. In doing so, it must weigh the benefits and costs of alternative solutions. The second paragraph targets subcontracting chains, particularly in third countries.

Article 30: mandatory contract content

Paragraph 2 applies to all ICT service contracts: a complete description of the services, the locations (regions or countries) where services are provided and data processed, and provisions on access to, recovery and return of data in an easily accessible format. For critical or important functions, paragraph 3 adds, among other things, the right to ongoing monitoring and audit, the supplier's obligation to participate in TLPT, and exit strategies with a mandatory adequate transition period.

Critical providers: what the list changes and what it does not

There are 19 providers on the list. From a cloud and infrastructure perspective, they are Amazon Web Services EMEA, Microsoft Ireland Operations, Google Cloud EMEA, Oracle Nederland, IBM, SAP, Deutsche Telekom, Orange, Colt, Equinix and InterXion; then the integrators and outsourcing firms Accenture, Capgemini, Kyndryl, NTT DATA and Tata Consultancy Services; and the financial data and software providers Bloomberg, LSEG Data and Risk and FIS.

Designation means direct ESA oversight of the provider. If imposed measures are not complied with, the Lead Overseer can impose periodic penalty payments of up to 1% of average daily worldwide turnover, daily, for a maximum of six months (Article 35(6)–(8)).

For a financial entity, two consequences matter.

• The obligations under Articles 28–30 do not change. They apply regardless of whether the supplier is on the list. According to a Morgan Lewis commentary, providers may argue in negotiations that direct oversight in itself gives customers a certain degree of assurance. However, Article 28(1)(a) states that the financial entity always remains fully responsible for compliance with all obligations under the regulation, and the cited PwC Legal summary says the same for providers under direct ESA oversight.
• An exit may be imposed from outside. Under Article 42(6), the competent authority may, as a last resort, require financial entities to temporarily suspend the use of a critical provider's service, or to terminate the contract in whole or in part. It is an extreme scenario, but it is precisely what the exit plan exists for.

The register of information as a dependency inventory

In the Czech Republic, the register is submitted through the SDAT system. The ČNB states that the reports are generated automatically for reporting entities and can be delivered as an XBRL-CSV file, imported from an Excel template or filled in via a form; the entity must have, and state, its own LEI code. Credit institutions, insurers and reinsurers submit their reports at the highest level of consolidation within the EU. The templates are set by Implementing Regulation (EU) 2024/2956, whose mandatory service categories Czech practitioners also point out.

The typical problem is not the format but the data source. A register filled in once a year from contract records drifts away from what is actually running. Yet the platform team already has most of the inputs: the list of cloud accounts and subscriptions, regions, managed services in use, SaaS integrations in the pipeline.

The practical solution is to keep a dependency inventory alongside the code and derive the register from it. The structure can be simple:

service: payment-gateway
function_critical: true          # critical or important function
owner: team-payments
dependencies:
  - provider: Microsoft Ireland Operations Limited
    contract_ref: SML-2024-017
    services: [AKS, Azure SQL Managed Instance, Key Vault]
    regions: [westeurope, northeurope]
    data: [personal-data, transactions]
    substitutability: medium     # low / medium / high
    exit_plan: docs/exit/payment-gateway.md
    exit_last_tested: 2026-05-14
  - provider: saas-monitoring-vendor
    contract_ref: SML-2025-003
    services: [metrics, alerting]
    subcontractors: [AWS eu-central-1]
    substitutability: high

The subcontractors field is not superfluous. Delegated Regulation (EU) 2025/532 on subcontracting, published on 2 July 2025 and applicable since 22 July 2025, requires the contract to explicitly specify which services may be subcontracted, and the financial entity to be informed in advance of material changes in the chain, with the right to object or terminate the contract. A SaaS tool that itself runs on a hyperscaler thus also enters the concentration assessment.

An exit plan that passes the test

The regulation does not say what the test should look like. A reasonable reading is that “sufficiently tested” means demonstrable evidence that the key transition steps work, not a full dry-run migration every year. Where supervisors will set the bar remains to be seen; it is safer to have more than a tabletop exercise.

Portability: where it ends and what it costs

Containers and Kubernetes move the compute layer reasonably well. What surrounds it is harder to move: IAM, networking, managed databases, queues, serverless functions and observability. Terraform or OpenTofu do not by themselves guarantee portability, because modules are written against a specific provider. But they do guarantee something else that is essential for an exit: a complete, readable description of what needs to be built elsewhere. For the discipline around infrastructure as code, see IaC security.

A realistic approach is to split the components of a critical function into three groups: portable as-is (containerized applications), portable with a substitute (managed PostgreSQL for another PostgreSQL service), and not portable without a rewrite (proprietary services). For the third group, the exit plan should contain an honest effort estimate, not a claim that it will work out.

Backups outside the provider

Article 12 requires backup policies, recovery procedures and their regular testing; when restoring data using their own systems, entities must use systems that are physically and logically segregated from the source system. The regulation contains no explicit obligation to keep backups with a different provider. For an exit, however, a copy outside the provider's account and control plane is the only way to have the data available in a scenario where the service is unavailable or suspended.

Three things determine whether such a backup is usable: a format readable without the provider's service (a logical dump, Parquet – not just a snapshot), encryption keys under your own control, and a restore actually tried in the target environment, with the time measured.

TLPT and the supply chain

Threat-led penetration testing does not apply to everyone. Article 26 imposes it on selected entities at least every three years, on live production systems, covering several or all critical functions, including those provided by a supplier. Responsibility stays with the financial entity. If the provider's participation would endanger its other customers, paragraph 4 allows pooled testing for multiple entities.

The ČNB joined the TIBER-EU framework in September 2024 and in March 2025 approved the TIBER-EU Implementation Guide for the Czech financial market (TIBER-CZ). According to the ČNB, TLPT applies to the most significant financial institutions.

What this means for IT suppliers

• Expect customers to want elements from Article 30 in the contract: processing locations, audit rights, cooperation during incidents, data return and a transition period.
• Have a list of your own subcontractors ready, and a process for announcing changes in advance.
• Describe how a customer gets their data and configuration in machine-readable form. Those who can demonstrate it have a shorter sales cycle.
• If you support a critical function, clarify the terms of participating in TLPT in advance: scope, windows, isolation of other customers.

When the recommendations do not apply, and what to do now

DORA does not mandate multi-cloud. Article 29 calls for a concentration assessment and a weighing of the benefits and costs of alternatives, not for running in two clouds. Active multi-cloud doubles the operational know-how needed, enlarges the attack surface and, for a small team, can actually reduce resilience. A documented, defensible decision to stay with a single provider with a tested exit is a legitimate outcome.

Likewise, it is not true that managed services must be avoided. Running your own database for the sake of portability shifts risk from the supplier to your own people. It makes sense to demand portability where it is cheap (containers, open protocols and formats), and elsewhere to accept the dependency consciously and write down the cost of exit.

And the exit strategy under Article 28(8) applies to critical or important functions. An internal wiki does not need the same plan as a payment gateway; the register of information, however, covers both.

The last point relates to how operational oversight is built; on that, see security monitoring and logging.

Key takeaways

• The exit plan must be tested. Article 28(8) wants plans that are comprehensive, documented, sufficiently tested and periodically reviewed; a contract clause is not enough.
• The list of 19 critical providers makes nothing easier. ESA oversight of AWS, Microsoft or Google Cloud does not replace the financial entity's obligations, and Article 42(6) even allows an ordered suspension of the service.
• The register of information should come from an inventory, not from memory. Dependencies kept alongside the code keep the register current between the annual collections too.
• Subcontractors count. Regulation (EU) 2025/532 has applied since 22 July 2025, and the subcontracting chain enters the concentration assessment.
• Multi-cloud is not mandatory. Article 29 requires an assessment and a weighing of costs and benefits; a defensible decision for a single provider is fine.
• Third parties are a real source of incidents. Roughly a third of the 3,383 major incidents reported for 2025 originated with a third party.