---
name: "DORA Exit Strategy & Exit Plan Template"
version: "1.0"
updated: "2026-07-17"
source: "https://www.orbiqhq.com/templates/dora-exit-strategy-plan"
license: "Free to use and adapt within your organisation. Attribution appreciated. Not legal advice."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2022/2554/oj"          # DORA — Regulation (EU) 2022/2554 (Art. 28(7), 28(8), 30(3)(f))
  - "https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj"      # RTS on the ICT third-party policy (Art. 10 — exit plans)
---

# DORA Exit Strategy & Exit Plan Template (machine-readable)

Purpose: document and maintain DORA-compliant exit strategies and per-arrangement exit plans for
ICT services supporting critical or important functions (Regulation (EU) 2022/2554, Article 28(8);
Commission Delegated Regulation (EU) 2024/1773, Article 10). This file is self-contained: an agent
can construct an entity-level exit strategy, generate one exit-plan record per in-scope contractual
arrangement, and maintain the testing/review log from the definitions below.

Structural rule: ONE exit-plan record per contractual arrangement supporting a critical or
important function (RTS Art. 10) — never one generic plan for the whole provider estate. Exit-plan
records key into the Register of Information via `contract_ref` (see the companion
dora-register-of-information-starter.md).

Protected outcomes (Art. 28(8)) — every exit must complete without:
1. disruption to business activities;
2. limiting compliance with regulatory requirements;
3. detriment to the continuity and quality of services provided to clients.

Jurisdiction notes: Norway applies Art. 28(8) unchanged (Norwegian DORA Act in force 2025-07-01,
Finanstilsynet; plans expected to be realistic and regularly tested). The UK has no DORA, but PRA
SS2/21 requires a documented, tested exit strategy per material outsourcing arrangement
distinguishing stressed vs non-stressed exits — the `trigger_class` enum below covers both regimes.

---

## 1. Exit Strategy (entity level) — one record

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `entity_legal_name` | text | Registered legal name |
| 2 | `entity_lei` | text (LEI-20) | Legal Entity Identifier |
| 3 | `competent_authority` | text | NCA (BaFin, DNB, CBI, AMF, Finanstilsynet, …) |
| 4 | `strategy_owner` | text (role) | Accountable role, e.g. Head of Third-Party Risk Management |
| 5 | `approval_body` | text | Management body or committee + approval date |
| 6 | `in_scope_contract_refs` | list of `contract_ref` | All arrangements supporting critical or important functions (Art. 3(22)); must match the Register of Information |
| 7 | `risk_scenarios` | fixed list | MUST cover: `provider_failure`, `quality_deterioration`, `business_disruption`, `material_deployment_risk`, `art_28_7_termination` (Art. 28(8) subpara 1) |
| 8 | `substitutability_scale` | enum definition | e.g. `easily_substitutable` / `substitutable_with_effort` / `difficult` / `not_substitutable` — align with RoI B_07 assessments |
| 9 | `market_scan_cadence` | text | How often alternatives are re-assessed per service category |
| 10 | `review_cadence` | text | At least annual + on material change |
| 11 | `last_review` / `next_review` | date (ISO 8601) | Strategy review dates |

## 2. Exit Plan — one record PER arrangement

### 2.1 Identification

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `contract_ref` | text, unique | PRIMARY KEY — must exist in the Register of Information (B_02) |
| 2 | `provider_legal_name` | text | ICT third-party service provider |
| 3 | `provider_id` | text | LEI or EUID (EU legal persons); LEI (third-country legal persons) |
| 4 | `ict_service_type` | enum `S01`–`S19` | Closed list per ITS (EU) 2024/2956 Annex III |
| 5 | `cif_supported` | text | Critical or important function supported + Art. 3(22) reasoning reference |
| 6 | `plan_owner` | text (role) | Maintains the plan |
| 7 | `activation_decision_maker` | text (role/committee) | Empowered to trigger the exit |
| 8 | `plan_version` / `plan_date` | text / date | Version control |

### 2.2 Triggers

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `trigger_class` | enum: `planned` / `stressed` | Stressed = failure/insolvency or Art. 28(7) circumstance; also satisfies PRA SS2/21 stressed/non-stressed split |
| 2 | `planned_triggers` | list of text | e.g. contract expiry without renewal, strategic insourcing |
| 3 | `stressed_triggers` | list of enum | `provider_insolvency` / `art_28_7_a_breach` / `art_28_7_b_monitoring_findings` / `art_28_7_c_ict_risk_weaknesses` / `art_28_7_d_supervisability` / `ctpp_oversight_recommendation` |
| 4 | `trigger_indicators` | list of text | KRIs surfacing each trigger (SLA breach counts, incident frequency, financial-health flags) |

### 2.3 Alternative solution

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `alternatives_assessed` | list of {name, assessed_date, result} | Alternative providers evaluated |
| 2 | `inhouse_option` | {feasible: boolean, notes} | Reincorporation in-house assessment (Art. 28(8) subpara 4) |
| 3 | `selected_route` | enum: `alternative_provider` / `in_house` / `hybrid` | Chosen exit route |
| 4 | `substitutability` | enum per strategy scale | Current rating |

### 2.4 Transition plan

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `phases` | ordered list of {phase, duration, description} | Typical: preparation → data migration → parallel run → cutover → decommission |
| 2 | `data_inventory` | list of {dataset, volume, location} | Data held by the provider |
| 3 | `data_return_format` | text | Agreed export format(s) — contractually guaranteed |
| 4 | `secure_transfer_method` | text | Mechanism + encryption in transit + integrity verification ("securely and integrally transfer", Art. 28(8)) |
| 5 | `parallel_run_window` | text | Duration + success criteria |
| 6 | `rollback_criteria` | text | Conditions reversing cutover |
| 7 | `closure_steps` | list of text | Deletion confirmation, access revocation, RoI update |

### 2.5 Contractual anchors

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `transition_period` | text | Mandatory adequate transition period per Art. 30(3)(f) |
| 2 | `notice_period_entity` / `notice_period_provider` | integer (days) | Termination notice periods |
| 3 | `data_return_clauses` | text | Clause refs + guaranteed formats |
| 4 | `transition_assistance` | text | Provider migration-support obligations incl. cost |
| 5 | `schedule_fit` | boolean | RULE: total of `phases` durations MUST fit inside `transition_period`; if false → contract remediation item, plan not executable |

### 2.6 Contingency, cost, governance

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `contingency_measures` | list of text | Interim continuity measures mid-exit (Art. 28(8) final subpara) |
| 2 | `client_impact_mitigation` | text | Protecting continuity/quality of client services |
| 3 | `compliance_safeguards` | text | Reporting, data-protection continuity, retention during migration |
| 4 | `exit_cost_estimate` | number + currency | One-off migration + transition-assistance fees |
| 5 | `resourcing` | text | Teams, FTE-weeks, key-person dependencies |

## 3. Testing & Review Log — append-only records

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `test_date` | date (ISO 8601) | |
| 2 | `contract_ref` | text | Arrangement tested |
| 3 | `scenario` | enum: `unforeseen_interruption` / `persistent_interruption` / `provider_insolvency` / `quality_deterioration` / `planned_exit` / other | RTS Art. 10: testing MUST consider unforeseen and persistent service interruptions |
| 4 | `test_type` | enum: `tabletop` / `walkthrough` / `partial_data_extraction` / `restore_verification` / `full_simulation` | Highest-criticality arrangements: include real data-extraction tests |
| 5 | `participants` | list of text | |
| 6 | `findings` | text | e.g. export-throughput below assumption |
| 7 | `remediation` | {actions, closed_date} | Plan updates resulting |
| 8 | `next_test` | date | Cadence rule: at least one test per arrangement per review cycle; risk-based frequency |

## 4. Activation runbook (sequence)

1. `declare` — decision-maker confirms trigger, declares exit (planned/stressed), records decision + time
2. `notify` — internal stakeholders; provider (contractual notice); competent authority where required; clients per plan
3. `freeze` — freeze scope changes; snapshot data; re-validate data inventory
4. `execute` — run transition phases against the Art. 30(3)(f) window; stand up contingency measures as needed
5. `verify` — data returned in agreed format; integrity verified; provider deletion confirmed; access revoked
6. `close` — update Register of Information; post-exit review; feed lessons into strategy and remaining plans

## 5. Example record (fictional, abridged)

```yaml
contract_ref: CTR-2024-018
provider_legal_name: CloudCore GmbH
ict_service_type: S17
cif_supported: "Retail payment processing (critical, RoI B_06.01)"
trigger_class: stressed
stressed_triggers: [provider_insolvency, art_28_7_c_ict_risk_weaknesses]
selected_route: alternative_provider   # HanseCloud AB, assessed 2026-03
phases:
  - {phase: preparation, duration: 4w}
  - {phase: data_migration, duration: 6w}   # re-planned 4w→6w after 2026-04-22 extraction test
  - {phase: parallel_run, duration: 4w}
  - {phase: cutover, duration: 1w}
  - {phase: decommission, duration: 3w}
transition_period: "24 months from termination notice"
schedule_fit: true
data_return_format: "PostgreSQL dumps + S3-compatible object export, AES-256 in transit, SHA-256 manifests"
contingency_measures: ["Degraded-mode payment queue via secondary site, RTO 4h"]
last_test: {date: 2026-04-22, scenario: persistent_interruption, test_type: partial_data_extraction}
```