# Free DORA Exit Strategy Template (2026) — Art 28(8), Word

Article 28(8) exit strategy and per-provider exit plan: triggers, alternatives, transition, testing log. Free DOCX + PDF + MD, no email gate.


**Quick answer:** This free **DORA exit strategy template** is a downloadable DOCX (plus PDF guide and machine-readable Markdown) covering the two layers Article 28(8) of [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) requires for ICT services supporting critical or important functions: an entity-level **exit strategy** built on the five Article 28(8) risk scenarios, and a per-arrangement **exit plan** form — triggers, alternative solutions, transition plan, data portability, contingency measures, and the testing log that [RTS (EU) 2024/1773](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj) Article 10 makes mandatory. It distinguishes planned from stressed exits, records the Article 30(3)(f) contractual transition period per arrangement, and includes a fully completed fictional example.

Free exit-plan artifacts exist — NOREA (the Dutch IT-auditors' body) publishes one, and the checklist blogs are endless. What they share is the shape supervisors are already criticising: a document you fill once and file. Early ECB-led DORA inspections flagged **overly generic and untested exit strategies** as a recurring finding. This template is built around that failure mode: the testing log and review cadence are structural parts of the document, the plan fields force per-arrangement specificity (which alternative, which data format, which transition window), and the machine-readable Markdown variant lets an AI agent maintain the plans alongside your Register of Information.

---

## Key Takeaways

- **Two layers, per the regulation.** Article 28(8) requires the strategy; RTS (EU) 2024/1773 Article 10 requires **a documented exit plan for each contractual arrangement** supporting a critical or important function. The template ships both — one strategy document, one repeatable plan form.
- **The three protected outcomes.** Every exit must complete **without disruption to business activities, without limiting regulatory compliance, and without detriment to the continuity and quality of client services** — the plan form scores each phase against all three.
- **Testing is the compliance bar, not an extra.** Plans must be *realistic, feasible, based on plausible scenarios and reasonable assumptions*, and tested against **unforeseen and persistent service interruptions** (RTS Art 10). The built-in test log tracks scenario, type (tabletop / partial data extraction / full simulation), findings, and remediation.
- **Planned vs stressed exits.** DORA's Article 28(7) termination circumstances plus provider insolvency give you the stressed scenarios; commercial or strategic moves give you the planned ones. The form handles both — which also satisfies the UK's PRA SS2/21 stressed/non-stressed distinction in one document.
- **Anchored to the contract.** The Article 30(3)(f) **mandatory adequate transition period** is recorded per arrangement, and the plan's schedule is checked against it — an exit plan that doesn't fit its contractual transition window is fiction.

---

## What's Inside the Template

The DOCX contains four working parts plus a completed example; the PDF is a field guide; the MD variant carries the full structure with enums for agent workflows.

### 1. Entity-Level Exit Strategy

The policy layer: scope (which arrangements are in the critical/important perimeter, linked by contract reference to your Register of Information), governance and ownership, the five Article 28(8) risk scenarios spelled out —

| # | Scenario | Source |
|---|---|---|
| 1 | Failure of the ICT third-party provider | Art. 28(8) |
| 2 | Deterioration of the quality of the ICT services provided | Art. 28(8) |
| 3 | Business disruption due to inappropriate or failed provision | Art. 28(8) |
| 4 | Material risk to appropriate and continuous deployment of the service | Art. 28(8) |
| 5 | Termination under an Article 28(7) circumstance (breach, monitoring findings, evidenced ICT-risk weaknesses, supervisability) | Art. 28(7)–(8) |

— plus the three protected outcomes as strategy objectives and the alternatives-assessment method (substitutability, market alternatives, in-house option).

### 2. Per-Arrangement Exit Plan Form

One form per critical/important arrangement:

| Section | Fields |
|---|---|
| Identification | Contract ref (RoI key), provider, ICT service, critical/important function supported |
| Triggers | Planned exit reasons; stressed triggers mapped to Art. 28(7)(a)–(d) + insolvency |
| Alternatives | Alternative provider(s) assessed / in-house reincorporation option / substitutability rating |
| Transition plan | Phases, timeline, data-migration steps, data return format, secure-transfer method, verification of integrity, parallel-run window, rollback criteria |
| Contractual anchors | Art. 30(3)(f) transition period, termination notice periods, data-return and deletion clauses, transition assistance |
| Contingency | Interim measures keeping the function running mid-exit (Art. 28(8) final subparagraph) |
| Governance | Plan owner, decision-maker for activation, escalation path, cost and resourcing estimate |

### 3. Exit Plan Testing & Review Log

Date, arrangement tested, scenario (including the RTS-required unforeseen and persistent interruption cases), test type, participants, findings, remediation actions, next scheduled test, and last review date — the evidence trail inspectors ask for first.

### 4. Activation Runbook Skeleton

A short sequenced checklist for the day an exit actually triggers: declare, notify (internal, provider, competent authority where required), freeze scope changes, execute transition phases, verify data return and deletion, close out and update the Register of Information.

### 5. Completed Fictional Example

The example uses the same fictional universe as our other DORA templates — Nordbank SE exiting cloud provider "CloudCore GmbH" (contract CTR-2024-018) — so the exit plan, the [ICT provider evidence checklist](/templates/dora-ict-provider-evidence-checklist), and the [Register of Information starter](/templates/dora-register-of-information-starter) read as one coherent workflow.

---

## How to Use This Template

1. **Scope from the register.** Pull every arrangement flagged as supporting a critical or important function from your Register of Information — those contract references are your exit-plan worklist. One plan per arrangement (RTS Art 10), not one plan for everything.
2. **Write the strategy once.** Complete the entity-level strategy: scenarios, protected outcomes, alternatives-assessment method, governance.
3. **Complete a plan form per arrangement.** Be concrete: name the alternative provider, the data export format, the transition phases. "Migrate to a comparable provider" is exactly the generic language inspections flag.
4. **Check the plan against the contract.** The transition schedule must fit inside the Article 30(3)(f) transition period, and the data-return clauses must support your migration steps. Gaps here are contract-remediation items, not plan footnotes.
5. **Test, log, remediate.** Run at least a tabletop per arrangement on a risk-based cadence — and for the highest-criticality arrangements, test data extraction for real. Log everything in the test log.
6. **Review periodically.** Reassess when the provider, the service, the market alternatives, or the function's criticality changes — and at minimum on the review cadence your policy sets.

For collecting the *evidence* that feeds these plans — assurance reports, resilience test results, subcontracting chains — use the companion [DORA ICT provider evidence checklist](/templates/dora-ict-provider-evidence-checklist); to maintain the register the plans key into, use the [Register of Information starter](/templates/dora-register-of-information-starter).

---

## Legal Basis

- **Article 28(8), Regulation (EU) 2022/2554 (DORA)** — for ICT services supporting critical or important functions: exit strategies accounting for provider failure, service deterioration, business disruption, material deployment risks, and Article 28(7) termination; the ability to exit without business disruption, regulatory limitation, or client detriment; comprehensive, documented, sufficiently tested and periodically reviewed exit plans; identified alternative solutions and transition plans for the secure and integral transfer of services and data to alternative providers or in-house; and contingency measures for business continuity.
- **Article 28(7), Regulation (EU) 2022/2554** — the mandatory termination circumstances (significant breach; circumstances identified through monitoring capable of altering performance; evidenced weaknesses in the provider's ICT risk management; supervisability concerns) that the exit strategy must be executable against.
- **Article 30(3)(f), Regulation (EU) 2022/2554** — contracts for critical/important ICT services must include exit strategies, in particular a **mandatory adequate transition period** during which the provider continues delivering, allowing migration to another provider or in-house solutions consistent with the complexity of the service.
- **[Commission Delegated Regulation (EU) 2024/1773](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj), Article 10** (RTS on the ICT third-party policy) — the policy must require **a documented exit plan for each contractual arrangement** supporting critical or important functions, periodically reviewed and tested; plans must be realistic, feasible, based on plausible scenarios and reasonable assumptions, with a planned implementation schedule compatible with the contract's exit and termination terms, and testing that considers unforeseen and persistent service interruptions.

For the full regulatory picture, see our [DORA compliance guide](/eu-regulations/dora-compliance); for why Articles 19, 28 and 30 outgrow a traditional ISMS, see the [DORA Article 19, 28 and 30 analysis](/eu-regulations/incident-reporting-provider-monitoring-dora-article-19-28-30).

---

## UK, Norway, and the EEA

**UK:** DORA does not apply, but the exit obligation exists under a different name. [PRA SS2/21](https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/outsourcing-and-third-party-risk-management-ss) expects firms to **develop, maintain and test a documented exit strategy for each material outsourcing arrangement**, explicitly differentiating **stressed exits** (provider failure, insolvency) from **non-stressed** planned exits, with cost, resourcing and trigger analysis — tested on a risk-based approach alongside operational resilience scenario testing (SS1/21). The critical third parties regime under FSMA 2023 adds direct oversight of designated providers but removes none of the firm-level exit expectations. This template's planned/stressed trigger split maps directly onto SS2/21.

**Norway / EEA:** DORA applies via the EEA Agreement; Norway's **DORA Act has been in force since 1 July 2025** with **Finanstilsynet** as competent authority. The Norwegian implementation carries Article 28(8) over intact — exit strategies for critical/important arrangements, exit without harming continuity, client service or compliance, and plans that are comprehensive, well-documented, tested and regularly reviewed. Finanstilsynet has stated it expects exit plans to be **realistic and regularly tested**.

---

## The Supervisory Reality: Paper Plans Fail Inspections

The pattern from the first wave of DORA supervision is consistent. ECB-led inspections following the IT risk questionnaire flagged overly generic and untested exit strategies as a common finding. The DORA third-party-policy RTS requires exit plans to rest on **plausible scenarios and appropriate assumptions** and be **sufficiently tested**. Under the EBA's earlier cloud outsourcing reviews, the gap between having an exit strategy on paper and having ever tested a data extraction was already a top finding — DORA turns that gap into an Article 28(8) deficiency.

The operational answer is to stop treating exit plans as documents and start treating them as maintained records with test evidence. Orbiq's [Vendor Assurance Platform](/platform/vendor-assurance-platform) keeps provider records, exit-plan status, and evidence with expiry tracking in one governed workflow — built for European financial entities with EU data residency. The machine-readable Markdown variant of this template is available at [/downloads/templates/dora-exit-strategy-plan.md](/downloads/templates/dora-exit-strategy-plan.md) for AI-agent workflows.

---

## Sources & References

1. [Regulation (EU) 2022/2554 (DORA) — EUR-Lex](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) — Articles 28(7), 28(8), 30(3)(f)
2. [Commission Delegated Regulation (EU) 2024/1773 — EUR-Lex](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj) — RTS on the ICT third-party policy; Article 10 exit-plan, review and testing requirements
3. [KPMG ECB Office — Understanding the DORA risk questionnaire and first inspection findings](https://kpmg.com/xx/en/our-insights/ecb-office/kpmg-european-central-bank-office-fs/understanding-dora-risk-questionnaire.html) — generic and untested exit strategies among common JST findings
4. [PRA SS2/21 — Outsourcing and third party risk management](https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/outsourcing-and-third-party-risk-management-ss) — UK documented exit strategies; stressed vs non-stressed exits
5. [Finanstilsynet — Norwegian DORA Act in force 1 July 2025](https://www.finanstilsynet.no/nyhetsarkiv/nyheter/2025/ny-lov-om-digital-operasjonell-motstandsdyktighet-i-finanssektoren-dora-loven-trer-i-kraft-1.-juli) — Norway / EEA implementation, Finanstilsynet as competent authority
6. [NOREA — DORA exit plan template](https://www.norea.nl/dora/dora-template-exit-plan) — the existing free artifact this template extends (strategy + plan + test log + agent-readable variant)