Cloud exit plan — DORA Article 28 meets the EU Data Act

Use this playbook when you must be able to leave a data processing service — IaaS, PaaS, or SaaS — that supports a critical or important function, and the exit has to satisfy two regimes at once: your DORA Article 28(8) exit-strategy obligation as a financial entity, and your switching rights as a customer under Chapter VI of the EU Data Act (Regulation (EU) 2023/2854).

Fire it when you are drafting or reviewing a cloud contract; when a supervisor asks for evidence that your exit strategy is executable; when a concentration-risk assessment flags a provider you cannot currently leave; or when a provider gives notice of a material change, price increase, or service withdrawal and you must decide whether to switch.

Out of scope: switching a service that supports no critical or important function (the DORA testing bar does not apply, though the Data Act rights still do); intra-group migrations that are not a change of provider; and emergency exit driven by a live security incident — that is an incident-response decision, run it through your third-party breach notification playbook first, then use this one for the orderly migration that follows.

The two regimes are not alternatives; they bite on the same exit plan from opposite ends.

DORA Article 28(8) is the obligation. As a financial entity you must put in place — and periodically test and review — exit strategies for ICT services supporting critical or important functions. The strategy has to identify alternative solutions, develop a transition plan that lets you remove the service and your data and move to another provider or back in-house, and keep contingency measures for business continuity, all without disrupting the service to your own clients or breaching your own regulatory duties. See Regulation (EU) 2022/2554.

Data Act Chapter VI is the leverage. It gives you, as the customer, enforceable contractual and technical switching rights that make the DORA transition plan executable rather than aspirational: a capped notice period, a bounded porting window, mandatory provider assistance, an exhaustive list of portable data and digital assets, and — from 2027 — no switching fee. The European Commission Data Act policy pages track the model contractual terms that operationalise these rights.

The practical consequence: audit your exit plan against the Data Act clauses your contract must now contain. A plan that assumes a six-month, high-fee, best-efforts migration is out of date — the Data Act floor is faster, cheaper, and enforceable, and your supervisor will expect the plan to reflect it.

Map each deadline, because the transition plan DORA asks for is only credible if it is built on the real numbers.

• Notice period to start switching: maximum 2 months. Your contract cannot make you wait longer to initiate the switch (Article 25).
• Transitional (porting) period: maximum 30 calendar days from the expiry of the notice period, during which the provider must transfer all exportable data and digital assets.
• Technical-impossibility escape valve: if the 30-day port is technically unfeasible, the provider must notify you within 14 working days of the switching request, explain why, and propose an alternative period that may not exceed 7 months. Treat any invocation of this clause as a concentration-risk finding, not a routine variation.
• Switching charges: gone from 12 January 2027 (Article 29). Between now and then a provider may bill only the costs directly incurred for the switch, including data egress; after that date, standard switching charges are prohibited. Early-termination penalties agreed before that date survive.
• Applicability: the Data Act switching obligations have applied since 12 September 2025, so any contract signed or renewed after that date should already carry compliant clauses.

Write these numbers into the transition plan as hard planning assumptions. If your documented recovery-time expectation for leaving a critical provider is longer than notice-plus-port, the gap is either a contract defect you must fix or a residual risk you must record and have the management body accept.

Exit readiness is built in procurement and contract review, not during the switch. Work this checklist for every provider that supports a critical or important function:

• Map the dependency. Record which critical or important function each service supports, the data categories it holds, and the downstream services that would break if it stopped. This is the register DORA expects you to keep current.
• Cross-walk the contract clause by clause against Data Act Article 25: switch authorisation, the exhaustive list of portable data and digital assets, notice period, the 30-day port window, assistance duties, export formats, and end-of-process erasure. Flag every clause that is missing, weaker than the Data Act floor, or silent.
• Name the destination. An exit strategy with no identified alternative provider or in-house target is not a strategy. Record at least one credible destination per critical service and the export format it can ingest.
• Confirm functional-equivalence scope. For IaaS the provider must take reasonable measures to help you reach functional equivalence after a same-service-type switch. For PaaS and SaaS you own the re-architecture — plan the format conversions and the re-integration work explicitly.
• Dry-run the port. Extract a representative data set in the contracted export format and re-import it to the named destination. A port that has never been executed is an assumption, not a capability.

Close Phase A only when every critical provider has a named destination, a clause cross-walk with no unresolved gaps, and at least one tested export.

When a real exit is triggered — provider withdrawal, price shock, concentration-risk decision, or supervisory pressure — run the migration on the clock you mapped in Phase A.

1. Issue the switch notice in writing and start the clock. The notice period runs to a maximum of 2 months; do not let internal indecision consume it.
2. Invoke the porting obligation. Require the provider to transfer all exportable data and digital assets within the 30-day transitional window. Hold them to the exhaustive asset list in the contract — undocumented assets are the ones that get left behind.
3. Track the impossibility clause. If the provider claims the 30-day port is unfeasible, demand the 14-working-day written explanation and the alternative period, and escalate anything approaching the 7-month ceiling to the risk function.
4. Stand up the destination in parallel, not after the port completes. Business continuity means the alternative is receiving and validating data while the source is still live.
5. Verify functional equivalence (IaaS) or completed re-integration (PaaS/SaaS) before you cut over. A cutover to an unvalidated destination is a self-inflicted operational incident.
6. Confirm erasure at the source. The Data Act entitles you to deletion of your data at the end of the switching process once portability is complete — get written confirmation and retain it as evidence.

Every step above produces an artefact. Capture them as you go; assembling the record after the migration is exactly the failure this playbook exists to prevent.

Have these ready, ordered by the gate that consumes them (supervisor review first, then audit, then the next test cycle):

• The register of critical/important-function ICT dependencies with each service exit destination and status.
• The clause cross-walk for each contract against Data Act Article 25, with gaps and their remediation or accepted-risk status.
• The transition plan per provider, stating notice-plus-port timing, assistance obligations, and the named destination.
• Dry-run evidence: dated export/import test results with the data volume, format, and elapsed time.
• Management-body acceptance records for any residual exit risk that exceeds your recovery-time expectation.
• Executed-switch artefacts when a real switch has occurred: notice, porting confirmation, functional-equivalence validation, erasure confirmation.

The recurring problem is that this evidence gets assembled once a year for a supervisor and is stale the day after. Keeping the dependency register and its exit-readiness status continuously current — mapped to the DORA and Data Act obligations each service carries — is exactly the standing-evidence job Zero Hunt Automatic Compliance is built to do, so the exit strategy is a live, attested record rather than a document reconstructed under deadline.

Patterns seen across peer financial entities:

• The supervisor-only plan. The exit strategy exists as a document written to pass an assessment and was never executed against the real contract. It fails at the first genuine port.
• The stale six-month assumption. The transition plan still assumes pre-Data-Act migration friction — long notice, high egress fees, best-efforts assistance — and understates how fast a switch can and must now happen.
• The undocumented asset. The port moves the obvious data and leaves behind configuration, keys, logs, and derived artefacts that were never in the portable-asset list, so the destination is subtly incomplete.
• PaaS/SaaS equivalence assumed. Teams expect the IaaS functional-equivalence duty to cover their managed-database or SaaS switch; it does not, and the re-architecture work surfaces mid-migration.
• Concentration risk hidden by a working contract. The clauses are compliant but every critical function sits with one provider, so an orderly exit is legally possible and operationally catastrophic. Record it as concentration risk, not as exit readiness.

The exit plan touches more than DORA and the Data Act:

• NIS2 supply-chain security (Article 21) expects essential and important entities to manage ICT third-party risk — the same dependency register and exit readiness feed that obligation.
• GDPR processor duties require deletion or return of personal data at the end of processing; align the Data Act erasure-at-end-of-switch step with your Article 28 GDPR processor obligations so one confirmation satisfies both.
• Concentration risk is a supervisory theme in its own right — a provider you cannot leave is a systemic dependency regardless of contract quality, and the exit test is the evidence that the dependency is survivable.

Build the artefact once and export the view each regime needs. Running separate exit, third-party-risk, and data-protection trails for the same providers multiplies work and guarantees they drift out of sync.