Prepare a cloud exit strategy that satisfies DORA

What DORA requires for a cloud exit

DORA requires an EU financial entity to have an exit strategy for every ICT service that supports a critical or important function. Cloud services count as ICT services like any other. Article 28(8) sets the outcome: the entity must be able to leave the contract without disrupting its business, without limiting its compliance with regulatory requirements and without harming the continuity and quality of its services to clients. The exit plans behind that strategy must be comprehensive, documented, sufficiently tested and reviewed periodically. The entity must also identify alternative solutions and develop transition plans that remove the contracted services and the relevant data from the provider and transfer them securely and integrally to another provider or back in-house. ^[1]

For engineering teams, that sentence comes down to three pieces of evidence. The first is a dependency inventory that says what would have to move. The second is a data portability record that says how the data leaves and how long that takes. The third is a set of test results showing that the plan works at the scale it claims. A policy that names an alternative provider without these is weak evidence, because Article 10 of Delegated Regulation (EU) 2024/1773 requires the exit plan to be realistic, feasible, based on plausible scenarios and reasonable assumptions, and to have an implementation schedule that fits the exit and termination terms in the contract. ^[2]

The list of triggers sets the scope. Article 28(8) asks the strategy to cover provider failure, a decline in the quality of the service, business disruption from inappropriate or failed provision, material risk to the continued deployment of the service, and termination in any of the circumstances in Article 28(7). Those circumstances include a significant breach by the provider, weaknesses in its ICT risk management, monitoring findings that could change how the function performs, and the competent authority no longer being able to supervise the entity effectively because of the arrangement. ^[1] The delegated regulation reduces the planning scenarios to three: unforeseen and persistent service interruptions, inappropriate or failed service delivery, and unexpected termination of the contract. ^[2]

The contract supplies the rest. For critical or important functions, Article 30(3)(f) requires the contract to cover exit strategies, in particular a mandatory adequate transition period. During that period the provider keeps delivering the service while the entity migrates to another provider or to an in-house solution, on a timescale that suits the complexity of the service. Article 30(2)(d) requires the contract to provide for access to, recovery of and return of data in an easily accessible format if the provider becomes insolvent, is resolved or stops operating, or if the contract ends. Article 30(2)(h) requires termination rights and minimum notice periods. ^[1]

Dates and supervisory activity

DORA was published in the Official Journal on December 27, 2022 and has applied since January 17, 2025. ^[1] The technical standards that matter most for exit work came later. Delegated Regulation 2024/1773, on the policy for contractual arrangements, was published on June 25, 2024 ^[2]. Delegated Regulation 2024/1774, on the ICT risk management framework, was published the same day ^[4]. Implementing Regulation 2024/2956, which sets the templates for the register of information, followed on December 2, 2024 ^[3], and Delegated Regulation 2025/532, on subcontracting, on July 2, 2025. ^[5]

Registers go up the chain every year. Under the ESAs' decision on reporting for the designation of critical providers, competent authorities send the ESAs registers with a reference date of December 31 of the previous year, and must do so by March 31. The first round used a reference date of March 31, 2025, with registers due at the ESAs by April 30, 2025. ^[8] National authorities set earlier deadlines for the firms they supervise, so each firm's deadline comes from its own supervisor, not from the ESA decision. The ESAs used those registers to assess providers. They planned to notify the providers assessed as critical by July 2025, with a six-week window for objections. ^[9]

On November 18, 2025 the ESAs published the first list of designated critical ICT third-party service providers. ^[6] The list has 19 entries. Among them are Amazon Web Services EMEA Sarl, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited, Oracle Nederland B.V., IBM, SAP SE, Equinix and InterXion, along with consultancies, telecom operators and market data firms. ^[7] Article 31(9) requires the ESAs to update the list every year. ^[1] On October 8, 2026, the ESAs' oversight page still linked to the November 2025 list. ^[10]

Designation changes who examines the provider. It does not change who is answerable for the exit. For each designated provider, a Lead Overseer runs the examinations, supported by a joint examination team of ESA and national authority staff. The ESAs describe this oversight as complementing, not replacing, the financial entities' own responsibility for ICT risk. ^[10] Article 28(1)(a) also keeps the financial entity fully responsible for compliance at all times. ^[1] A provider's place on the list means its resilience will get more scrutiny. It does not substitute for the entity's own exit plan.

Source. EUR-Lex texts of Regulation (EU) 2022/2554, the cited delegated and implementing regulations and Regulation (EU) 2023/2854; ESAs designation press release, list and reporting decision. ^{[1][2][3][4][5][6][7][8][12]}

Method. Dates copied from Official Journal headers, application articles and ESA documents. The March 31, 2026 date applies the ESA decision's annual rule (by March 31, reference date December 31 of the prior year). Entity deadlines set by national authorities are earlier and are not shown. Ordinal layout; spacing does not represent elapsed time.

Accessible table and figure data

Figure 1 accessible table

Date	Milestone
December 27, 2022	DORA published in the Official Journal
June 25, 2024	RTS 2024/1773 and 2024/1774 published
December 2, 2024	Register of information ITS 2024/2956 published
January 17, 2025	DORA applies
April 30, 2025	First registers due at ESAs, reference date March 31, 2025
July 2, 2025	Subcontracting RTS 2025/532 published
September 12, 2025	Data Act applies, including cloud switching rules
November 18, 2025	ESAs publish first list of 19 critical providers
March 31, 2026	Registers due at ESAs, reference date December 31, 2025
January 12, 2027	Data Act switching charges prohibited

Figure 1 accessible table

Date	Milestone
December 27, 2022	DORA published in the Official Journal
June 25, 2024	RTS 2024/1773 and 2024/1774 published
December 2, 2024	Register of information ITS 2024/2956 published
January 17, 2025	DORA applies
April 30, 2025	First registers due at ESAs, reference date March 31, 2025
July 2, 2025	Subcontracting RTS 2025/532 published
September 12, 2025	Data Act applies, including cloud switching rules
November 18, 2025	ESAs publish first list of 19 critical providers
March 31, 2026	Registers due at ESAs, reference date December 31, 2025
January 12, 2027	Data Act switching charges prohibited

Download imageDownload table CSV

What the register of information already says about your exit

Article 28(3) requires a register of information that covers every contractual arrangement for ICT services and separates those that support critical or important functions from those that do not. It is kept at entity, sub-consolidated and consolidated level and must be made available to the competent authority on request. ^[1] Implementing Regulation 2024/2956 sets the templates. Its Annex III gives cloud three service types of its own: S17 for IaaS, S18 for PaaS and S19 for SaaS. Its Article 3 requires the register to include every subcontractor that effectively underpins a service supporting a critical or important function. ^[3]

Two fields need particular care. B_07.01.0080 is a plain Yes or No, so a vague plan can still be reported as Yes. The register will not show the difference, but an inspection will. B_07.01.0110 lists 'Assessment not performed' as an allowed answer, yet the instructions say an assessment to identify an alternative provider shall be performed for every provider that supports a critical or important function. ^[3] Consider a register that shows a 90-day notice period for the provider in B_02.02.0110 while the plan estimates five months to move the data. The register already contains the contradiction.

The function's recovery time and recovery point objectives in B_06.01 are reported in hours. Where an objective is under one hour, the register records 1. ^[3] Those values should come from the same exercise that sets recovery objectives for the service, not from a separate spreadsheet kept for reporting.

Several fields in the register amount to a summary of the exit plan, and the table lists them with what each one implies. Engineering owners should check these fields for their own services before a supervisor does, because each one asserts something that the plan and its tests must back up.

Map what actually has to leave

Exit plans are written for each contractual arrangement and each ICT service, so the first engineering task is to draw the boundary of the service being exited. ^[2][3] On a cloud platform, that boundary rarely stops at one account. Take a hypothetical payment reconciliation service. It runs on the provider's managed Kubernetes, with a managed PostgreSQL database, object storage for statement files, a managed message queue and the provider's key management service, and it is deployed by a pipeline that relies on the provider's identity federation. Only the containers come close to being portable. Every other component is a managed service with its own export path, and some hold state the application cannot rebuild.

Record four things for each component: the data it holds and the formats it can be exported in, the provider-specific APIs the code calls, the identity and key material it depends on, and the operational tooling that would also need replacing. The ECB's cloud guide gives virtual machines and container-based applications as examples of portable IaaS technology, and says the portability of PaaS and SaaS depends on the specific solution. ^[11] That gives a reasonable way to rank components by how hard they are to exit.

Exit plans tend to fail quietly at shared dependencies. Key management is the clearest example. If data at rest is encrypted under keys that cannot leave the provider, the export path has to decrypt the data inside the provider and re-encrypt it on the target, and that path has to be designed and tested. Identity, DNS, certificate issuance and the deployment pipeline are the other usual suspects. Give each one a place in the plan as a dependency with its own replacement step. The categories below cover most cloud estates.

• Data stores: databases, object storage, queues that retain messages, search indexes, and the formats each can be exported in.
• Keys and secrets: provider key management, certificate authorities, secret stores, and who is allowed to export which material.
• Identity: workload federation, human administrator access and break-glass accounts on the target platform.
• Network and naming: DNS zones, private connectivity, and IP allow lists held by counterparties and payment schemes.
• Operations: retention of logs and audit records, monitoring, backups and the deployment pipeline.

Write an exit plan engineers can run

The delegated regulation asks for a realistic, feasible plan with an implementation schedule. ^[2] The ECB's cloud guide spells out what it treats as good practice. An exit plan should include, at a minimum, the critical milestones, the tasks and skill sets needed to carry out the exit, and a rough estimate of the time and cost involved. Exit strategies, with clearly defined roles and estimated costs, should be drawn up before the systems go live. ^[11] The guide also separates two time horizons: business continuity measures keep the service running in the short term, and the exit plan secures continuity in the long term. ^[11]

That distinction points to writing two versions of the plan. A planned exit runs within the contractual transition period, while the provider is still delivering the service and helping with the move. A stressed exit begins with a provider failure or an abrupt termination. In that case the transition period may not hold in practice, and the first days depend on the contingency measures that Article 28(8) requires as a separate obligation. ^[1] The stressed version needs a copy of the critical data outside the provider before anything goes wrong, because a provider that has stopped operating cannot export anything.

Keep the plan as a structured record next to the service's code or runbooks. That way, changes to the architecture show up as changes to the plan. The fragment below shows one possible layout. It is not a regulatory template, and the field names are illustrative. In this hypothetical record, the 120-day estimate already exceeds the provider's 90-day notice period. That is exactly the kind of gap the plan has to close, for example by negotiating a longer transition period or by removing the slowest dependency.

Two fields do most of the work. readiness stops a plan from implying that an alternative is ready when only a design exists. measured_export_hours forces the estimate to come from a test rather than an assumption. Where a value is unknown, leave it empty and visible instead of filling in a guess.

# Example exit plan record (illustrative, not a regulatory template)
service: payment-reconciliation
contract_ref: CTR-0001
register:
  ict_service_type: S18            # Cloud services: PaaS (ITS Annex III)
  provider_notice_period_days: 90  # must match B_02.02.0110
  exit_plan_exists: true           # reported in B_07.01.0080
scenarios:
  - persistent-service-interruption
  - failed-service-delivery
  - unexpected-termination
target:
  type: alternative-provider       # or in-house
  readiness: design-only           # design-only | environment-built | rehearsed
components:
  - name: ledger-db
    kind: managed-postgresql
    export: logical dump plus WAL archive copied outside the provider
    volume_gb: 1800
    measured_export_hours: null    # fill in from the last test
  - name: statement-files
    kind: object-storage
    export: bulk copy with per-object checksums
    volume_gb: 42000
  - name: data-keys
    kind: provider-kms
    export: not exportable; decrypt and re-encrypt during copy
milestones:
  - id: M1
    task: freeze schema changes and start bulk copy
    owner_role: platform-lead
  - id: M2
    task: verify row counts and checksums on the target
    owner_role: data-engineering
  - id: M3
    task: cut over writes and switch DNS
    owner_role: sre-on-call
estimates:
  duration_days: 120
  cost_eur: null                   # finance estimate, reviewed yearly
last_test:
  date: null
  type: desktop-review
  independent_reviewer: null

Data portability you can measure

The phrase 'securely and integrally' in Article 28(8) describes something you can test. ^[1] Integrity means the target holds the same records as the source at a defined point in time. That is checked with row counts per table, checksums per object, and reconciliation of business totals such as ledger balances. Security means the data stays encrypted in transit and only the exit team has access during the copy. Build both into the export tooling, because doing them by hand does not scale to hundreds of terabytes.

Duration is arithmetic before it is engineering. Copying a hypothetical 400 TB estate over a sustained 10 Gbit/s link takes about 320,000 seconds of transfer, a little under four days. That figure is 400 TB times 8 bits per byte divided by 10 Gbit/s, before throttling, API rate limits, retries or verification passes. Real exports run below line rate, so the plan should use throughput measured during a test copy. The ECB recommends reviewing the volume of data and the complexity of the applications, and taking the transfer method into account, so that time estimates mean something. ^[11]

The EU Data Act now gives cloud customers contractual switching terms that help with this. For contracts in scope, the customer can start a switch after a notice period of at most two months. The provider must then complete the switch within a transitional period of 30 calendar days, which can run to at most seven months if the provider justifies that 30 days is technically unfeasible. The provider must also support the customer's exit strategy with relevant information and keep the data retrievable for at least 30 days afterwards. ^[12] Until January 12, 2027, switching charges may not exceed the provider's costs directly linked to the switch, and from that date they are prohibited. ^[12] The Data Act as a whole has applied since September 12, 2025. ^[12] Check with your legal team which of your existing cloud contracts already include these clauses.

Treat these terms as a minimum, not as the plan. A 30-day transitional period is shorter than most migrations of a core banking or payments platform. The Commission's November 2025 Digital Omnibus proposal would also change parts of the switching rules for heavily customised services and for services from SMEs and small mid-caps. ^[13] Check the current text before building a specific Data Act term into an exit schedule.

Test the exit in stages

DORA requires exit plans to be sufficiently tested, in line with the proportionality criteria in Article 4(2), and to be reviewed periodically. ^[1] It does not require a full production migration as the test. The ECB's guide describes a graduated approach. At a minimum, staff with enough cloud expertise carry out an in-depth desktop review. A walkthrough then confirms that the available staff can perform the tasks. The most critical migration steps are tested periodically, and someone who did not write the plan verifies that it is feasible. ^[11]

Business continuity testing overlaps with exit testing, but the two are different exercises. Article 11(6) requires ICT business continuity plans and response and recovery plans to be tested at least once a year. ^[1] Delegated Regulation 2024/1774 requires that testing to include ICT services from third-party providers where applicable, giving due consideration to scenarios such as the provider's insolvency or failure, or political risk in its jurisdiction. ^[4] A continuity test shows that the function survives a provider outage for a while. An exit test shows that the function can run somewhere else for good.

A practical sequence moves from paper, to data, to traffic. Each stage produces a dated record, and each can fail without harming production. The figure sets out one such sequence. The last stage, moving a non-critical slice of traffic, is optional and makes sense only where the target environment already exists.

Time each technical step and write the measured figure back into the plan. A test that ends with 'export completed' is weaker evidence than a record, here hypothetical, showing that 1.8 TB was exported in 9 hours 40 minutes with zero checksum mismatches and that the restored application passed its reconciliation checks. Hold the restored service to the same acceptance criteria as a recovery exercise, including its dependencies and a defined finish line.

Source. Conceptual sequence based on DORA Article 28(8), Delegated Regulation (EU) 2024/1774 Article 25 and the ECB cloud outsourcing guide, section 2.4.3. ^[1][4][11]

Method. Conceptual ordering of the testing practices described in the cited texts. Neither DORA nor the ECB guide prescribes this exact sequence, and the optional last stage goes beyond what they describe.

Accessible table and figure data

Figure 2 accessible table

Stage	What happens	Evidence
Desktop review	Reviewers with cloud skills check scenarios, dependencies and estimates	Review record listing gaps and owners
Task walkthrough	Named staff walk through each milestone and confirm skills	Staffing check, with any external help identified
Data export test	Export a representative data set by the planned method	Measured throughput, checksums and row counts
Restore on the target	Load the export into the alternative provider or in-house target	Restore duration and any failed steps
Application acceptance	Run reconciliation and functional checks on the target	Pass or fail against acceptance criteria
Independent verification	Someone who did not write the plan assesses its feasibility	Signed verification and plan updates
Optional slice cutover	Move a non-critical slice of traffic or tenants	Cutover log and rollback result

Figure 2 accessible table

Stage	What happens	Evidence
Desktop review	Reviewers with cloud skills check scenarios, dependencies and estimates	Review record listing gaps and owners
Task walkthrough	Named staff walk through each milestone and confirm skills	Staffing check, with any external help identified
Data export test	Export a representative data set by the planned method	Measured throughput, checksums and row counts
Restore on the target	Load the export into the alternative provider or in-house target	Restore duration and any failed steps
Application acceptance	Run reconciliation and functional checks on the target	Pass or fail against acceptance criteria
Independent verification	Someone who did not write the plan assesses its feasibility	Signed verification and plan updates
Optional slice cutover	Move a non-critical slice of traffic or tenants	Cutover log and rollback result

Download imageDownload table CSV

Concentration and substitution

Before signing, Article 29 asks the entity to consider two things about a new arrangement for a critical or important function. The first is whether it means contracting a provider that is not easily substitutable. The second is whether it means holding several such arrangements with the same provider or with closely connected providers. The entity must weigh the benefits and costs of alternative solutions. ^[1] If the provider is in a third country or subcontracts, the entity must also consider which insolvency law applies, any constraint on urgently recovering its data, and how long subcontracting chains affect its ability to monitor the function. ^[1]

None of this requires running every workload on two clouds. Article 6(9) says an entity may define a multi-vendor strategy, and Article 28(8) accepts bringing services back in-house as an alternative to another provider. ^[1] What the regulation does require is an honest assessment of substitutability. B_07.01.0050 has four values, from 'not substitutable' to 'easily substitutable'. The two hardest values require a reason, taken from the same criteria the ESAs use for designation: a lack of real alternatives, or difficulty migrating data and workloads. ^[3]

Concentration also hides in the supply chain. A SaaS vendor hosted on the same hyperscaler as your core platform adds a second arrangement that depends on that one provider, and the register's B_05.02 template exists to make that visible. ^[3] Under Delegated Regulation 2025/532, the entity may write termination rights into the contract for three cases: the provider makes material subcontracting changes over the entity's objection, makes them before the notice period ends without approval, or subcontracts a service supporting a critical or important function without permission. ^[5] These are exit triggers in their own right, and the exit plan should name them.

Evidence to keep, and what to do first

Supervisors see the exit position first through the register and then through documents. The matrix maps each requirement to the engineering record that supports it. The right-hand column lists the records worth keeping in version control, each with a date and an owner.

For a team starting now, this order of work produces evidence fastest. First, confirm which services support critical or important functions and which contract each one sits under. Second, build the dependency inventory for those services. Third, run a desktop review of the existing plan against that inventory. Fourth, measure one real export and restore for the largest data store. Finally, reconcile the register fields, the notice periods and the plan's estimates so that they agree. Repeat the measurement whenever the architecture changes materially, and at least on the review cycle your policy sets. Delegated Regulation 2024/1773 requires the management body to review that policy at least once a year. ^[2]

The decision rule follows from this. If the plan's measured exit duration does not fit inside the contractual transition period, or a critical data store has no tested export path outside the provider, this guide reads the plan as not yet realistic and feasible in the sense of Article 10 of Delegated Regulation 2024/1773, whatever the register says. ^[2] Change the contract, the architecture or the estimate until all three agree.

Source. Conceptual mapping. Requirements paraphrased from Regulation (EU) 2022/2554, Delegated Regulation (EU) 2024/1773 and Implementing Regulation (EU) 2024/2956. ^[1][2][3]

Method. Conceptual: the requirement and source columns paraphrase the cited articles. The evidence column is this guide's suggestion, not a regulatory list.

Accessible table and figure data

Figure 3 accessible table

Requirement	Source	Engineering evidence
Exit strategy for critical or important functions	DORA Art. 28(8)	Service list mapped to functions and owners
Documented exit plan per arrangement	RTS 2024/1773 Art. 10	Versioned plan record for each service
Realistic plan, schedule fits contract terms	RTS 2024/1773 Art. 10	Measured estimates compared with notice periods
Plans sufficiently tested and reviewed	DORA Art. 28(8)	Dated test reports with measured results
Secure and complete transfer of services and data	DORA Art. 28(8)	Export tooling, checksums and reconciliation
Alternative solutions identified	DORA Art. 28(8), ITS B_07.01	Reviewed alternatives list or in-house design
Transition period in the contract	DORA Art. 30(3)(f)	Contract clause matched to plan duration
Data returned in an accessible format	DORA Art. 30(2)(d)	Export format list for each data store
Accurate register entries	ITS 2024/2956 Art. 3	Register fields reconciled with the plan

Figure 3 accessible table

Requirement	Source	Engineering evidence
Exit strategy for critical or important functions	DORA Art. 28(8)	Service list mapped to functions and owners
Documented exit plan per arrangement	RTS 2024/1773 Art. 10	Versioned plan record for each service
Realistic plan, schedule fits contract terms	RTS 2024/1773 Art. 10	Measured estimates compared with notice periods
Plans sufficiently tested and reviewed	DORA Art. 28(8)	Dated test reports with measured results
Secure and complete transfer of services and data	DORA Art. 28(8)	Export tooling, checksums and reconciliation
Alternative solutions identified	DORA Art. 28(8), ITS B_07.01	Reviewed alternatives list or in-house design
Transition period in the contract	DORA Art. 30(3)(f)	Contract clause matched to plan duration
Data returned in an accessible format	DORA Art. 30(2)(d)	Export format list for each data store
Accurate register entries	ITS 2024/2956 Art. 3	Register fields reconciled with the plan

Download imageDownload table CSV