Draait je organisatie belangrijke systemen in de cloud of op software van een ander, dan vraagt iemand je binnenkort om een exitplan. Voor de rijksoverheid en haar uitvoeringsorganisaties, Defensie uitgezonderd, is dat sinds 3 juli beleid. Elk materieel cloudgebruik heeft nu een gedocumenteerd exitplan nodig, door de organisatie zelf getoetst, voor twee scenario's: een geplande exit en een plotselinge onderbreking. Beide worden elk jaar beoordeeld, en waar de cloud al in gebruik is, moet het plan er in juli 2027 liggen, twaalf maanden na de vaststelling van het beleid. Andere overheidsorganisaties, zoals gemeenten en waterschappen, krijgen het advies het beleid te volgen. Banken, verzekeraars, pensioenfondsen en vermogensbeheerders kennen een versie van die vraag al langer, uit de regels voor uitbesteding en IT-risico die hun toezichthouders handhaven.
Veel organisaties zullen de vraag om een exitplan beantwoorden met de exitstrategie die hun inkoopafdeling in het contract heeft gezet: het recht om op te zeggen, de data terug in een standaardformaat, een overgangsperiode. De Kamerbrief bij het nieuwe beleid stelt zelf vast dat de huidige exitstrategieën vaak vooral gaan over de eis dat de cloudleverancier bij een exit de data overdraagt en na vertrek vernietigt. Dat is het deel van een exit dat op papier werkt.
Wat een contractclausule niet regelt
In augustus meldde ShapeBlue, een bedrijf dat organisaties helpt om van VMware af te stappen, dat elke openbare downloadpagina voor een klein stuk VMware-software een foutmelding gaf. Die software heet VDDK, de Virtual Disk Development Kit. Veel migratie- en back-uptools gebruiken die om de schijven van een virtuele machine van buiten VMware te lezen, en meestal is het de snelste manier om ze te verhuizen. De licentie staat geen vrije herdistributie toe; alleen partners met een getekende overeenkomst mogen de software meeleveren.
In september bevestigde Broadcom, de eigenaar van VMware, dat het de openbare VDDK-downloads had ingetrokken en dat de software nu alleen via geselecteerde partners beschikbaar is, voor back-up en herstel. Andere routes werken nog, maar sommige zijn trager, zoals eerst elke machine exporteren, en andere hangen af van hoe de opslag is ingericht. De software viel onder geen enkel klantcontract: volgens Broadcom hoorde die nooit bij wat klanten kochten.
Er is een verschil tussen een exit die je mag maken en een exit die je kunt maken. Een contract kan je het recht geven om te vertrekken. Het kan je niet vertellen of de systemen rond je data mee kunnen, hoe lang de verhuizing duurt, wat het kost zolang je twee omgevingen draait, of welk land er met zijn wetgeving bij kan op de dag dat je weg moet. Dat zijn architectuurvragen, en die moet je per systeem beantwoorden, omdat elk systeem om een andere reden vastzit.
Vier vragen per systeem
Voor elk systeem dat ertoe doet, komt een exitstrategie neer op vier vragen, en een bestuur heeft de antwoorden nodig voordat het over een exitplan kan beslissen. Opgeschreven vormen de antwoorden een kaart: één rij per systeem, één kolom per vraag, met bij elk antwoord een naam.
Kunnen we weg? Komt de data compleet en bruikbaar terug, en kan het werk dat erop draait ergens anders gebeuren? Een systeem dat zijn data wel exporteert maar zijn logica in de eigen workflows van de leverancier houdt, verlaat je alleen door die logica opnieuw te bouwen.
Hoe lang duurt het? De realistische doorlooptijd van de verhuizing, inclusief de afhankelijkheden die niemand op een lijst zette: de inlogvoorziening, het integratieplatform, de migratietool die leunt op software van de leverancier die je verlaat. Schrijf op waar dat getal op gebaseerd is: een proefmigratie, het woord van de leverancier of een gok.
Wat kost het? De migratie zelf, de maanden waarin oud en nieuw naast elkaar draaien, en de prijs van het alternatief. Hier lopen een geplande en een gedwongen exit uiteen. Een exit die je zelf kiest, kun je vooraf plannen en testen; een exit die een leverancier je oplegt door te stoppen, niet.
Onder welk recht? Wie de leverancier bezit, waar de data en het beheer zitten, en de autoriteiten van welk land toegang kunnen eisen. In juli weigerde de voorzieningenrechter in Rotterdam het verbod te schorsen dat de staatssecretaris van Economische Zaken had opgelegd op de verkoop van Solvinity aan de Nederlandse dochter van het Amerikaanse Kyndryl. Solvinity verzorgt de hosting van DigiD, de inlogdienst van de overheid. Het verbod berust op een risico dat de staatssecretaris zag: dat de Amerikaanse overheid na de verkoop toegang zou kunnen krijgen tot de gevoelige gegevens waar Solvinity bij kan. Dat zou kunnen op grond van Amerikaanse wetgeving, via de Amerikaanse moedermaatschappij van die Nederlandse dochter. De rechter vond dat de staatssecretaris zich op het standpunt kon stellen dat de overname het publiek belang bedreigt. Kyndryl liet in augustus weten dat de overname door het verbod niet doorgaat en dat het bedrijf het besluit niet aanvecht; Solvinity zet haar bezwaar voort.
De Rotterdamse rechter gaf de staatssecretaris ook iets mee voor de beslissing op het bezwaar van Solvinity: ga nader in op de mogelijkheid om de data zo te versleutelen dat Solvinity die niet kan lezen. De sleutel ligt dan bij de overheid zelf of bij een derde. De zaak laat zien dat de vraag net zo goed over eigendom gaat als over de plek waar de servers staan, en dat een deel van het antwoord in de architectuur kan liggen. Het is een voorlopige uitspraak: begin oktober was er nog geen beslissing op het bezwaar bekend, en ook die beslissing kan weer aan de rechter worden voorgelegd.
Twee scenario's, elk jaar opnieuw beoordeeld
De twee scenario's leveren verschillende kaarten op: een systeem dat bij een geplande exit makkelijk te verlaten is, kan bij een plotselinge onderbreking het zwakste punt zijn. Bij een geplande exit draait het om kosten en volgorde: welk systeem eerst, welk contract wanneer afloopt, wat in hetzelfde jaar mee kan. Bij een plotselinge onderbreking is de leverancier morgen weg, failliet, verkocht of afgesneden, en is de vraag welke diensten je draaiende kunt houden en hoe lang.
Beide kaarten veranderen elk jaar, omdat systemen worden vervangen en leveranciers van eigenaar wisselen. Daarom vraagt het beleid om een jaarlijkse beoordeling, en is een plan dat je één keer schrijft bij de volgende begrotingsronde al verouderd. De herziening is goedkoop als de eerste kaart vastlegde wie elke vraag beantwoordde en op basis waarvan. Zo niet, dan is het een nieuw project.
Wat het kost, en wat het niet oplost
Om je meest kritieke systemen zo in kaart te brengen, heb je de mensen nodig die ze kennen: de applicatie-eigenaren, een architect en iemand die de contracten leest. Het beleid komt zonder extra budget, dus hun tijd concurreert met al het andere. Wat het kost om het niet te doen, merk je later en op een slecht moment: als een leverancier zijn prijzen of voorwaarden verandert en je moet onderhandelen vanuit een positie die je niet kunt meten.
De kaart geeft een bestuur per systeem de feiten voor een besluit. Ze lost niet alles op. De juridische kolom is het minst stabiel: de uitspraak in Rotterdam is voorlopig, en de eerste jaarlijkse beoordelingen onder het nieuwe beleid moeten nog laten zien wat de overheid accepteert.
Waar begin je?
Neem de drie systemen die je organisatie het minst kan missen. Schrijf per systeem op of je ervan weg kunt, hoe lang dat zou duren, wat het zou kosten en onder welk recht het valt, met bij elk antwoord de naam van wie het gaf. Een vraag waar niemand antwoord op heeft, is het eerste punt van je exitplan.
Jacques Domenie leidde de IT-functie van een bank onder toezicht van de centrale bank en legde verantwoording af aan bestuur, toezichthouders en accountant. Via Delfen (delfen.com) werkt hij een deel van de week voor organisaties.
Contact: domenie@delfen.com of delfen.com/nl/contact. De dienst Exit map staat beschreven op delfen.com/nl/diensten.
Bronnen
- Herziening rijksbreed cloudbeleid 2026 — Rijksoverheid, vastgesteld 3 juli 2026. Paragraaf 3.2 regelt het exitplan met twee scenario's en de jaarlijkse beoordeling; voetnoot 12 geeft bestaand materieel cloudgebruik twaalf maanden voor een exitplan.
- Kamerbrief Herziening Rijksbreed Cloudbeleid 2026 — Kamerbrief bij het beleid, staatssecretaris van Economische Zaken en Klimaat, 3 juli 2026 (Kamerstuk 26 643, nr. 1541)
- Verordening (EU) 2022/2554, de Digital Operational Resilience Act (DORA) — artikel 2, lid 1: banken, beheerders van beleggingsfondsen, verzekeraars en pensioenfondsen vallen eronder; artikel 28, lid 8: exitstrategieën en gedocumenteerde, geteste en periodiek herziene exitplannen voor ICT-diensten die kritieke of belangrijke functies ondersteunen; van toepassing sinds 17 januari 2025
- Broadcom Removes VDDK Pages Without Explanation: What You Need to Know — Marco Sinhoreli, ShapeBlue, 25 augustus 2026 (later gecorrigeerd)
- Broadcom confirms it revoked public VMware migration tool access — Beth Pariseau, TechTarget, 9 september 2026 (verklaring van Broadcom)
- Rechtbank Rotterdam, voorlopige voorziening over het verbod op de overname van Solvinity (ECLI:NL:RBROT:2026:8586) — 14 juli 2026
- Solvinity (van DigiD) mocht inderdaad niet overgenomen vanwege de CLOUD Act — Arnoud Engelfriet, Ius Mentis, 15 juli 2026
- Amerikaans bedrijf dat Solvinity wilde kopen, heeft het opgegeven — Redactie iBestuur, 26 augustus 2026
- Digital sovereignty is a mapping problem, not a vendor problem — Delfen, juli 2026 (Engelstalig)
- Exit map: welke systemen kunt u werkelijk verlaten? — Delfen