Het herziene rijkscloudbeleid: wat er per juli 2026 echt veranderd is — en voor wie

Over het herziene rijksbrede cloudbeleid is sinds de zomer genoeg geschreven — vrijwel allemaal gericht op de overheidsorganisaties die eraan moeten voldoen. Dit stuk is voor de andere kant van de tafel: de SaaS-leverancier, het webbureau en de dienstverlener die aan die overheden levert, of aan partijen die dat doen. Want de interessantste werking van dit beleid zit niet in wat het van het Rijk vraagt, maar in wat het Rijk daardoor van zijn leveranciers gaat vragen.

Vooraf één ding, in lijn met hoe we hier over dit onderwerp schrijven: dit beleid is geen verbod op Amerikaanse cloud, en wie het je zo verkoopt, heeft het niet gelezen. Het is een risicogestuurd kader — met tanden, maar ook met ruimte voor de uitkomst “dit gebruik is afgewogen en acceptabel”. Wat er wél onherroepelijk verandert: dat oordeel moet voortaan gedocumenteerd, onderbouwd en jaarlijks herhaald worden. Papier wordt de norm. En dat papier kan een leverancier maken of breken.

Wat er is gebeurd

Op 3 juli 2026 stelde de ministerraad de herziening van het rijksbrede cloudbeleid vast; staatssecretaris Aerdts (Digitale Economie en Soevereiniteit) stuurde het dezelfde dag naar de Tweede Kamer. Het vervangt het beleid uit 2022, dat destijds juist de deur naar publieke clouddiensten openzette. De aanleiding voor de aanscherping benoemt het document zelf: de kritische onderzoeken van de Auditdienst Rijk en de Algemene Rekenkamer uit 2024 over het gebrek aan grip op het cloudgebruik, meerdere Kamermoties, de gewijzigde geopolitieke verhoudingen en de ontwikkelingen in de cloudmarkt.

Voor wie geldt het? Rechtstreeks: de Rijksdienst, zodra clouddiensten — publiek, hybride of privaat — door een externe leverancier worden geleverd. ZBO’s zijn formeel niet gebonden maar “worden geacht dit beleid te volgen”, en de praktijk beweegt al: UWV heeft publiek aangegeven het rijksbrede cloudbeleid vrijwillig te volgen. Gemeenten, provincies en waterschappen vallen er nog buiten, maar er wordt gewerkt aan overkoepelend, overheidsbreed cloudbeleid — en wie op die formele uitbreiding wacht voordat hij in beweging komt, mist dat gemeentelijke inkopers de eisen nu al in aanbestedingsteksten kopiëren. Beleid sijpelt sneller door via inkoop dan via wetgeving.

De vijf aanscherpingen die ertoe doen

Voor leveranciers zijn dit de vijf onderdelen om te kennen, met paragraafverwijzing zodat je ze kunt nalezen:

1. De integrale risicoanalyse (§3.1). Bij “materieel cloudgebruik” — clouddiensten die een kerntaak raken of van wezenlijk belang zijn, waarbij grootschalige verwerking van persoonsgegevens per definitie materieel is (§4.1) — moet de organisatie een integrale risicoanalyse maken. Die kijkt verder dan vroeger: niet alleen naar de hoofddienstverlener maar ook naar de onderdienstverleners eronder, naar de geografische regio waar data staat, en — nieuw en expliciet — naar het risico van buitenlandse inmenging en van een te grote leveranciersafhankelijkheid. Het document benoemt letterlijk het geval waarin een leverancier “(deels) onder een andere jurisdictie dan de Nederlandse of één van de EU- of EER-lidstaten valt”.

2. Het exitplan met twéé scenario’s (§3.2). Dit is de bekendste aanscherping, maar de details worden vaak gemist. Vereist is een gedocumenteerd en door de organisatie zelf getoetst exitplan dat twee situaties dekt: de geplande exit (verplaatsing zonder ongeplande verstoring, inclusief contractueel geborgde overdracht van data, metadata en applicaties, kritische randvoorwaarden en een minimale termijn) én de disruptieve onderbreking — wat er gebeurt als een dienst onverwacht wegvalt, inclusief maatregelen die vooraf genomen moeten zijn, zoals een back-up buiten de cloudomgeving van de leverancier. In beide scenario’s hoort de datavernietiging bij de oude leverancier geregeld te zijn.

3. Jaarlijkse actualisatie. Zowel de risicoanalyse als het exitplan moeten jaarlijks op actualiteit worden beoordeeld en zo nodig aangepast (§3.2, slot). Een exitplan is daarmee geen eenmalig document meer maar een levend dossier — met een jaarlijks terugkerend moment waarop het aantoonbaar bijgewerkt moet zijn.

4. Melding aan CISO Rijk (§3.3). Materieel cloudgebruik wordt gemeld bij de CISO Rijk, mét risicoanalyse en exitplan. Er kijkt dus centraal iemand mee of het papier er ligt — en dat verandert de dynamiek: een ontbrekend exitplan is niet langer een intern ongemak maar een zichtbare afwijking.

5. Datalocatie en sleutelbeheer (§4.6). Opslag en verwerking horen plaats te vinden binnen de EER plus Zwitserland. Data moet versleuteld worden opgeslagen, en — subtiel maar belangrijk — het sleutelbeheer ligt bij voorkeur niet bij de cloudleverancier zelf. Voor bijzondere persoonsgegevens gaat het verder: publieke cloud wordt daarvoor afgeraden, en waar het toch noodzakelijk is, moeten Privacy Enhancing Technologies worden toegepast. Wie zorg-, jeugd- of sociaal-domein-software levert, leest die laatste zin twee keer.

De deadline die iedereen mist

In de berichtgeving circuleert vooral de overgangstermijn van vier jaar, en die klopt — maar hij gaat over het aanpassen van het cloudgebruik zelf aan het nieuwe beleid, met verlengingsmogelijkheid. Voor het exitplan geldt iets anders, weggestopt in een voetnoot bij §3.2: voor bestaand materieel cloudgebruik moet het exitplan er binnen twaalf maanden na vaststelling liggen. Vastgesteld op 3 juli 2026 betekent: rond de zomer van 2027 hoort elke rijksorganisatie voor elk materieel cloudgebruik een gedocumenteerd, getoetst exitplan te hebben — óók voor diensten die daarna nog jaren mogen blijven draaien.

Het document en het systeem hebben dus verschillende deadlines, en het document komt eerst. Onthoud dat onderscheid, want het bepaalt de volgorde waarin de vragen bij leveranciers binnenkomen: eerst de informatievragen voor het papier, pas daarna de eventuele migratie-eisen.

Waarom dit jou raakt als je géén overheid bent

Nu de keten die dit beleid interessant maakt voor iedereen die aan de publieke sector levert. Stap één: het beleid is expliciet van toepassing op SaaS zodra die software op publieke cloud draait (§2) — de afgenomen dienst telt als cloudgebruik van de overheidsorganisatie. Stap twee: die organisatie moet er dus een risicoanalyse en een exitplan voor maken, binnen de termijnen hierboven. Stap drie: dat kán ze helemaal niet zonder informatie van de leverancier — waar draait de dienst, welke onderliggende cloudpartijen en subverwerkers zitten eronder, hoe komt de klant bij zijn data, wat gebeurt er bij beëindiging. Stap vier, de onvermijdelijke conclusie: die vragen komen op jouw bord, via inkoop, via een contractmanager, via een security-vragenlijst bij de verlenging.

Dat is de directe doorwerking. Er zijn nog twee indirecte die je wilt kennen. De werkplekregel (§4.5): e-mail en documenten van rijksorganisaties horen niet in de publieke cloud, behoudens een strikte uitzondering, met vier jaar overgangstermijn voor bestaande werkplekken — het beleid beschouwt werkplekdiensten als een zaak van nationaal belang. Wat vandaag voor rijkswerkplekken geldt, is de voorbode van wat semipublieke organisaties morgen aan hun leveranciers vragen. En voor wie met gerubriceerde of gevoelige overheidsinformatie werkt: externe leveranciers moeten aan de Algemene Beveiligingseisen Rijksoverheid voldoen, en staatsgeheime informatie blijft categorisch buiten de publieke cloud (§5.2).

De vijf vragen die je als leverancier klaar wilt hebben

Alles hierboven komt voor een leverancier neer op vijf vragen. Wie ze vandaag kan beantwoorden — schriftelijk, actueel, zonder een projectje te hoeven starten — maakt de risicoanalyse van zijn overheidsklant een middag werk in plaats van een traject:

1. Waar draait het, precies? Niet “in de cloud” maar: welke onderliggende cloudleverancier, welke regio’s, en waar staan de back-ups.
2. Wie zitten eronder? Het volledige subverwerkersoverzicht, met per partij de jurisdictie en de procedure waarmee wijzigingen worden aangekondigd.
3. Hoe komt de klant bij zijn data? Welke data exporteerbaar is, in welke formaten, via welke weg (self-service, API, op verzoek) en binnen welke termijn.
4. Wat doe je bij beëindiging? Welke overdrachtsondersteuning de klant krijgt, tegen welke voorwaarden en tarieven.
5. Hoe wordt data vernietigd? De procedure na afloop, en of de klant daar een bevestiging van krijgt.

Wie er een zesde aan toevoegt — een continuïteitsparagraaf: wat er geregeld is als jóuw dienst uitvalt of jouw onderliggende cloudleverancier de voorwaarden wijzigt — beantwoordt daarmee precies het disruptie-scenario dat de klant in zijn exitplan moet beschrijven. Dat is geen compliance-kost; dat is aanbestedingsmunitie die je concurrent waarschijnlijk niet heeft liggen.

Het nuchtere slot

Wordt dit allemaal streng gehandhaafd vanaf dag één? Nee. Er is geen extra budget voor de implementatie vrijgemaakt, de termijnen zijn verlengbaar, en de ervaring met het beleid van 2022 leert dat de uitvoering per departement flink verschilt. Wie op basis van dit beleid paniek verkoopt, overdrijft — en wie het daarom negeert, mist het punt. Want er is één plek waar beleidswijzigingen wél onmiddellijk landen: in de tekst van de volgende aanbesteding en het volgende contractgesprek. Aanbestedingsteksten veranderen sneller dan systemen. Het verschil tussen de leverancier die zijn vijf antwoorden klaar heeft en de leverancier die “daar komen we op terug” moet zeggen, materialiseert op precies dat moment — en op dat moment is het te laat om nog te beginnen.

Lever je SaaS of digitale diensten aan de publieke sector en wil je die antwoorden gedocumenteerd klaar hebben liggen — als eigen exitplan én als overdraagbaar dossier voor je overheidsklanten? Dat is precies wat we bouwen: het Exitplan en het Exitdossier, opgesteld volgens de systematiek van dit beleid, met de eisenmatrix erbij.

---

Bronnen: Kamerbrief Herziening Rijksbreed Cloudbeleid 2026 (2026D35294), 3 juli 2026 · Herziening rijksbreed cloudbeleid 2026, beleidsdocument (2026D35295) · Binnenlands Bestuur: “Rijksbreed cloudbeleid aangescherpt”, 4 juli 2026 · Antwoorden Kamervragen SZW over cloudafhankelijkheid (Aanhangsel 2025–2026, nr. 56).