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.
Download this template
Version 1.0 · Updated Jul 17, 2026 · Free, no email required
Free DORA Exit Strategy Template (2026) — Art 28(8), Word
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 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 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, and the Register of Information starter read as one coherent workflow.
How to Use This Template
- 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.
- Write the strategy once. Complete the entity-level strategy: scenarios, protected outcomes, alternatives-assessment method, governance.
- 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.
- 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.
- 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.
- 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; to maintain the register the plans key into, use the 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, 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; for why Articles 19, 28 and 30 outgrow a traditional ISMS, see the DORA Article 19, 28 and 30 analysis.
UK, Norway, and the EEA
UK: DORA does not apply, but the exit obligation exists under a different name. PRA SS2/21 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 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 for AI-agent workflows.
Sources & References
- Regulation (EU) 2022/2554 (DORA) — EUR-Lex — Articles 28(7), 28(8), 30(3)(f)
- Commission Delegated Regulation (EU) 2024/1773 — EUR-Lex — RTS on the ICT third-party policy; Article 10 exit-plan, review and testing requirements
- KPMG ECB Office — Understanding the DORA risk questionnaire and first inspection findings — generic and untested exit strategies among common JST findings
- PRA SS2/21 — Outsourcing and third party risk management — UK documented exit strategies; stressed vs non-stressed exits
- Finanstilsynet — Norwegian DORA Act in force 1 July 2025 — Norway / EEA implementation, Finanstilsynet as competent authority
- NOREA — DORA exit plan template — the existing free artifact this template extends (strategy + plan + test log + agent-readable variant)
Download this template
Version 1.0 · Updated Jul 17, 2026 · Free, no email required
Frequently Asked Questions
What must a DORA exit strategy include under Article 28(8)?
For ICT services supporting critical or important functions, Article 28(8) requires exit strategies that account for provider failure, deterioration of service quality, business disruption from failed provision, material risks to continuous deployment, and termination under any of the Article 28(7) circumstances. The entity must be able to exit without disrupting business activities, limiting regulatory compliance, or harming the continuity and quality of client services. Exit plans must be comprehensive, documented, sufficiently tested, and reviewed periodically, and the entity must identify alternative solutions and develop transition plans to transfer services and data securely to another provider or back in-house.
Is a DORA exit plan required for every ICT contract?
No. Article 28(8) applies to ICT services supporting critical or important functions as defined in Article 3(22). However, the RTS on the ICT third-party policy (Commission Delegated Regulation (EU) 2024/1773, Article 10) requires a documented exit plan for each contractual arrangement in that critical/important scope — one plan per arrangement, not one generic strategy for the whole estate. Non-critical arrangements need termination rights under Article 28(7) but not a full exit plan.
Does a DORA exit plan have to be tested?
Yes. Article 28(8) requires exit plans to be 'sufficiently tested and reviewed periodically' in line with Article 4(2) proportionality, and RTS (EU) 2024/1773 Article 10 requires the plans to be realistic, feasible, based on plausible scenarios and reasonable assumptions, with testing that considers unforeseen and persistent service interruptions. Supervisors act on this: early ECB-led DORA inspections flagged overly generic and untested exit strategies as a recurring finding, so a paper-only plan with no test log is itself a deficiency.
What is the difference between a DORA exit strategy and an exit plan?
The exit strategy is the entity-level policy layer: which risk scenarios you plan for, what outcomes an exit must protect (business continuity, regulatory compliance, client service quality), and how alternatives are assessed. The exit plan is the operational playbook per contractual arrangement: triggers, the alternative solution chosen, the transition timeline and data-migration steps, contingency measures, roles, and the test schedule. RTS (EU) 2024/1773 Article 10 expects the documented exit plan per critical/important arrangement; Article 28(8) requires both layers.
What is the mandatory transition period in DORA Article 30(3)(f)?
Contracts for ICT services supporting critical or important functions must include exit strategies with a mandatory adequate transition period, during which the provider keeps delivering the service so the financial entity can migrate to another provider or an in-house solution without disruption — sized to the complexity of the service. The transition period agreed in the contract is what makes an exit plan executable, so the template records it per arrangement and flags plans whose schedules don't fit inside it.
Do UK firms need DORA exit strategies?
DORA does not apply in the UK, but PRA Supervisory Statement SS2/21 imposes a materially similar obligation: firms must develop, maintain, and test a documented exit strategy for each material outsourcing arrangement, explicitly differentiating stressed exits (provider failure or insolvency) from non-stressed, planned exits. Pan-European groups can maintain one DORA-grade exit plan per arrangement and reuse it for the UK regime — the DORA field set plus the stressed/non-stressed distinction covers both.
Does Norway require DORA exit strategies?
Yes. DORA was incorporated into the EEA Agreement and Norway's DORA Act has been in force since 1 July 2025, with Finanstilsynet as competent authority. Norwegian financial entities face the same Article 28(8) obligations — comprehensive, documented, tested and periodically reviewed exit plans — and Finanstilsynet has stated it expects exit plans to be realistic and regularly tested.