---
name: "DORA-exitstrategie- en exitplansjabloon"
version: "1.0"
updated: "2026-07-23"
source: "https://www.orbiqhq.com/nl/sjablonen/dora-exitstrategie-sjabloon"
license: "Vrij te gebruiken en aan te passen binnen uw organisatie. Bronvermelding gewaardeerd. Geen juridisch advies."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2022/2554/oj"          # DORA — Verordening (EU) 2022/2554 (art. 28, lid 7, 28, lid 8, 30, lid 3, onder f))
  - "https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj"      # RTS over het ICT-derdenbeleid (art. 10 — exitplannen)
---

# DORA-exitstrategie- en exitplansjabloon (machine-leesbaar)

Doel: het documenteren en onderhouden van DORA-conforme exitstrategieën en exitplannen per
overeenkomst voor ICT-diensten die kritieke of belangrijke functies ondersteunen (Verordening (EU)
2022/2554, artikel 28, lid 8; Gedelegeerde Verordening (EU) 2024/1773, artikel 10). Dit bestand is
zelfstandig leesbaar: een agent kan uit de onderstaande definities een exitstrategie op
entiteitsniveau opstellen, per contractuele overeenkomst binnen scope één exitplanrecord genereren
en de test-/evaluatielog onderhouden.

Structuurregel: ÉÉN exitplanrecord per contractuele overeenkomst die een kritieke of belangrijke
functie ondersteunt (RTS, art. 10) — nooit één generiek plan voor het hele leveranciersbestand.
Exitplanrecords sluiten via `contract_ref` aan op het informatieregister (zie het bijbehorende
dora-register-of-information-starter.md).

Beschermde uitkomsten (art. 28, lid 8) — elke exit moet worden voltooid zonder:
1. verstoring van de bedrijfsactiviteiten;
2. beperking van de naleving van regelgeving;
3. afbreuk aan de continuïteit en kwaliteit van de dienstverlening aan klanten.

Jurisdictienotities: Noorwegen past art. 28, lid 8, ongewijzigd toe (Noorse DORA-wet van kracht
sinds 2025-07-01, Finanstilsynet; plannen moeten realistisch zijn en regelmatig worden getest).
Het VK kent geen DORA, maar PRA SS2/21 vereist per materiële uitbestedingsovereenkomst een
gedocumenteerde, geteste exitstrategie met onderscheid tussen gedwongen en niet-gedwongen exits —
de `trigger_class`-enum hieronder dekt beide regimes. In Nederland verwachten DNB en de AFM
alomvattende, gedocumenteerde en geteste exitplannen; NOREA (de beroepsorganisatie van
IT-auditors) publiceert een eigen gratis exitplansjabloon dat dit bestand uitbreidt.

---

## 1. Exitstrategie (entiteitsniveau) — één record

| # | Veld | Type | Definitie / regel |
|---|---|---|---|
| 1 | `entity_legal_name` | tekst | Geregistreerde juridische naam |
| 2 | `entity_lei` | tekst (LEI-20) | Legal Entity Identifier |
| 3 | `competent_authority` | tekst | NCA (DNB, AFM, BaFin, CBI, Finanstilsynet, …) |
| 4 | `strategy_owner` | tekst (rol) | Verantwoordelijke rol, bijv. Hoofd Third-Party Risk Management |
| 5 | `approval_body` | tekst | Leidinggevend orgaan of comité + goedkeuringsdatum |
| 6 | `in_scope_contract_refs` | lijst van `contract_ref` | Alle overeenkomsten die kritieke of belangrijke functies ondersteunen (art. 3, punt 22); moet overeenkomen met het informatieregister |
| 7 | `risk_scenarios` | vaste lijst | MOET dekken: `provider_failure`, `quality_deterioration`, `business_disruption`, `material_deployment_risk`, `art_28_7_termination` (art. 28, lid 8, eerste alinea) |
| 8 | `substitutability_scale` | enum-definitie | bijv. `easily_substitutable` / `substitutable_with_effort` / `difficult` / `not_substitutable` — afstemmen op de RoI B_07-beoordelingen |
| 9 | `market_scan_cadence` | tekst | Hoe vaak alternatieven per dienstcategorie worden herbeoordeeld |
| 10 | `review_cadence` | tekst | Ten minste jaarlijks + bij materiële wijziging |
| 11 | `last_review` / `next_review` | datum (ISO 8601) | Evaluatiedatums van de strategie |

## 2. Exitplan — één record PER overeenkomst

### 2.1 Identificatie

| # | Veld | Type | Definitie / regel |
|---|---|---|---|
| 1 | `contract_ref` | tekst, uniek | PRIMAIRE SLEUTEL — moet bestaan in het informatieregister (B_02) |
| 2 | `provider_legal_name` | tekst | ICT-derde aanbieder |
| 3 | `provider_id` | tekst | LEI of EUID (rechtspersonen in de EU); LEI (rechtspersonen uit derde landen) |
| 4 | `ict_service_type` | enum `S01`–`S19` | Gesloten lijst conform ITS (EU) 2024/2956, bijlage III |
| 5 | `cif_supported` | tekst | Ondersteunde kritieke of belangrijke functie + verwijzing naar de redenering onder art. 3, punt 22 |
| 6 | `plan_owner` | tekst (rol) | Onderhoudt het plan |
| 7 | `activation_decision_maker` | tekst (rol/comité) | Bevoegd om de exit te activeren |
| 8 | `plan_version` / `plan_date` | tekst / datum | Versiebeheer |

### 2.2 Triggers

| # | Veld | Type | Definitie / regel |
|---|---|---|---|
| 1 | `trigger_class` | enum: `planned` / `stressed` | Gedwongen (stressed) = falen/insolventie of een omstandigheid van art. 28, lid 7; dekt ook het onderscheid gedwongen/niet-gedwongen van PRA SS2/21 |
| 2 | `planned_triggers` | lijst van tekst | bijv. contracteinde zonder verlenging, strategische insourcing |
| 3 | `stressed_triggers` | lijst van 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` | lijst van tekst | KRI's die elke trigger zichtbaar maken (aantal SLA-schendingen, incidentfrequentie, signalen over financiële gezondheid) |

### 2.3 Alternatieve oplossing

| # | Veld | Type | Definitie / regel |
|---|---|---|---|
| 1 | `alternatives_assessed` | lijst van {name, assessed_date, result} | Beoordeelde alternatieve aanbieders |
| 2 | `inhouse_option` | {feasible: boolean, notes} | Beoordeling van reïntegratie in de eigen organisatie (art. 28, lid 8, vierde alinea) |
| 3 | `selected_route` | enum: `alternative_provider` / `in_house` / `hybrid` | Gekozen exitroute |
| 4 | `substitutability` | enum volgens de strategieschaal | Actuele score |

### 2.4 Transitieplan

| # | Veld | Type | Definitie / regel |
|---|---|---|---|
| 1 | `phases` | geordende lijst van {phase, duration, description} | Typisch: voorbereiding → datamigratie → parallelrun → cutover → ontmanteling |
| 2 | `data_inventory` | lijst van {dataset, volume, location} | Gegevens die de aanbieder houdt |
| 3 | `data_return_format` | tekst | Afgesproken exportformaat/-formaten — contractueel gegarandeerd |
| 4 | `secure_transfer_method` | tekst | Mechanisme + encryptie onderweg + integriteitsverificatie ("veilig en integraal overdragen", art. 28, lid 8) |
| 5 | `parallel_run_window` | tekst | Duur + succescriteria |
| 6 | `rollback_criteria` | tekst | Voorwaarden waaronder de cutover wordt teruggedraaid |
| 7 | `closure_steps` | lijst van tekst | Verwijderingsbevestiging, intrekken van toegang, RoI-update |

### 2.5 Contractuele ankers

| # | Veld | Type | Definitie / regel |
|---|---|---|---|
| 1 | `transition_period` | tekst | Verplichte toereikende transitieperiode conform art. 30, lid 3, onder f) |
| 2 | `notice_period_entity` / `notice_period_provider` | geheel getal (dagen) | Opzegtermijnen |
| 3 | `data_return_clauses` | tekst | Clausuleverwijzingen + gegarandeerde formaten |
| 4 | `transition_assistance` | tekst | Migratieondersteuningsverplichtingen van de aanbieder incl. kosten |
| 5 | `schedule_fit` | boolean | REGEL: het totaal van de `phases`-duren MOET binnen `transition_period` passen; zo niet → contractremediëringspunt, plan niet uitvoerbaar |

### 2.6 Noodmaatregelen, kosten, governance

| # | Veld | Type | Definitie / regel |
|---|---|---|---|
| 1 | `contingency_measures` | lijst van tekst | Tijdelijke continuïteitsmaatregelen tijdens de exit (art. 28, lid 8, laatste alinea) |
| 2 | `client_impact_mitigation` | tekst | Bescherming van continuïteit/kwaliteit van de dienstverlening aan klanten |
| 3 | `compliance_safeguards` | tekst | Rapportage, continuïteit van gegevensbescherming, bewaring tijdens migratie |
| 4 | `exit_cost_estimate` | getal + valuta | Eenmalige migratiekosten + vergoedingen voor transitieondersteuning |
| 5 | `resourcing` | tekst | Teams, FTE-weken, afhankelijkheden van sleutelpersonen |

## 3. Test- en evaluatielog — append-only records

| # | Veld | Type | Definitie / regel |
|---|---|---|---|
| 1 | `test_date` | datum (ISO 8601) | |
| 2 | `contract_ref` | tekst | Geteste overeenkomst |
| 3 | `scenario` | enum: `unforeseen_interruption` / `persistent_interruption` / `provider_insolvency` / `quality_deterioration` / `planned_exit` / overig | RTS, art. 10: tests MOETEN rekening houden met onvoorziene en aanhoudende dienstonderbrekingen |
| 4 | `test_type` | enum: `tabletop` / `walkthrough` / `partial_data_extraction` / `restore_verification` / `full_simulation` | Meest kritieke overeenkomsten: neem echte data-extractietests op |
| 5 | `participants` | lijst van tekst | |
| 6 | `findings` | tekst | bijv. exportdoorvoer onder de aanname |
| 7 | `remediation` | {actions, closed_date} | Daaruit voortvloeiende planupdates |
| 8 | `next_test` | datum | Cadansregel: ten minste één test per overeenkomst per evaluatiecyclus; risicogebaseerde frequentie |

## 4. Activeringsdraaiboek (volgorde)

1. `declare` — beslisser bevestigt de trigger, verklaart de exit (gepland/gedwongen), legt besluit + tijdstip vast
2. `notify` — interne belanghebbenden; aanbieder (contractuele opzegging); bevoegde autoriteit waar vereist; klanten volgens plan
3. `freeze` — scopewijzigingen bevriezen; datasnapshot veiligstellen; datainventaris hervalideren
4. `execute` — transitiefasen uitvoeren binnen het venster van art. 30, lid 3, onder f); noodmaatregelen activeren waar nodig
5. `verify` — gegevens terugontvangen in het afgesproken formaat; integriteit geverifieerd; verwijdering door de aanbieder bevestigd; toegang ingetrokken
6. `close` — informatieregister bijwerken; post-exitevaluatie; lessen terugvoeren naar de strategie en de overige plannen

## 5. Voorbeeldrecord (fictief, verkort)

```yaml
contract_ref: CTR-2024-018
provider_legal_name: CloudCore GmbH
ict_service_type: S17
cif_supported: "Verwerking van retailbetalingen (kritiek, RoI B_06.01)"
trigger_class: stressed
stressed_triggers: [provider_insolvency, art_28_7_c_ict_risk_weaknesses]
selected_route: alternative_provider   # HanseCloud AB, beoordeeld 2026-03
phases:
  - {phase: preparation, duration: 4w}
  - {phase: data_migration, duration: 6w}   # herpland 4w→6w na extractietest 2026-04-22
  - {phase: parallel_run, duration: 4w}
  - {phase: cutover, duration: 1w}
  - {phase: decommission, duration: 3w}
transition_period: "24 maanden vanaf de opzegging"
schedule_fit: true
data_return_format: "PostgreSQL-dumps + S3-compatibele objectexport, AES-256 onderweg, SHA-256-manifesten"
contingency_measures: ["Betalingswachtrij in degraded mode via secundaire locatie, RTO 4 uur"]
last_test: {date: 2026-04-22, scenario: persistent_interruption, test_type: partial_data_extraction}
```