Samenvatting

Nederlandse gemeenten zijn voor hun dienstverlening sterk afhankelijk van niet-Europese cloudaanbieders. Dit brengt risico’s met zich mee op het gebied van digitale soevereiniteit, compliance en de continuïteit van de dienstverlening. Dit artikel biedt IT-professionals, informatiebeveiligings- en privacyprofessionals en auditors een raamwerk om gemeenten die dit risico willen adresseren meer regie te bieden.

Om organisaties in staat te stellen meer regie te nemen over hun digitale infrastructuur zijn er inmiddels Europese alternatieven beschikbaar. Deze alternatieven zijn echter nog niet altijd geschikt en schaalbaar, waardoor een directe en volledige overstap vaak nog niet mogelijk is. Dit artikel beoogt daarom om de afhankelijkheid van Nederlandse gemeenten proactief te beheersen. Het raamwerk dat wordt gepresenteerd geeft gemeenten inzicht in hun huidige afhankelijkheid, weegt de risico’s van beschikbare Europese alternatieven en stelt een gefaseerde exit- en/of migratiestrategie op, waarbij de dienstverlening zo min mogelijk wordt verstoord. Het is hierbij van belang om op te merken dat een directe migratie niet een doel op zich is. Het doel is het creëren van regie voor Nederlandse gemeenten op het gebied van clouddienstverlening door het beschikbaar stellen van een exitstrategie. Het raamwerk benadrukt het belang van continue evaluatie, security-by-design, digitale soevereiniteit, bedrijfscontinuïteit en sectorale afstemming. Hierbij worden functionele, juridische en geopolitieke risico’s afgewogen. Beperkingen en richtingen voor vervolgonderzoek worden besproken, evenals de implicaties voor beleid en de praktijk.

Inleiding

Nederlandse gemeenten opereren binnen een snel veranderend technologisch en geopolitiek landschap. De digitalisering van publieke dienstverlening heeft geleid tot aanzienlijke efficiëntiewinsten en schaalbaarheid (Branderhorst & Ruijer, 2024), maar heeft tevens een structurele afhankelijkheid gecreëerd van commerciële, veelal niet-Europese cloudplatforms. Microsoft 365 (M365) domineert hierbij de markt, wat resulteert in een hoge mate van vendor lock-in (Deprins, 2020; Shaji George, 2024). Deze afhankelijkheid wordt verder versterkt door extraterritoriale wetgeving zoals de Amerikaanse Cloud Act, die Amerikaanse autoriteiten in staat stelt gegevens op te eisen die elders zijn opgeslagen (Terlouw, 2025a, 2025b). Dergelijke wetgeving staat haaks op Europese kaders zoals de AVG, Schrems II en de NIS2-richtlijn, wat het compliance-risico en de zorgen over digitale autonomie vergroot (Terlouw, 2025b; Zwets, 2025).

Hoewel de urgentie van digitale soevereiniteit steeds breder wordt erkend, ontbreekt het gemeenten vaak aan gestructureerde instrumenten om cloudafhankelijkheid te mitigeren. Cloud governance – het definiëren en borgen van regels, verantwoordelijkheden en controles rond clouddienstgebruik – is nog niet structureel geïmplementeerd binnen de Nederlandse gemeentelijke praktijk (Boon, 2024). Tegelijkertijd wijzen praktijkvoorbeelden uit dat een directe overstap naar Europese alternatieven op korte termijn vaak niet haalbaar is, zoals blijkt uit de ervaringen van de Belastingdienst en de gemeente Amsterdam (Hofmans, 2025; NOS, 2026).

Dit artikel beoogt deze kloof te overbruggen door een academisch en praktisch toepasbaar raamwerk te presenteren voor een M365-exitstrategie, specifiek toegespitst op Nederlandse gemeenten. De centrale onderzoeksvraag luidt: Hoe kunnen Nederlandse gemeenten hun afhankelijkheid van Microsoft Office 365 proactief verminderen?

Uitgangspunten van het raamwerk

De discussie rond cloudexitstrategieën vindt zijn oorsprong in de financiële sector, waar vendor lock-in en operationele continuïteit al vroeg als kritieke risico’s werden geïdentificeerd (Cloud Banking Forum, 2020; Deprins, 2020). In de publieke sector is deze literatuur minder uitgewerkt, terwijl de impact van cloudafhankelijkheid op digitale soevereiniteit en compliance ook in deze sector groot is (Bria et al., 2025; Sheikh, 2022).

Bestaande exitmodellen leggen vaak de nadruk op kostenreductie en technische haalbaarheid, maar negeren vaak de institutionele, juridische en geopolitieke dimensies die voor overheden cruciaal zijn (Shaji George, 2024; Voort, 2022). We passen het originele raamwerk daarom aan voor gemeenten door de nadruk te leggen op vier overkoepelende thema’s: security-by-design, digitale soevereiniteit, bedrijfscontinuïteit en sectorale afstemming. Deze thema’s komen terug in elke stap van het raamwerk. Indien relevant, kan digitale transformatie (met mogelijke subthema’s duurzaamheid en vertrouwen) als optioneel thema worden toegevoegd.

Security-by-design

Dit omvat het integraal meenemen van cyberbeveiliging in het ontwerp, de ontwikkeling, de implementatie en het beheer van systemen en diensten. Met ‘integraal meenemen’ doelen we op het scenario waarbij cyberbeveiliging in de gehele cyclus van een systeem of dienst wordt meegenomen. Hiermee worden beveiligingsrisico’s structureel beperkt en hoeven ze niet achteraf op te lossen (Lagarde Groep, z.d.).

Digitale soevereiniteit

Dit duidt op de mate waarin een organisatie regie behoudt over haar data en systemen. Het gaat hierbij specifiek over juridische en bestuurlijke controle over de digitale infrastructuur.  Dit omvat ook de zeggenschap over opslag, verwerking, toegang, afhankelijkheden van leveranciers en relevante wet- en regelgeving (Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, 2025).

Bedrijfscontinuïteit

Het vermogen van een organisatie om kritieke processen en dienstverlening te blijven uitvoeren of binnen vooraf bepaalde termijnen weer te herstellen, ook in het geval van een calamiteit. Op basis van een bedrijfsimpactanalyse (BIA) worden de hersteltijd (RTO) en het maximale dataverlies (RPO) bepaald. Het gaat hierbij om uitval van de dienstverlening door storingen, cyberincidenten of uitval van leveranciers (Alexiou, 2022).

Sectorale afstemming

Het afstemmen van beleid, standaarden, architectuur en voorzieningen binnen een sector. In dit geval richten we ons op de publieke sector. Middels sectorale afstemming kan er gezamenlijk worden gewerkt aan uniforme standaarden, interoperabiliteit, kennisdeling en een efficiënte inzet van middelen. In de gemeentelijke context houdt dit in dat gemeenten onderling en/of samen met de Vereniging van Nederlandse Gemeenten (VNG) risico’s en afhankelijkheden in kaart brengen en desgewenst gezamenlijke maatregelen kunnen treffen.

Het circulaire zevenfasenmodel voor gemeenten

Het circulaire zevenfasenmodel is ontwikkeld door Microsoft General (2020) en werd oorspronkelijk ontwikkeld voor financiële instellingen. We passen het raamwerk toe op de specifieke context van Nederlandse gemeenten: beperkte digitale soevereiniteit, compliance-vereisten en de beperkte beschikbaarheid van volwassen Europese alternatieven. De circulaire structuur benadrukt dat een exitstrategie geen lineair project is, maar een iteratief governanceproces dat continu moet worden geactualiseerd op basis van interne en externe ontwikkelingen. Hierdoor sluit het aan bij recente ontwikkelingen in de publieke IT-strategie, waarbij digitale weerbaarheid wordt benaderd als een dynamisch, iteratief proces in plaats van een statisch eindpunt (Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, 2023).

Het raamwerk biedt een basisstructuur en vereisten die aangepast moeten worden aan de juridische, technische en (geo)politieke context van elke gemeente die besluit deze strategie toe te passen. Hoewel het Microsoft General-raamwerk een praktische structuur biedt, geeft het de voorkeur aan het behoud van de cloudleverancier door de nadruk te leggen op de kosten en inspanningen die nodig zijn om de terugtrekking uit te voeren. De hoge investering kan gerechtvaardigd worden door het hebben van een onderhouden exitstrategie (of deze al te hebben uitgevoerd) wanneer zich een incident voordoet waarop extraterritoriale wetgeving zoals de Amerikaanse Cloud Act van toepassing is. Het raamwerk probeert een balans te vinden tussen enerzijds het accepteren van het risico dat M365 voor gemeenten vormt en anderzijds het mitigeren van dat risico door een terugtrekking uit M365. Door gebruik te maken van literatuur over exitstrategieën, exitplannen, cloudmigratiestrategieën en cloudmigratieplannen, en deze toe te passen op een exitstrategie, wordt naar deze balans gezocht. Het raamwerk is specifiek ontwikkeld voor de Office-suite. Indien voor gemeenten het E5-abonnement relevant is, moet er rekening worden gehouden met de veiligheidsdiensten van Microsoft, zoals insider risk management-diensten of een aantal threat protection-diensten. Denk aan Privileged Access Management, Microsoft Defender XDR en Microsoft Defender for Office 365 (Plan 1 en 2) (Microsoft Corporation, 2026).

Het circulaire zevenfasenmodel voor gemeenten wordt hieronder grafisch weergegeven. Daarop volgt de verdere uitwerking van de fasen.

Fase 1: Planning en analyse

In de initiële fase worden de governancestructuur en de scope van de exitstrategie gedefinieerd. Een multidisciplinair coördinatieteam — bestaande uit onder meer een cloudarchitect, IT-leidinggevende (bijv. CIO), juridisch adviseur, CISO, compliance-specialist, en leveranciersmanager — wordt verantwoordelijk gesteld voor de ontwikkeling, borging en uitvoering van de exitstrategie. Het team bepaalt de scope, formuleert KPI’s en waarborgt de overkoepelende thema’s (security-by-design, digitale soevereiniteit, bedrijfscontinuïteit en sectorale afstemming). Het multidisciplinair coördinatieteam kan ervoor kiezen om meer overkoepelende thema’s te overwegen indien dit gewenst is. Een mogelijke toevoeging kan digitale transformatie zijn waar duurzaamheid en vertrouwen onderdeel van kunnen uitmaken.

De scopebepaling vereist een gedetailleerde inventarisatie van M365-diensten, datatypen en onderlinge afhankelijkheden. Een onderscheid tussen de huidige essentiële en optionele diensten faciliteert het definiëren van minimale vereisten voor alternatieven. Een stakeholderanalyse (interne gebruikers, externe partners en burgers) en een bedrijfsimpactanalyse (BIA) identificeren de kritieke processen en de impact van eventuele uitval. Tevens wordt onderzocht of data-opschoning wenselijk is om migratiecomplexiteit te reduceren en om persoonsgegevens te identificeren ten behoeve van prioritering.

Hieronder volgen voorbeeldvragen waar een multidisciplinair coördinatieteam gebruik van kan maken voor de planning- en analysefase:

Inventarisatie van M365-diensten

1. Van welke M365-diensten maken we gebruik?
2. Welke M365-diensten zijn kritiek, ondersteunend of optioneel?
3. Welke M365-diensten hebben onderlinge afhankelijkheden?
4. Welke M365-diensten vallen binnen de scope?
5. Welke processen binnen de gemeente zijn afhankelijk van de M365-diensten die binnen de scope vallen?

Data-inventarisatie en -classificatie

1. Welke datatypes zijn aanwezig per M365-dienst?
2. Welke data bevatten persoonsgegevens?
3. Welke data is kritisch voor bedrijfsprocessen?
4. Welke data staat op welke locatie? (Bijvoorbeeld: de data staat binnen M365-diensten, de data staat buiten M365-diensten en is afhankelijk van M365-diensten, of de data staat buiten M365-diensten en is onafhankelijk van M365-diensten.)
5. Welke data kan geminimaliseerd worden? (Dit kan bijvoorbeeld gebaseerd zijn op bewaartermijnen of niet langer bruikbare data.)

Stakeholderanalyse

1. Welke interne stakeholders zijn afhankelijk van welke M365-diensten?
2. Is er een mogelijkheid tot prioriteren tussen interne stakeholders?
3. Welke leveranciers zijn afhankelijk van M365-diensten?
4. Welke klantportalen of samenwerkingen zijn afhankelijk van M365-diensten?
5. Welke communicatie naar stakeholders is vereist om een exit soepel te laten verlopen?

BIA

Wat zijn de kritieke organisatieprocessen?

1. Welke M365-diensten ondersteunen de geïdentificeerde kritieke processen?
2. Wat is de impact bij een uitval van deze M365-diensten? (Bijvoorbeeld financieel, operationeel en qua reputatie.)
3. Welke processen hebben prioriteit tijdens een migratie of rollback?
4. Wat is de maximale acceptabele downtime per kritiek proces en de maximale acceptabele frequentie van downtime per kritiek proces?

Overkoepelende vragen

1. Welke compliance- en auditkaders moeten worden gevolgd en kunnen worden beïnvloed door een M365-exit?
2. Welke afhankelijkheden zijn er met lopende contracten (bijvoorbeeld opzegtermijnen) en zijn de geassocieerde contractverplichtingen afhankelijk van M365-diensten?

Fase 2: Risicobeoordeling

De risicobeoordeling bepaalt of een exitstrategie wordt geactiveerd, gepauzeerd of bijgesteld. Om een goed geïnformeerde risicobeoordeling te kunnen realiseren, wordt er gebruikgemaakt van meerdere risicofactoren.

De eerste risicofactor is gebaseerd op de conclusies van een kwaliteitscriteriabeoordeling (Quality of Service, QoS) van de huidige in gebruik zijnde clouddienst. Naast de verhoogde zorgen over digitale soevereiniteit is de beoordeling van de clouddienst die in gebruik is tijdens fase 2 een belangrijke factor om te kunnen bepalen of een exit gewenst is. Het resultaat van een QoS wordt onder andere gebaseerd op eisen die worden gesteld vanuit gemeenten, zoals naleving van wet- en regelgeving (bijvoorbeeld informatiebeveiliging en gegevensbescherming), beschikbaarheid van de clouddienst, aantoonbare beveiligingseisen (bijvoorbeeld een incidentbeheerproces, wijzigingsbeheer, back-up en recovery), prijs en prestatie-indicatoren.

De tweede risicofactor is gebaseerd op de conclusies van een beoordeling betreffende de betrouwbaarheid van de huidige clouddienst. De betrouwbaarheid van een clouddienst is een losse beoordeling om de focus te kunnen leggen op continuïteit, veiligheid en wetgeving, in plaats van op de operationaliteit en techniek van een QoS-beoordeling. De huidige cloudaanbieder wordt geëvalueerd aan de hand van gestandaardiseerde beoordelingen, zoals de Cloud Service Provider Trust Assessment van Jaaouani en Bobbert (2023), die 64 betrouwbaarheidsfactoren omvat.

In de praktijk bevat een QoS-beoordeling vaak al continuïteits-, veiligheids- en wetgevingsaspecten. Het is verstandig om een losse betrouwbaarheidsbeoordeling uit te voeren, ondanks het feit dat deze aspecten niet hoeven te worden verwijderd uit een QoS-beoordeling. Hierdoor kunnen gemeenten makkelijker bewust een conclusie van de QoS- of betrouwbaarheidsbeoordeling zwaarder laten wegen, afhankelijk van de belangen van de gemeente. Dit is relevant omdat de belangen van een gemeente kunnen veranderen per risicobeoordeling, aangezien het een momentopname betreft.

Gebaseerd op de vier overkoepelende thema’s van dit artikel zijn verschillende hedendaagse risico’s relevant om mee te nemen in de risicobeoordeling. Een aantal risico’s raakt meerdere thema’s. Zo zijn prijsvolatiliteit, geopolitieke onzekerheid en het complianceniveau van Europese en Nederlandse beveiligingskaders relevante risico’s voor zowel bedrijfscontinuïteit, digitale soevereiniteit en sectorale afstemming. Daarnaast zijn de beschikbaarheid en volwassenheid van Europese alternatieven relevante risico’s voor zowel security-by-design als bedrijfscontinuïteit. Gezien het relatief beperkte marktaandeel van Europese aanbieders is het belangrijk om de stabiliteit van leveranciers en de ontwikkeling van hun product roadmap vanuit een risicogebaseerd perspectief te beoordelen (Cloud Banking Forum, 2020; Lang et al., 2018; Shaji George, 2024).

Verder zijn concrete voorbeelden van risico’s die voortvloeien uit de vier overkoepelende thema’s ook relevant om te overwegen, bijvoorbeeld:

• Veilige standaardconfiguraties. Vanuit het thema security-by-design vormt het ontbreken van veilige standaardconfiguraties een belangrijk risico. Wanneer beveiliging niet standaard is ingebouwd, kunnen kwetsbaarheden ontstaan. Daarnaast beperkt de complexiteit van het Microsoft 365-landschap het inzicht in de Microsoft-gebaseerde configuratiestandaarden, wat de kans vergroot op configuratiefouten in de beveiliging van een cloudalternatief. Bovendien zijn beveiligingsmaatregelen nu nog vaak afhankelijk van Microsoft, wat de complexiteit verder vergroot.
• Vendor lock-in. Binnen het thema digitale soevereiniteit is de afhankelijkheid van één leverancier een belangrijk risico. Vendor lock-in maakt een overstap naar alternatieve oplossingen kostbaar en complex, en beperkt daarmee de autonomie van organisaties. Daarnaast leidt deze afhankelijkheid tot onzekerheid over de verwerking van gegevens en de mogelijke toegang door buitenlandse overheden.
• Beschikbaarheid. Voor bedrijfscontinuïteit vormt de beschikbaarheid van dienstverlening het belangrijkste aandachtspunt. Uitval of verstoring van essentiële digitale diensten kan de uitvoering van gemeentelijke taken direct verstoren. Dit is voor gemeenten extra relevant, omdat de meest kritische processen gebonden zijn aan wet- en regelgeving en kritieke dienstverlening moet kunnen doorgaan of moet worden hersteld binnen vastgestelde termijnen.
• Het hanteren van verschillende beveiligingsniveaus. Een gebrek aan sectorale afstemming brengt het risico met zich mee dat gemeenten verschillende beveiligingsniveaus hanteren en onvoldoende gezamenlijke afspraken maken over compliance-eisen aan leveranciers. Dit leidt tot ketenrisico’s en vermindert de mogelijkheid om als sector gezamenlijk invloed uit te oefenen op de beveiliging, compliance en doorontwikkeling van digitale dienstverlening van leveranciers.

De kwaliteitscriteriabeoordeling en de betrouwbaarheidsbeoordeling van cloudalternatieven worden hier niet meegenomen omdat de voorselectie van mogelijke cloudalternatieven in fase 3 wordt uitgevoerd. De nadruk in fase 2 ligt op het beoordelen of de huidige clouddienst voldoende is, gebaseerd op de beoordeling van de dienst zelf en de belangen van de gemeente met betrekking tot continuïteits-, veiligheids- en wetgevingsaspecten.

Fase 3: Het doel van de exitstrategie vaststellen

Het primaire doel van de exitstrategie is de (gedeeltelijke) migratie naar een Europese of open-source cloudaanbieder die voldoet aan soevereiniteits- en compliance-eisen. Hierin zijn variaties nog te bepalen:

• Wordt het doel een gedeeltelijke migratie?
• Naar welk alternatief zal worden gemigreerd?
• Welk deploymentmodel zal worden gebruikt voor het alternatief?

In deze fase wordt het doel zoveel mogelijk vastgesteld, waarna het doel wordt uitgebreid tot een concreet toekomstbeeld in fase 4.

Het primaire doel is niet te verwarren met het overkoepelende doel van het exitstrategie-raamwerk om een gemeente gereed te maken voor een mogelijke exit wanneer dit nodig blijkt. Indien uit de risicobeoordeling blijkt dat een exit niet nodig is, dan is deze exitstrategie nog te gebruiken als voorbereiding op een toekomstige exit wanneer er geconcludeerd wordt tijdens één van de periodieke risicobeoordelingen dat een exit gewenst is (zie fase 7). Hierbij kan er ruimte worden gecreëerd door de gemeenten om niet alle informatie voor de exitstrategie concreet te maken, omdat er momentopname-gevoelige beslissingen moeten worden genomen om deze exitstrategie in volledigheid voor te bereiden.

Afhankelijk van hoe de alternatieve cloudaanbieder zal worden geïmplementeerd en gebruikt, moet in deze fase het doel nog verder worden bepaald. Voordat gemeenten beslissen naar welk alternatief ze willen migreren, hebben ze de mogelijkheid om te evalueren welk type deploymentmodel ze willen gebruiken. Door het gewenste deploymentmodel vóór de selectie van een alternatieve clouddienst te definiëren, kan de mogelijkheid tot het gewenste deploymentmodel de selectie beïnvloeden.

Deploymentmodellen zoals de publieke cloud, privécloud, hybride cloud of multi-cloud zijn te overwegen. Het is mogelijk om (gedeeltelijke) on-premise hosting te overwegen voor de meest kritieke gegevens. Hierbij wordt een hybride cloud over het algemeen beschouwd als een ideaal model. Daarnaast is de verwachting dat de uitgaven voor externe clouddiensten vanaf nu zullen afnemen. Hierdoor is te concluderen dat de hybride cloud een werkbaar alternatief is voor de publieke clouddienst M365 (Shaji George, 2024). Een ander element om rekening mee te houden is het argument voor sectorbrede clouddeployments. Dit maakt ook meer maatwerk mogelijk, waardoor flexibiliteit toeneemt en innovatie kan worden afgestemd op specifieke behoeften binnen de sectorale gemeenschap (Shaji George, 2024). Op dit moment is zo’n sectorbrede deployment niet beschikbaar voor een Europees alternatief om M365 één-op-één te vervangen. Het ondersteunen van een dergelijke sectorbrede implementatie zou de digitale soevereiniteit wel versterken.

Alternatieven identificeren

Gemeenten kunnen gebruikmaken van bronnen zoals European Alternatives (Graf, z.d.) en academische overzichten (Bria et al., 2025) voor een geïnformeerde voorselectie. Tabel 1 presenteert een gestructureerd overzicht van relevante alternatieven inclusief jurisdictie, bron, focusthema’s, een hyperlink naar additionele informatie en een korte omschrijving. Dit overzicht is beperkt tot de alternatieven die gebruikt zijn ter ondersteuning van het onderzoek van dit artikel. Het onderzoek is gelimiteerd tot een momentopname, waardoor er mogelijk meer alternatieven voor Microsoft 365 beschikbaar zijn.

Voorselectie van alternatieven

Om te voorkomen dat een gemeente het risico loopt om direct een exit te moeten maken zonder al te hebben besloten naar welk alternatief moet worden gemigreerd, moet er een voorselectie worden gemaakt. Dit is een voorselectie van de beschikbare cloudalternatieven om te bepalen welk alternatief de beste optie is om naartoe te migreren wanneer dit nodig blijkt. Deze voorselectie moet gebaseerd zijn op een cloudbeoordeling van de alternatieve cloudproviders, technische vereisten en mogelijkheden, betrouwbaarheid en factoren gebaseerd op digitale soevereiniteit. De vier overkoepelende thema’s van het exitstrategie-raamwerk zijn toepasbaar op de cloudbeoordeling als richtlijn voor welke aspecten beoordeling vereisen. Verder kunnen gemeenten gebruikmaken van ‘inkoop als strategisch instrument’ zoals omschreven door de VNG (2026). De VNG biedt meerdere informatiebronnen over het strategisch omgaan met inkoop in het kader van digitale autonomie.

Shaji George adviseert om te streven naar open source-consistentie, gedeelde standaarden en flexibiliteit voor een cloud exit (2024). Door het toevoegen van vereisten die gebaseerd zijn op digitale soevereiniteit en lokale en Europese wetgeving, kunnen gedeelde standaarden worden meegenomen in de voorselectie. Een vereiste op basis van digitale soevereiniteit die belangrijk is om te benoemen, is of Europese aanbieders onafhankelijk zijn van niet-Europese partners of investeerders die invloed hebben op de ontwikkeling en/of het onderhoud van het alternatief. Een voorbeeld hiervan is het Gaia-X-initiatief. Dit initiatief wordt bekritiseerd vanwege de afhankelijkheid die deelnemers hebben van Amerikaanse hyperscalers. Hierdoor zijn er twijfels ontstaan over de digitale soevereiniteit waar het initiatief voor staat (Bria et al., 2025; Sheikh, 2022). 

De meeste alternatieven zijn momenteel nog hun diensten aan het verbeteren, wat betekent dat het één-op-één vervangen van de huidige M365-diensten niet het belangrijkste criterium moet zijn. Echter, een alternatief dat aan dit criterium voldoet maakt de implementatie wel eenvoudiger. De overstap van M365 naar een Europees alternatief is te rechtvaardigen wanneer de migratie een oplossing biedt voor de zorgen over digitale soevereiniteit en naleving van EU-regelgeving. Wanneer een alternatief nog niet voldoende ontwikkeld is om gemeenten zonder twijfel te laten migreren naar het desbetreffende alternatief, is het belangrijk om te benadrukken dat gemeenten de ontwikkeling van een alternatieve cloudaanbieder kunnen ondersteunen of daarin een actieve rol kunnen spelen. Dit biedt gemeenten de kans om legacy-technologie van M365 te vermijden en meer regie te nemen in veiligheidsbeheer.

Voorbeeld van een voorselectie

Op basis van de bovenstaande voorselectieadviezen is een voorbeeldselectie gemaakt voor onderzoek naar alternatieven. De voorbeeldvoorselectie van de alternatieven is beschikbaar als bijlage. De inhoudelijke antwoorden op de vragen van deze voorbeeldvoorselectie zijn gevoelig voor veranderingen en moeten worden beschouwd als een momentopname.

Gemeenten kunnen deze voorbeeldvoorselectie gebruiken ter inspiratie. De gemaakte overwegingen kunnen door gemeenten worden meegenomen in hun voorselecties. Deze zijn onderverdeeld in drie thema’s en één overweging onder ‘overige’. De overwegingen zijn gebaseerd op de thema’s digitale soevereiniteit, wet- en regelgeving en functionaliteit. Het overkoepelende thema security-by-design komt terug in functionaliteit en  wet- en regelgeving. De overkoepelende thema’s bedrijfscontinuïteit en sectorale afstemming komen terug in digitale soevereiniteit en wet- en regelgeving.

Onder digitale soevereiniteit vallen de volgende overwegingen:

• Is het alternatief betrokken bij een ander alternatief?
• Heeft het alternatief partners buiten de EU?
• Maakt het alternatief gebruik van Deutsche Telekom of TIM (Telecom Italia Mobile)? (Een vraag gebaseerd op: Bria et al., 2025)
• Als laatste zijn de hoofdthema’s die het alternatief hanteert genoteerd ter overweging.

Voor wet- en regelgeving wordt overwogen of het alternatief NIS2-conform en/of ISO 27001-conform is. Er is geen overweging betreft AVG-conformiteit toegevoegd; echter komt privacy wel terug onder de hoofdthema’s van alternatieven wanneer dit van toepassing is.

Wat betreft functionaliteit wordt het volgende overwogen:

• Welke alternatieven voor M365-toepassingen, -systemen, -functies, etc. biedt het alternatief?
• Worden deze momenteel ontwikkeld of staan ze in de planning voor ontwikkeling?
• Welke interoperabiliteitsmogelijkheden biedt het alternatief?
• Maakt het alternatief gebruik van open source?
• De beschikbaarheid van het alternatief refereert aan welk type deployment-model(len) het alternatief beschikbaar stelt.
• Een nice-to-have: biedt het alternatief een zelfontwikkelde AI-agent die in de EU is gevestigd?
• Een tweede nice-to-have: biedt het alternatief een in de EU gevestigde AI-agent in een gesloten/beveiligde omgeving?

Tot slot is ‘Voordelen van het alternatief’ toegevoegd om overige geïdentificeerde voordelen vast te leggen, aangezien onverwachte voordelen zwaar kunnen wegen of zelfs de doorslaggevende factor kunnen zijn. Echter, naar deze voordelen is niet specifiek gezocht.

Fase 4: De toekomstige situatie schetsen

Gebaseerd op de voorselectie wordt er een alternatief gekozen als hét alternatief voor de huidige clouddienst. Deze fase vertaalt het gekozen alternatief naar een concreet toekomstbeeld, waarbij de kloof tussen de huidige en gewenste situatie wordt geanalyseerd (Voort, 2022). De kloof wordt geadresseerd door faciliterende aspecten te schetsen: technologische infrastructuur, hardware-/softwarelicenties, capaciteitsopbouw, training en mogelijke uitbesteding of werving. Aannames worden expliciet gemaakt en gemonitord, zoals voortdurende toegang tot M365 tijdens de transitie, stabiliteit van het alternatief en continueel leveranciersrisicobeheer. Idealerwijs worden keuzes afgestemd op (nog te ontwikkelen) nationale of Europese publiekesectorstandaarden om geforceerde migraties door toekomstige standaarden te voorkomen. Sectorbrede standaarden kunnen bijvoorbeeld refereren aan voorkeursalternatieven, maar ook aan gestandaardiseerde contracten en deploymentmodellen.

Voorbeeld van de toekomstige situatie schetsen

Afhankelijk van het gekozen alternatief in fase 3 en het onderzoek naar de huidige context van de organisatie in fase 1, kan het toekomstbeeld beter worden geschetst. Na de identificatie van de AVG en overige kritieke data van fase 1, kan een gemeente besluiten om deze data on-premise of off-premise te hosten. Indien zij het off-premise hosten, maakt de gemeente gebruik van hosting middels de faciliteiten van het alternatief. Daarnaast is het ook mogelijk om gebruik te maken van de software van het alternatief. Verder kan er voor het hosten gebruikgemaakt worden van een betrouwbare derde partij.

Wanneer een gemeente ervoor kiest om persoonsgegevens en/of kritieke data on-premise te hosten, dan wordt het doel van een hybride deploymentmodel uitgewerkt naar de vereiste subdoelen. Subdoelen hiervoor kunnen bijvoorbeeld zijn: het identificeren van hardware- en softwarevereisten, een bouwplan voor een on-premise datacentrum gebaseerd op een gedefinieerde hybride cloudarchitectuur, compatibiliteitstesten van de hybride omgeving voor het functioneren van applicaties tussen twee of meerdere omgevingen en het implementeren van een uniform security framework.

De doelen en subdoelen van de gewenste situatie, bijvoorbeeld een hybride deploymentmodel, moeten gedefinieerd worden om een zo volledig mogelijk exitplan te kunnen opstellen in de volgende fase.

Fase 5: Een exitplan voor de migratie opstellen

Het exitplan structureert de uitvoering in fasen: resource-inventarisatie, voorbereiding, tijdlijnen, pilot-testing en volledige migratie. Een kritisch onderdeel is het rollbackplan dat bedrijfscontinuïteit borgt bij mislukking. Verder wordt een risicoregister dynamisch onderhouden om te beoordelen of er aanpassingen van toepassing zijn in het exitplan tijdens de uitvoering ervan of dat het uitvoeren van het rollbackplan vereist is. Het is hierbij verstandig om van tevoren te definiëren welke mogelijke risico’s van toepassing zijn op het exitplan en deze risico’s actief te monitoren. Wanneer er nieuwe risico’s ontstaan, moeten deze worden toegevoegd aan het risicoregister. Risicomanagement kan worden geborgd middels risicomonitoring- en inventarisatiesessies met de uitvoerenden van het exitplan en stakeholders van de migratie. Hierbij zijn de monitoringintensiteit en -prioritering evenredig aan hoe kritisch de data en systemen zijn.

Het exitplan bevat onder andere technische, juridische en financiële componenten. Essentiële technische componenten zijn data-extractie, transformatie, versleutelde overdracht en Identity & Access Management (IAM) (Ong et al., 2017). Juridische componenten zoals verplichtingen, DPIA’s, dataverwerkingssovereenkomsten en dataclassificaties worden geborgd. Tot slot worden financiële componenten zoals een gedetailleerd budget tijdens testen gevalideerd en bijgesteld.

Overigens is er is bewust voor gekozen om geen voorbeeld toe te voegen van een exitplan, aangezien dit zeer afhankelijk is van de context van de organisatie gedurende het plannen van de migratie en hoe de vorige fases van het exitstrategie raamwerk zijn uitgevoerd. Indien gewenst is een nadere toelichting en een fictieve casus van een exitplan te vinden in het werk van Microsoft General (2020). Het is echter verstandig om de fictieve casus niet leidend te laten zijn voor het ontwikkelen van een eigen exitplan. Voor het ontwikkelen van een exitplan zijn de benodigdheden gebaseerd op de context van de gemeente, waarbij de unieke keuzes per gemeente leidend zijn.

Fase 6: Het exitplan testen

Het testen beoordeelt de haalbaarheid, doorlooptijd en rolhelderheid binnen het plan (Cloud Banking Forum, 2020). Het identificeert verouderde aannames en vereiste actualisering. De testen vereisen investeringen in tijd, middelen en expertise. Er wordt gezocht naar een balans tussen minimale testvereisten en een uitgebreide validatie. Naast deze essentie kan de test verder worden gebaseerd op de richtlijnen die door Cloud Banking Forum (2020) zijn omschreven.

De technische, juridische, financiële en overige componenten van het exitplan worden getest door bijvoorbeeld voor de technische testen gebruik te maken van monitoring tools, datamigratieprototypes en IAM-configuraties. Juridische testen valideren DPIA’s, contractuele afspraken en compliance. Financiële testen herzien budgetten op basis van beoogde kosten. Waar mogelijk wordt een tabletop-oefening gecombineerd met technische pilots. De volledige implementatietesten worden als aanvullend beschouwd vanwege kosten en complexiteit.

Fase 7: De strategie en het exitplan actualiseren

In de laatste fase wordt het exitplan geactualiseerd en wordt het risicoprofiel van de gemeente beoordeeld. De testresultaten van fase 6 leiden tot aanpassingen van het exitplan. Hierbij worden de eigenaars aangesteld voor acties. Verder evalueert de gemeente of het risicoprofiel is beïnvloed door interne en externe veranderingen. Externe factoren die het risicoprofiel kunnen beïnvloeden zijn wet- en regelgeving en geopolitieke- of marktinstabiliteit. Qua interne factoren zijn organisatiebrede capaciteit van zowel personeel als middelen en financiën mogelijk van belang. De beoordeling van het risicoprofiel wordt gebruikt voor actualisering tijdens de volgende iteratie van de exitstrategie.

Deze fase sluit de cirkel en vormt de basis voor de volgende iteratie. Na de voltooiing van de eerste iteratie wordt het raamwerk niet beschouwd als een statische strategie. Bij een besluit tot niet-migreren blijft een actieve exitstrategie noodzakelijk voor risicomitigatie en wordt een periodieke cyclus geïnitieerd. Dit betekent dat wanneer fase 1 wordt uitgevoerd na de eerste volledige iteratie, fase 1 wordt herhaald om de planning en analyse bij te werken. Vervolgens wordt er in fase 2 opnieuw een risicobeoordeling gemaakt om te beoordelen of de exitstrategie moet worden geactiveerd, gepauzeerd of bijgesteld. Ongeacht of de exitstrategie wordt geactiveerd moet in fase 3 beoordeeld worden of de selectie van het alternatief nog voldoet aan de wensen en benodigdheden van de gemeente. Afhankelijk van hoeveel fasen 1 tot en met 3 zijn gewijzigd ten opzichte van de voorgaande iteratie, worden fasen 4 tot en met 7 in minder of meer mate beïnvloed en bijgewerkt.

Microsoft General (2020) adviseert een jaarlijkse evaluatie van fase 7 om het exitplan te actualiseren. In deze exitstrategie wordt de evaluatie geborgd middels de periodieke cyclus van de gehele strategie. Gemeenten kunnen ervoor kiezen om de frequentie van de exitstrategiecyclus te verlagen in vergelijking met de jaarlijkse evaluatie van het exitplan van Microsoft General. De keuze voor het verlagen van de jaarlijkse frequentie is te onderbouwen doordat de gehele exitstrategie wordt bijgewerkt en niet alleen het exitplan. De periodieke cyclus moet aansluiten op de beschikbaarheid van de gemeente, zodat de cyclus proportioneel aan het risicoprofiel van de gemeente uitgevoerd kan worden. Gemeenten kunnen de frequentie van de periodieke cyclus verhogen bij geopolitieke- of marktinstabiliteit. Tot slot, wanneer een gedeeltelijke of volledige migratie is uitgevoerd wordt de exitstrategie opnieuw toegepast op het nieuwe cloudlandschap om zo het risico te mitigeren voor een (potentiële) volgende exit.

Discussie

Het voorgestelde raamwerk positioneert cloudexitstrategieën niet als een technisch migratieproject, maar als een structureel governance-instrument voor digitale soevereiniteit. Door het Microsoft-model te herinterpreteren verschuift de focus van kostenreductie naar risicobeheersing, compliance en institutionele autonomie.

Een sterke kant van het raamwerk is de circulaire structuur, die gemeenten in staat stelt proactief te handelen zonder overhaaste migraties te forceren. De integratie van de vier overkoepelende thema’s (security-by-design, digitale soevereiniteit, bedrijfscontinuïteit en sectorale afstemming) en de daaruit voortvloeiende juridische, technische en geopolitieke dimensies verhoogt de praktijkrelevantie.

Tegelijkertijd zijn er beperkingen gebonden aan het model. Ten eerste vereist de uitvoering aanzienlijke interne capaciteit en multidisciplinaire expertise, wat voor kleinere gemeenten een drempel kan vormen. Ten tweede zijn Europese alternatieven vaak nog niet volledig volwassen of gestandaardiseerd, wat interoperabiliteit en gebruikerstraining bemoeilijkt. Ten derde ontbreekt op dit moment een breed gedragen, sectorale cloudstandaard voor de publieke sector, wat kan resulteren in gefragmenteerde implementaties. Desondanks biedt het raamwerk een schaalbaar uitgangspunt dat gemeenten in staat stelt hun onderhandelingspositie te versterken, compliance-risico’s te mitigeren en op termijn bij te dragen aan de ontwikkeling van soevereine cloudinfrastructuur. Sectorale samenwerking, open-source adoptie en gestandaardiseerde governancekaders zijn hierbij cruciale hefbomen.

Conclusie en limitatie van onderzoek

Dit artikel presenteert een academisch onderbouwd raamwerk voor een Microsoft 365-exitstrategie, specifiek ontwikkeld voor Nederlandse gemeenten. Het circulaire zevenfasenmodel biedt een gestructureerde aanpak om afhankelijkheidsrisico’s proactief te mitigeren doordat het model wordt geherinterpreteerd vanuit digitale soevereiniteit, cloud governance en geopolitieke risicobeheersing. Het model benadrukt dat een exitstrategie geen eenmalig migratieplan is, maar een voortdurend proces van evaluatie, aanpassing en institutionele borging.

Belangrijkste leerpunten

De belangrijkste leerpunten per fase van de exitstrategie raamwerk zijn als volgt:

Fase 1: Planning en analyse

De governancestructuur wordt opgesteld door middel van een multidisciplinair coördinatieteam. Dit team wordt verantwoordelijk gesteld voor de ontwikkeling, borging en uitvoering van de exitstrategie. De scopebepaling vereist een gedetailleerde inventarisatie van M365-diensten, datatypen en onderlinge afhankelijkheden. Verder zijn een stakeholderanalyse en een BIA essentieel om de volledige scope van de exitstrategie te kunnen overzien. Het team formuleert KPI’s gebaseerd op de gedefinieerde scope en waarborgt de overkoepelende thema’s voor de gehele ontwikkeling en, indien relevant, de uitvoering van de exitstrategie. Dit betreft de thema’s security-by-design, digitale soevereiniteit, bedrijfscontinuïteit en sectorale afstemming.

Fase 2: Risicobeoordeling

Een risicobeoordeling bepaalt of een exitstrategie wordt geactiveerd, gepauzeerd of bijgesteld. Hierbij wordt er gebruik gemaakt van een kwaliteitscriteriabeoordeling en een betrouwbaarheidsbeoordeling van de huidige clouddienst.

Fase 3: Het doel van de exitstrategie vaststellen

Het primaire doel van de exitstrategie is de (gedeeltelijke) migratie naar een Europese of open-source cloudaanbieder die voldoet aan soevereiniteits- en compliance-eisen. Het primaire doel is niet te verwarren met het overkoepelende doel van het exitstrategie-raamwerk om een gemeente gereed te maken voor een mogelijke exit wanneer dit nodig blijkt door een cyclisch proces in te richten. Tijdens deze fase moet een gemeente al een voorkeur kunnen uitspreken voor een deploymentmodel of een paar deploymentmodellen. Deploymentmogelijkheden van alternatieven kunnen een verschil uitmaken bij de voorselectie van alternatieven. Vervolgens worden alternatieven geïdentificeerd en wordt er een voorselectie gemaakt.

Fase 4: De toekomstige situatie schetsen

Gebaseerd op de voorselectie wordt er een alternatief gekozen als hét alternatief voor de huidige clouddienst. Deze fase vertaalt het gekozen alternatief naar een concreet toekomstbeeld. Faciliterende aspecten worden geschetst en aannames worden expliciet gemaakt en gemonitord. Verder, indien dit mogelijk is, wordt hier afstemming gezocht met sectorbrede standaarden voor het gebruik van clouddiensten.

Fase 5: Een exitplan voor de migratie opstellen

Het exitplan structureert de uitvoering in fasen waarbij een rollbackplan essentieel is voor bedrijfscontinuïteit. Het plan bevat onder andere technische, juridische en financiële componenten. Een dynamisch risicoregister wordt onderhouden om de status van de uitvoering van het exitplan te kunnen beoordelen.

Fase 6: Het exitplan testen

De haalbaarheid, doorlooptijd en rolhelderheid binnen het plan worden beoordeeld door middel van testen (Cloud Banking Forum, 2020). Het identificeert verouderde aannames en vereiste actualisering. In deze fase worden de technische, juridische, financiële en overige componenten van het exitplan getest. Hierbij wordt door de bijkomende kosten gezocht naar een balans tussen minimale vereisten en een uitgebreide validatie.

Fase 7: De strategie en het exitplan actualiseren

In de laatste fase wordt het exitplan geactualiseerd en wordt het risicoprofiel van de gemeente beoordeeld. De testresultaten van fase 6 leiden tot aanpassingen van het exitplan en de gemeente evalueert of het risicoprofiel is beïnvloed door interne en externe veranderingen die het risicoprofiel kunnen beïnvloeden. De beoordeling van het risicoprofiel wordt gebruikt voor actualisering tijdens de volgende iteratie van de exitstrategie.

Deze fase sluit de cirkel en vormt de basis voor de volgende iteratie. Bij besluit tot niet-migreren blijft een actieve exitstrategie noodzakelijk voor risicomitigatie en wordt een periodieke cyclus geïnitieerd. Gemeenten kunnen ervoor kiezen om de frequentie van het exitstrategieraamwerk te verlagen in vergelijking met de jaarlijkse evaluatie van het exitplan van Microsoft General. De periodieke cyclus moet aansluiten op de beschikbaarheid van de gemeente om de cyclus te kunnen uitvoeren, proportioneel aan het risicoprofiel van de gemeente. Tot slot, wanneer een gedeeltelijke of volledige migratie is uitgevoerd moet het raamwerk opnieuw worden toegepast op het nieuwe cloudlandschap om het risico te mitigeren voor een (potentiële) volgende exit.

Limitaties

Het raamwerk is theoretisch en conceptueel ontwikkeld op basis van bestaande literatuur en publiek beschikbare case-inzichten. Empirische validatie binnen de Nederlandse gemeentelijke praktijk ontbreekt. Daarnaast zijn de functionele mogelijkheden van Europese alternatieven dynamisch en onderhevig aan snelle marktontwikkelingen, wat de generaliseerbaarheid op lange termijn beïnvloedt.

Aanzet voor vervolgonderzoek

Toekomstig onderzoek dient zich te richten op empirische validatie van het raamwerk via casestudies of action research binnen gemeenten. Daarnaast is onderzoek naar de effectiviteit van sectorale clouddeployments, open-source adoptiebarrières in de publieke sector en de juridische houdbaarheid van Europese cloudcontracten onder extraterritoriale wetgeving wenselijk. Kwantitatieve studies naar de kosten-batenverhouding van exitstrategieën versus vendor lock-in-risico’s kunnen beleidsmakers tevens ondersteunen.

Praktische implicaties

Gemeenten kunnen het raamwerk direct toepassen als strategisch instrument voor cloud governance, risicomanagement en digitale transformatie. Het aanmoedigen van intergemeentelijke samenwerking, het ontwikkelen van standaardcontracten, en het investeren in interne cloudexpertise zijn daarbij aanbevolen actielijnen.

Bronnen

Alexiou, S. (2022, 01 mei). Is Business Continuity Management still relevant. ISACA, 3(2022). https://www.isaca.org/resources/isaca-journal/issues/2022/volume-3/is-business-continuity-management-still-relevant?utm_source=chatgpt.com

Bria, F., Timmers, P., & Gernone, F. (2025, 13 februari). EuroStack – A European Alternative for Digital Sovereignty. Bertelsmann Stiftung. https://doi.org/10.11586/2025006

Branderhorst, E. M., & Ruijer, E. (2025). Digital leadership in local government: An empirical study of Dutch city managers. Local Government Studies, 51(3), 576–599. https://doi.org/10.1080/03003930.2024.2363368

Cloud Banking Forum. (2020, 4 juni). Cloud exit strategy – Testing of exit plans (Technical Paper). European Banking Federation. https://www.ebf.eu/wp-content/uploads/2020/06/EBF-Cloud-Banking-Forum_Cloud-exit-strategy-testing-of-exit-plans.pdf

Deprins, T. (2020, 23 november). Cloud exit strategies for financial services institutions. Microsoft Industry Blogs. https://www.microsoft.com/en-us/industry/blog/financial-services/2020/11/23/cloud-exit-planning-guidelines-for-financial-services-institutions/ 

Graf, C. (z.d.). European Alternatives. https://european-alternatives.eu/

Hartholt, S. (2025, 13 februari). Er mag niets met Microsoft gebeuren, want dan hebben we een probleem. Binnenlands Bestuur. https://www.binnenlandsbestuur.nl/digitaal/it-personeel/er-mag-niets-met-microsoft-gebeuren-want-dan-hebben-we

Hofmans, T. (2025, 2 oktober). Ook fiscus kan geen EU-alternatief voor Microsoft vinden en zet migratie door. Tweakers. https://tweakers.net/nieuws/239890/ook-fiscus-kan-geen-eu-alternatief-voor-microsoft-vinden-en-zet-migratie-door.html

Jaaouani, R., & Bobbert, Y. (2023, 3 februari). Cloud (sovereignty) trust assessment. LinkedIn. https://www.linkedin.com/pulse/cloud-trust-assessment-yuri-bobbert/

Lagarde Groep. (z.d.). Wat is security by design? IT-Security. https://it-security.nl/kennisbank/security-by-design/

Lang, M., Wiesche, M., & Krcmar, H. (2018, 01 september). Criteria for selecting cloud service providers: A Delphi study of quality-of-service attributes. Information & Management, 55(6), 746–758. https://doi.org/10.1016/j.im.2018.03.004

Microsoft Corporation. (2026). Microsoft 365, Office 365, Enterprise Mobility + Security, and Windows 11 subscriptions. https://www.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-plans-and-pricing

Microsoft General. (2020, december 12). Exit planning for Microsoft cloud services. https://servicetrust.officeppe.com/DocumentPage/4aa0c653-312f-4098-b78a-0d499e07825e

Ministerie van Binnenlandse Zaken en Koninkrijksrelaties. (2023, 05 januari). I-Strategie Rijk 2021 – 2025. Open Overheid. https://www.open-overheid.nl/documenten/2023/01/05/i-strategie-rijk-2021-2025

Ministerie van Binnenlandse Zaken en Koninkrijksrelaties. (2025, juni). Digitale autonomie en soevereiniteit van de overheid. Open Overheid. Ministerie van Binnenlandse Zaken. https://open.overheid.nl/documenten/c49a2705-3f3d-44be-8a7d-2cecd2183604/file

NOS. (2026, 07 februari). Kunnen we zonder Microsoft? In Duitsland proberen ze het. NOS Nieuws. https://nos.nl/nieuwsuur/artikel/2601288-kunnen-we-zonder-microsoft-in-duitsland-proberen-ze-it

Ong, T. C., Pradhananga, R., Holve, E. G., & Kahn, M. G. (2017). A framework for classification of electronic health data extraction-transformation-loading challenges in data network participation. EGEMS (generating Evidence & Methods to Improve Patient Outcomes), 5(1), 10. https://doi.org/10.5334/egems.222  

Boon, D. (2024, 30 oktober). Wat is cloud governance? De weg tot succesvolle cloudadoptie. TTNL. https://ttnl.nl/blog/wat-is-cloud-governance

Schellevis, J. (2025, 31 mei). Overheid leunt veel meer op Amerikaanse clouds dan bekend: ‘Meelezen is makkelijk’. NOS. https://nos.nl/artikel/2569392-overheid-leunt-veel-meer-op-amerikaanse-clouds-dan-bekend-meelezen-is-makkelijk

Shaji George, A. (2024, 25 oktober). The Cloud Comedown: Understanding the Emerging Trend of Cloud Exit Strategies. Partners Universal International Innovation Journal (PUIIJ), 2(5), 1–32. https://doi.org/10.5281/zenodo.13993933

Sheikh, H. (2022, 18 november). European digital sovereignty: A layered approach. Digital Society, 1, Article 25. https://doi.org/10.1007/s44206-022-00025-z

Terlouw, L. (2025a, september). Datasoevereiniteit, deel 1: Extraterritoriale wetgeving. Recht en Techniek. https://www.rechtentechniek.nl/datasoevereiniteit-deel-1-extraterritoriale-wetgeving/

Terlouw, L. (2025b, oktober). Datasoevereiniteit, deel 2: Bescherming persoonsgegevens in de EU. Recht en Techniek. https://www.rechtentechniek.nl/datasoevereiniteit-deel-2-bescherming-persoonsgegevens-in-de-eu/

Van de Voort, H., Aberkane, A, commissaris., & Lemeire, L, promotor. (2022). Is there an exit? Universiteit Gent. Faculteit Economie en Bedrijfskunde. https://lib.ugent.be/catalog/rug01:003117782

VNG. (2026, 08 juli). Digitale autonomie: wat kunnen gemeenten nu al doen? VNG. https://vng.nl/artikelen/digitale-autonomie-wat-kunnen-gemeenten-nu-al-doen

Zwets, B. (2025, 07 april). Nederland zet in op eigen soevereine overheidscloud. Techzine. https://www.techzine.nl/nieuws/infrastructure/563864/nederland-zet-in-op-eigen-soevereine-overheidscloud/

Bijlage