DORA-exitstrategie: gratis sjabloon (2026) — art. 28(8)

DORA-exitstrategie: gratis sjabloon (2026) — art. 28(8)

Kort antwoord: dit gratis DORA-exitstrategie-sjabloon is een downloadbare DOCX (plus PDF-gids en machine-leesbare Markdown; de downloadbestanden zijn beschikbaar in het Nederlands) die de twee lagen dekt die artikel 28, lid 8, van Verordening (EU) 2022/2554 vereist voor ICT-diensten die kritieke of belangrijke functies ondersteunen: een exitstrategie op entiteitsniveau, gebouwd op de vijf risicoscenario's van artikel 28, lid 8, en een exitplan-formulier per overeenkomst — triggers, alternatieve oplossingen, transitieplan, dataportabiliteit, noodmaatregelen en de testlog die RTS (EU) 2024/1773, artikel 10, verplicht stelt. Het onderscheidt geplande van gedwongen exits, legt per overeenkomst de contractuele transitieperiode van artikel 30, lid 3, onder f), vast en bevat een volledig ingevuld fictief voorbeeld.

Gratis exitplan-documenten bestaan al — NOREA, de Nederlandse beroepsorganisatie van IT-auditors, publiceert er een, en aan checklistblogs geen gebrek. Wat ze gemeen hebben, is de vorm die toezichthouders nu al bekritiseren: een document dat u één keer invult en archiveert. Vroege door de ECB geleide DORA-inspecties merkten te generieke en ongeteste exitstrategieën aan als terugkerende bevinding. Dit sjabloon is rond die faalmodus gebouwd: de testlog en de evaluatiecadans zijn structurele onderdelen van het document, de planvelden dwingen specificiteit per overeenkomst af (welk alternatief, welk dataformaat, welk transitievenster) en de machine-leesbare Markdown-variant laat een AI-agent de plannen bijhouden naast uw informatieregister.

---

Belangrijkste punten

• Twee lagen, conform de regelgeving. Artikel 28, lid 8, vereist de strategie; RTS (EU) 2024/1773, artikel 10, vereist een gedocumenteerd exitplan voor elke contractuele overeenkomst die een kritieke of belangrijke functie ondersteunt. Het sjabloon levert beide — één strategiedocument, één herbruikbaar planformulier.
• De drie beschermde uitkomsten. Elke exit moet worden voltooid zonder verstoring van de bedrijfsactiviteiten, zonder beperking van de naleving van regelgeving en zonder afbreuk aan de continuïteit en kwaliteit van de dienstverlening aan klanten — het planformulier toetst elke fase aan alle drie.
• Testen is de compliancelat, geen extraatje. Plannen moeten realistisch en uitvoerbaar zijn, gebaseerd op plausibele scenario's en redelijke aannames, en getest tegen onvoorziene en aanhoudende dienstonderbrekingen (RTS, art. 10). De ingebouwde testlog registreert scenario, type (tabletop / gedeeltelijke data-extractie / volledige simulatie), bevindingen en remediëring.
• Geplande versus gedwongen exits. De beëindigingsomstandigheden van artikel 28, lid 7, plus insolventie van de aanbieder leveren de gedwongen scenario's; commerciële of strategische keuzes de geplande. Het formulier dekt beide — en voldoet daarmee in één document ook aan het onderscheid gedwongen/niet-gedwongen van het Britse PRA SS2/21.
• Verankerd in het contract. De verplichte toereikende transitieperiode van artikel 30, lid 3, onder f), wordt per overeenkomst vastgelegd, en de planning van het plan wordt ertegen getoetst — een exitplan dat niet binnen zijn contractuele transitievenster past, is fictie.

---

Wat er in het sjabloon zit

De DOCX bevat vier werkende delen plus een ingevuld voorbeeld; de PDF is een veldgids; de MD-variant draagt de volledige structuur met enums voor agent-workflows.

1. Exitstrategie op entiteitsniveau

De beleidslaag: scope (welke overeenkomsten binnen de kritieke/belangrijke perimeter vallen, via contractreferentie gekoppeld aan uw informatieregister), governance en eigenaarschap, de vijf risicoscenario's van artikel 28, lid 8, uitgeschreven —

#	Scenario	Bron
1	Falen van de ICT-derde aanbieder	Art. 28, lid 8
2	Verslechtering van de kwaliteit van de geleverde ICT-diensten	Art. 28, lid 8
3	Bedrijfsverstoring door ongeschikte of gebrekkige dienstverlening	Art. 28, lid 8
4	Materieel risico voor de passende en continue inzet van de dienst	Art. 28, lid 8
5	Beëindiging onder een omstandigheid van artikel 28, lid 7 (inbreuk, monitoringbevindingen, aangetoonde ICT-risicozwaktes, toezichtbaarheid)	Art. 28, leden 7–8

— plus de drie beschermde uitkomsten als strategiedoelen en de beoordelingsmethode voor alternatieven (vervangbaarheid, marktalternatieven, interne optie).

2. Exitplanformulier per overeenkomst

Eén formulier per kritieke/belangrijke overeenkomst:

Sectie	Velden
Identificatie	Contractref. (RoI-sleutel), aanbieder, ICT-dienst, ondersteunde kritieke of belangrijke functie
Triggers	Redenen voor een geplande exit; gedwongen triggers gemapt op art. 28, lid 7, onder a) t/m d) + insolventie
Alternatieven	Beoordeelde alternatieve aanbieder(s) / interne reïntegratieoptie / vervangbaarheidsscore
Transitieplan	Fasen, planning, datamigratiestappen, formaat gegevensteruggave, veilige overdrachtsmethode, integriteitsverificatie, parallelrunvenster, rollbackcriteria
Contractuele ankers	Transitieperiode van art. 30, lid 3, onder f), opzegtermijnen, clausules voor teruggave en verwijdering van gegevens, transitieondersteuning
Noodmaatregelen	Tijdelijke maatregelen die de functie draaiende houden tijdens de exit (art. 28, lid 8, laatste alinea)
Governance	Planeigenaar, beslisser voor activering, escalatiepad, kosten- en capaciteitsraming

3. Test- en evaluatielog voor exitplannen

Datum, geteste overeenkomst, scenario (inclusief de door de RTS vereiste gevallen van onvoorziene en aanhoudende onderbreking), testtype, deelnemers, bevindingen, remediëringsacties, volgende geplande test en laatste evaluatiedatum — het bewijsspoor waar inspecteurs het eerst om vragen.

4. Skelet van het activeringsdraaiboek

Een korte, gefaseerde checklist voor de dag dat een exit werkelijk wordt geactiveerd: verklaren, informeren (intern, aanbieder, bevoegde autoriteit waar vereist), scopewijzigingen bevriezen, transitiefasen uitvoeren, teruggave en verwijdering van gegevens verifiëren, afsluiten en het informatieregister bijwerken.

5. Ingevuld fictief voorbeeld

Het voorbeeld gebruikt hetzelfde fictieve universum als onze andere DORA-sjablonen — Nordbank SE die cloudaanbieder "CloudCore GmbH" verlaat (contract CTR-2024-018) — zodat het exitplan, de DORA-bewijschecklist voor ICT-leveranciers en het informatieregister-sjabloon als één samenhangende workflow lezen.

---

Zo gebruikt u dit sjabloon

1. Bepaal de scope vanuit het register. Haal elke overeenkomst die als ondersteunend voor een kritieke of belangrijke functie is gemarkeerd uit uw informatieregister — die contractreferenties zijn uw exitplan-werklijst. Eén plan per overeenkomst (RTS, art. 10), niet één plan voor alles.
2. Schrijf de strategie één keer. Vul de strategie op entiteitsniveau in: scenario's, beschermde uitkomsten, beoordelingsmethode voor alternatieven, governance.
3. Vul per overeenkomst een planformulier in. Wees concreet: noem de alternatieve aanbieder, het exportformaat van de gegevens, de transitiefasen. "Migreren naar een vergelijkbare aanbieder" is precies de generieke taal die inspecties aanmerken.
4. Toets het plan aan het contract. De transitieplanning moet binnen de transitieperiode van artikel 30, lid 3, onder f), passen, en de clausules voor gegevensteruggave moeten uw migratiestappen ondersteunen. Hiaten hier zijn contractremediëringspunten, geen voetnoten bij het plan.
5. Test, log, remedieer. Draai ten minste een tabletop per overeenkomst op een risicogebaseerde cadans — en test voor de meest kritieke overeenkomsten de data-extractie in het echt. Leg alles vast in de testlog.
6. Evalueer periodiek. Herbeoordeel wanneer de aanbieder, de dienst, de marktalternatieven of de criticaliteit van de functie verandert — en minimaal op de evaluatiecadans die uw beleid voorschrijft.

Voor het verzamelen van het bewijs dat deze plannen voedt — assurancerapporten, resultaten van weerbaarheidstests, onderaannemingsketens — gebruikt u de bijbehorende DORA-bewijschecklist voor ICT-leveranciers; voor het register waarop de plannen aansluiten, gebruikt u het DORA-informatieregister-sjabloon.

---

Juridische grondslag

• Artikel 28, lid 8, Verordening (EU) 2022/2554 (DORA) — voor ICT-diensten die kritieke of belangrijke functies ondersteunen: exitstrategieën die rekening houden met het falen van de aanbieder, kwaliteitsverslechtering, bedrijfsverstoring, materiële inzetrisico's en beëindiging onder artikel 28, lid 7; de mogelijkheid om uit te treden zonder bedrijfsverstoring, regulatoire beperking of nadeel voor klanten; alomvattende, gedocumenteerde, voldoende geteste en periodiek geëvalueerde exitplannen; geïdentificeerde alternatieve oplossingen en transitieplannen voor de veilige en integrale overdracht van diensten en gegevens naar alternatieve aanbieders of de eigen organisatie; en noodmaatregelen voor bedrijfscontinuïteit.
• Artikel 28, lid 7, Verordening (EU) 2022/2554 — de verplichte beëindigingsomstandigheden (significante inbreuk; via monitoring vastgestelde omstandigheden die de dienstverlening kunnen veranderen; aangetoonde zwaktes in het ICT-risicobeheer van de aanbieder; toezichtbaarheidszorgen) waartegen de exitstrategie uitvoerbaar moet zijn.
• Artikel 30, lid 3, onder f), Verordening (EU) 2022/2554 — contracten voor kritieke/belangrijke ICT-diensten moeten exitstrategieën bevatten, in het bijzonder een verplichte toereikende transitieperiode waarin de aanbieder blijft leveren, zodat migratie naar een andere aanbieder of interne oplossingen mogelijk is, passend bij de complexiteit van de dienst.
• Gedelegeerde Verordening (EU) 2024/1773 van de Commissie, artikel 10 (RTS over het ICT-derdenbeleid) — het beleid moet een gedocumenteerd exitplan per contractuele overeenkomst vereisen die kritieke of belangrijke functies ondersteunt, periodiek geëvalueerd en getest; plannen moeten realistisch en uitvoerbaar zijn, gebaseerd op plausibele scenario's en redelijke aannames, met een implementatieplanning die past bij de exit- en beëindigingsvoorwaarden van het contract, en tests die rekening houden met onvoorziene en aanhoudende dienstonderbrekingen.

Voor het volledige regulatoire beeld, zie onze DORA-compliancegids; waarom de artikelen 19, 28 en 30 een traditioneel ISMS ontgroeien, leest u in de analyse van DORA-artikelen 19, 28 en 30.

---

VK, Noorwegen en de EER

VK: DORA geldt er niet, maar de exitverplichting bestaat onder een andere naam. PRA SS2/21 verwacht dat ondernemingen voor elke materiële uitbestedingsovereenkomst een gedocumenteerde exitstrategie ontwikkelen, onderhouden en testen, met een expliciet onderscheid tussen gedwongen exits (falen of insolventie van de aanbieder) en niet-gedwongen, geplande exits, inclusief kosten-, capaciteits- en triggeranalyse — risicogebaseerd getest naast de scenariotests voor operationele weerbaarheid (SS1/21). Het regime voor kritieke derde partijen onder FSMA 2023 voegt direct toezicht op aangewezen aanbieders toe, maar neemt geen van de exitverwachtingen op ondernemingsniveau weg. De trigger-splitsing gepland/gedwongen van dit sjabloon mapt rechtstreeks op SS2/21.

Noorwegen / EER: DORA geldt via de EER-overeenkomst; de Noorse DORA-wet is sinds 1 juli 2025 van kracht met Finanstilsynet als bevoegde autoriteit. De Noorse implementatie neemt artikel 28, lid 8, ongewijzigd over — exitstrategieën voor kritieke/belangrijke overeenkomsten, uittreden zonder schade aan continuïteit, klantdienstverlening of naleving, en plannen die alomvattend, goed gedocumenteerd, getest en regelmatig geëvalueerd zijn. Finanstilsynet heeft aangegeven te verwachten dat exitplannen realistisch zijn en regelmatig worden getest.

---

De toezichtsrealiteit: papieren plannen stranden bij inspecties

Het patroon uit de eerste golf DORA-toezicht is consistent. Door de ECB geleide inspecties na de IT-risicovragenlijst merkten te generieke en ongeteste exitstrategieën aan als veelvoorkomende bevinding. De RTS over het ICT-derdenbeleid vereist dat exitplannen rusten op plausibele scenario's en passende aannames en voldoende getest zijn. Al onder de eerdere cloud-uitbestedingsreviews van de EBA was de kloof tussen een exitstrategie op papier en een ooit werkelijk geteste data-extractie een topbevinding — DORA maakt van die kloof een tekortkoming onder artikel 28, lid 8. Ook DNB en de AFM verwachten van Nederlandse entiteiten niets minder dan wat de verordening voorschrijft: alomvattende, gedocumenteerde en geteste exitplannen, en NOREA's eigen sjabloon laat zien dat de Nederlandse auditpraktijk daar al op voorsorteert.

Het operationele antwoord is exitplannen niet langer als documenten te behandelen, maar als onderhouden records met testbewijs. Het Vendor Assurance Platform van Orbiq houdt leveranciersrecords, exitplanstatus en bewijs met vervaltracking bij in één beheerde workflow — gebouwd voor Europese financiële entiteiten met EU-dataresidentie. De machine-leesbare Markdown-variant van dit sjabloon is beschikbaar op /downloads/templates/nl/dora-exit-strategy-plan.md voor AI-agent-workflows.

---

Bronnen en verwijzingen

1. Verordening (EU) 2022/2554 (DORA) — EUR-Lex — artikelen 28, lid 7, 28, lid 8, en 30, lid 3, onder f)
2. Gedelegeerde Verordening (EU) 2024/1773 van de Commissie — EUR-Lex — RTS over het ICT-derdenbeleid; exitplan-, evaluatie- en testvereisten van artikel 10
3. KPMG ECB Office — Understanding the DORA risk questionnaire and first inspection findings — generieke en ongeteste exitstrategieën onder de veelvoorkomende JST-bevindingen
4. PRA SS2/21 — Outsourcing and third party risk management — Britse gedocumenteerde exitstrategieën; gedwongen versus niet-gedwongen exits
5. Finanstilsynet — Noorse DORA-wet van kracht op 1 juli 2025 — implementatie in Noorwegen / de EER, Finanstilsynet als bevoegde autoriteit
6. NOREA — DORA-sjabloon exitplan — het bestaande gratis document van de Nederlandse beroepsorganisatie van IT-auditors, dat dit sjabloon uitbreidt (strategie + plan + testlog + agent-leesbare variant)