Een cloudexitplan is een gedocumenteerd, getest en aantoonbaar uitvoerbaar plan waarmee een organisatie haar digitale werkprocessen, data en koppelingen gecontroleerd kan overdragen van een cloudleverancier naar een alternatieve omgeving, zonder verlies van continuïteit, soevereiniteit of juridische conformiteit. Voor overheidsorganisaties is dit geen vrijwillig kwaliteitsinstrument, maar een verplichting die voortvloeit uit het Rijkscloudbeleid 2026, NIS-2 artikel 21 en de EU Data Act.
Exitplan versus disaster recovery: twee fundamenteel andere documenten
Een exitplan en een disaster recovery plan worden in de praktijk regelmatig verward, maar beschrijven wezenlijk verschillende situaties en vereisen een eigen aanpak.
Een disaster recovery plan (DRP) richt zich op technisch herstel na een incident: een datastorage die uitvalt, een ransomware-aanval of een regionale stroomstoring. Het doel is terugkeer naar de bestaande situatie bij dezelfde leverancier. Een exitplan beschrijft iets fundamenteel anders: het gecontroleerd verlaten van een leverancier, met overdracht van data, het sluiten of overzetten van API-koppelingen, contractafwikkeling en de overgang naar een alternatieve omgeving. Beide documenten vullen elkaar aan, maar een DRP kan een exitplan nooit vervangen.
Wat een exitplan voor overheidsorganisaties onderscheidt van een generiek zakelijk equivalent, zijn de soevereiniteitselementen. Dit zijn onder meer: een jurisdictieanalyse van de huidige leverancier (is die onderworpen aan de US CLOUD Act of de Foreign Intelligence Surveillance Act?), een inventarisatie van proprietary dataformaten die overdracht bemoeilijken, en een toetsing aan open standaarden die overdraagbaarheid garanderen. Deze elementen komen in een standaard DRP niet voor.
Minimumvereisten onder het Rijkscloudbeleid 2026
Het Rijkscloudbeleid 2026 stelt concrete minimumeisen aan het exitplan van rijksorganisaties en organisaties die onder het Rijksinkoopbeleid vallen.
Het beleid schrijft voor dat een exitplan minimaal drie scenario’s uitwerkt: een gepland vertrek bij contracteinde of strategische heroriëntatie, een ongepland vertrek bij faillissement van de leverancier of intrekking van de dienst, en een noodscenario waarbij de leverancier niet meer medewerkt aan gegevensoverdracht. Voor elk scenario moeten hersteltijddoelstellingen (RTO) en herstelpuntdoelstellingen (RPO) zijn vastgelegd, analoog aan de eisen in NIS-2 artikel 21 over bedrijfscontinuïteit.
Daarnaast vereist het beleid dat het exitplan is geïntegreerd in de bredere informatiebeveiligingsstrategie van de organisatie, conform de cloudspecifieke beveiligingsmaatregelen uit ISO/IEC 27017. Dat certificeringsschema schrijft voor welke verantwoordelijkheden de leverancier heeft bij beëindiging van de dienst, waaronder het bewaren van data gedurende een overeengekomen exportperiode en het beschikbaar stellen van exporttools in interoperabele formaten.
Contractuele verplichtingen bij leveranciers buiten de EU/EER
Overheidsorganisaties die werken met cloudleveranciers buiten de EU/EER lopen een dubbel risico: enerzijds de extraterritoriale werking van wetten zoals de US CLOUD Act, anderzijds het ontbreken van wettelijk afdwingbare overdrachtsrechten in geval van contractbeëindiging.
De Cloud III DPS exitclausules, die als standaard contractraamwerk gelden voor rijksaanbestedingen op het inkoopplatform van de rijksoverheid, bevatten een reeks verplichte bepalingen die dit risico reduceren. Organisaties moeten in hun eigen contractonderhandelingen minimaal bedingen:
- Expliciete dataportabiliteitsrechten in open en gestandaardiseerde formaten, zonder conversieverlies.
- Een gegarandeerde exporttermijn van minimaal 30 dagen na contractbeëindiging, met toegang tot alle data inclusief metadata.
- Een verbod op gebruik van klantdata voor het trainen van AI-modellen of andere doeleinden buiten de overeengekomen dienstverlening.
- Een jurisdictieclausule die EU-recht en de toepasselijke Nederlandse wetgeving als exclusief toepasselijk recht aanwijst.
- Een auditrecht dat de overheidsorganisatie of een onafhankelijke derde in staat stelt jaarlijks de werking van de exitprocedure te verifiëren.
Zonder deze bepalingen is een exitplan weliswaar technisch beschreven, maar juridisch niet afdwingbaar. ENISA benadrukt in haar cloudbeveiligingsrichtlijnen dat contractuele waarborgen en technische uitvoerbaarheid hand in hand moeten gaan.
“Vendor lock-in bij cloudproviders is een van de grootste strategische risico’s voor de digitale soevereiniteit van overheden. Een exitplan is geen formaliteit maar een operationeel document dat jaarlijks getest moet worden.” (ENISA, Cloud Security for the EU Institutions)
Technische afhankelijkheden in kaart brengen en reduceren
Een geloofwaardig exitplan begint bij een accurate inventarisatie van alle technische afhankelijkheden die vertrek bemoeilijken of onmogelijk maken.
De drie meest voorkomende vormen van lock-in bij overheidsorganisaties zijn: data-lock-in (data is opgeslagen in proprietary formaten die niet zonder conversieverlies exporteerbaar zijn), API-lock-in (interne systemen zijn direct gekoppeld aan leverancierspecifieke API’s zonder abstractielaag) en proceslock-in (werkprocessen zijn zo diep geïntegreerd met leverancierspecifieke functionaliteiten dat migratie een complete herinrichting vereist).
| Type afhankelijkheid | Voorbeeld | Reductiestrategie |
|---|---|---|
| Data-lock-in | Documenten in proprietair Office-formaat (.docx zonder ODF-export) | Verplicht gebruik van OpenDocument Format of PDF/A als archiefformaat |
| API-lock-in | Directe koppeling met Microsoft Graph API zonder adapter | Invoer van een abstractielaag (middleware) die API-wisseling transparant maakt |
| Proceslock-in | Werkstromen volledig ingericht in Teams/SharePoint zonder procesontwerp | Procesontwerp los van tooling documenteren; keuze voor open-source workflowtools |
| Identiteitslock-in | Gebruikersbeheer uitsluitend via Azure Active Directory | Inzet van open LDAP/SAML-gebaseerde identiteitsdiensten als alternatief |
ENISA raamt dat meer dan 60% van de EU-overheidsinstanties in 2023 geen volledig gedocumenteerd exitplan had voor hun primaire cloudprovider, mede doordat technische afhankelijkheden nooit systematisch in kaart waren gebracht. (Bron: ENISA, 2023)
Rol van open standaarden en de EU Data Act
Open standaarden zijn de technische ruggengraat van elk uitvoerbaar exitplan. Zonder interoperabele formaten en interfaces is dataportabiliteit in de praktijk illusoir.
De EU Data Act (Verordening (EU) 2023/2854), van toepassing vanaf september 2025, legt cloudaanbieders een wettelijke verplichting op tot het ondersteunen van portabiliteitsrechten en het aanbieden van interoperabele interfaces. Dit is een directe versterking van de positie van overheidsorganisaties in exitscenario’s: aanbieders kunnen niet langer weigeren medewerking te verlenen aan gegevensoverdracht of buitensporige overstapvergoedingen in rekening brengen.
“De overheid moet kunnen aantonen dat zij haar digitale infrastructuur daadwerkelijk zelf kan aansturen en dat de afhankelijkheid van één leverancier niet leidt tot bestuurlijke of operationele kwetsbaarheid.” (Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, Cloudstrategie Rijksoverheid)
Open-source softwareoplossingen zoals Nextcloud, LibreOffice en open federatieve identiteitsstandaarden (SAML 2.0, OpenID Connect) verlagen de overstapkosten structureel, doordat ze niet afhankelijk zijn van één leverancier voor updates, beheer of licenties. Het Forum Standaardisatie beheert de lijst van verplichte open standaarden voor de Nederlandse overheid, waaronder ODF, DKIM, STARTTLS en OAuth 2.0.
CADA en Union assurance levels in de aanbestedingspraktijk
Het EUCS-schema (EU Cybersecurity Certification Scheme for Cloud Services), dat wordt uitgewerkt door ENISA op basis van de Europese Cyber Act, kent drie assurance levels: Basic (Level 1), Substantial (Level 2) en High (Level 3).
CADA artikel 30 (in de context van het EUCS-schema) stelt dat overheidsaanbestedingen minimaal Union assurance level 1 vereisen voor cloudleveranciers die overheidsdata verwerken. In de praktijk betekent dit dat een leverancier aantoonbare portabiliteits- en interoperabiliteitsgaranties moet kunnen overleggen als onderdeel van het certificeringsdossier. Voor geclassificeerde informatie of kritieke infrastructuur geldt minimaal Level 2 (Substantial).
Voor een exitplan vertaalt dit zich naar concrete aanbestedingseisen: een leverancier die Level 1 wil halen, moet in zijn dienstverlening gestandaardiseerde exportmogelijkheden aanbieden, documenteren hoe data na contracteinde beschikbaar blijft, en aantonen dat de dienst interoperabel is met tenminste één alternatieve gecertificeerde leverancier. Organisaties kunnen deze eisen als minimumselectiecriterium opnemen in aanbestedingsdocumenten, zonder dat dit als disproportioneel of marktverstorend wordt beschouwd.
Circa 70% van de Nederlandse overheidsorganisaties maakt gebruik van clouddiensten buiten de EU/EER. (Bron: Rekenkamer/Ministerie van BZK, 2023). Het aantal ransomware-incidenten bij Europese overheidsinstanties steeg in 2022-2023 met 34%, waarbij cloud-omgevingen een toenemend doelwit vormen. (Bron: ENISA Threat Landscape 2023). Deze cijfers onderstrepen het belang van een exitplan dat niet alleen regulatoire conformiteit afdekt, maar ook operationele veerkracht borgt.
Van papieren plan naar uitvoerbare exitstrategie
Een exitplan dat uitsluitend als document bestaat zonder technische voorbereiding, is geen geloofwaardig exitplan. NIS-2 artikel 21 verplicht organisaties in de categorie “essentiële entiteiten” (waaronder veel overheidsorganisaties vallen) tot het inrichten van bedrijfscontinuïteitsmaatregelen die aantoonbaar werkbaar zijn. Een exitplan dat nooit is getest, voldoet hier niet aan.
Praktische voorbereiding omvat: het jaarlijks uitvoeren van een tabletop-oefening voor het noodscenario (leverancier valt weg zonder vooraankondiging), het bijhouden van een actueel register van alle data-assets en hun formaten, het periodiek exporteren en valideren van een volledige datadump in open formaten, en het documenteren van alle externe API-koppelingen met een migratieclassificatie (kritisch, hoog, laag). Organisaties die migreren van Microsoft 365 naar een soevereine Nextcloud-omgeving, doen er goed aan dit migratieproces zelf als exitoefening te documenteren: de lessen zijn direct overdraagbaar naar toekomstige transitiescenario’s.
Interoperabiliteit, open standaarden, contractuele waarborgen en jaarlijkse tests vormen samen de vier pijlers waarop een geloofwaardig cloudexitplan voor de rijksoverheid rust. Elk van deze pijlers is afzonderlijk onvoldoende: alleen de combinatie leidt tot een exitplan dat bij regulatoire toetsing en in een daadwerkelijk exitscenario stand houdt.
Veelgestelde vragen
Wat is het verschil tussen een exitplan en een disaster recovery plan?
Een disaster recovery plan beschrijft hoe een organisatie herstelt na een technisch incident bij de huidige leverancier. Een exitplan beschrijft hoe een organisatie een cloudleverancier gecontroleerd en volledig verlaat, inclusief datamigratie, contractafwikkeling en overgang naar een alternatieve omgeving. Een exitplan bevat bovendien soevereiniteitselementen, zoals een jurisdictieanalyse en open-standaardenvereisten, die in een DRP niet thuishoren.
Welke scenario’s moeten minimaal zijn uitgewerkt in een exitplan onder Rijkscloudbeleid 2026?
Het Rijkscloudbeleid schrijft minimaal drie scenario’s voor: een gepland leveranciersvertrek (contracteinde of strategische keuze), een ongepland vertrek (faillissement of eenzijdige intrekking van de dienst), en een noodscenario waarbij de leverancier niet meer bereikbaar is of de gegevensoverdracht weigert. Voor elk scenario moeten RTO en RPO zijn vastgelegd en jaarlijks getest.
Wat houdt CADA artikel 30 Union assurance level 1 in voor een cloudexitplan?
Level 1 (Basic) van het EUCS-schema is het minimumniveau voor publieke aanbesteding. Voor een exitplan betekent dit dat de leverancier aantoonbare portabiliteits- en interoperabiliteitsgaranties moet bieden, zodat data en processen overdraagbaar zijn naar een gecertificeerde alternatieve leverancier. Geclassificeerde overheidsdata vereist Level 2 of hoger.
Hoe helpen open standaarden bij het voorkomen van data-lock-in?
Open standaarden zoals OpenDocument Format, CalDAV, CardDAV en WebDAV zorgen ervoor dat data zonder conversieverlies overdraagbaar is. De EU Data Act verplicht cloudaanbieders per september 2025 tot ondersteuning van portabiliteitsrechten en interoperabele interfaces, wat de wettelijke basis versterkt voor een technisch uitvoerbaar exitplan.
Welke contractuele clausules zijn essentieel bij cloudleveranciers buiten de EU/EER?
Minimaal vereist zijn: expliciete dataportabiliteitsrechten in open formaten, een exporttermijn van minimaal 30 dagen na contractbeëindiging, een verbod op gebruik van klantdata voor AI-training, een jurisdictieclausule die EU-recht als exclusief toepasselijk recht aanwijst, en een auditrecht voor jaarlijkse verificatie van de exitprocedure. De Cloud III DPS exitclausules bieden hiervoor een bruikbaar standaardraamwerk bij rijksaanbestedingen.
