Nederlandse Digitaliseringsstrategie · Prioriteit Cloud

Soevereine overheidscloud

Het ontwerp

NDS Cloud · Nederlandse Digitale Dienst · september 2026

Programma

Inhoud van vanmiddag

Inleiding. Politieke context · NDS Cloudprogramma · doel soevereine overheidscloud · EU Cloud Sovereignty Framework · scenario’s uit de verkenning · scope
Stand van zaken. Waar staan we in september 2026 en de roadmap
Het Ontwerp. Totstandkoming, vastlegging van besluiten en de belangrijkste keuzes
Kijkje in de keuken. Technische verdieping
Vragen kunnen bij elk blok, naar achteren toe steeds meer. Vandaag halen we feedback op Het Ontwerp op.

Blok 1

Inleiding

Waar deze opgave vandaan komt, wat we bedoelen met een soevereine overheidscloud, en waar we nu staan.

Politieke context

Soevereiner, en meer samen

Geopolitiek

Digitale autonomie versterken en een veilige en weerbare overheid.

Technologie

Kansen pakken op een verantwoorde en veilige manier, met oog voor cyberdreigingen. We kunnen het niet meer alleen: kennis, kunde, budget en schaalgrootte.

Dienstverlening

Burgers en bedrijven zien één overheid en verwachten betere dienstverlening. De overheid is versnipperd: loketten, lagen, processen en data.

Daarom: een gezamenlijke koers van rijk, medeoverheden en publieke dienstverleners · minder versnippering en meer als één geheel · meer regie en minder vrijblijvend · politiek-bestuurlijke sturing.
Nederlandse Digitaliseringsstrategie, ‘Samen versnellen’

De opdracht

Er ligt een duidelijke politieke opdracht om voorzieningen soevereiner te maken

Moties Kathmann en Six Dijkstra. Verzoek om het uitgangspunt van een soevereine cloud voor strategische toepassingen onomwonden te steunen.
Coalitieakkoord. Stevige ambities omtrent cloud, het verhogen van digitale veiligheid en soevereiniteit en het verkleinen van strategische risico’s bij cloudgebruik.
Kamerbrief 1 juli 2026. Om als overheid slagvaardig te kunnen blijven optreden in een veranderende geopolitieke context is het essentieel te beschikken over een soevereine overheidscloud.
Het herziene (rijks)cloudbeleid stelt ook eisen aan samenwerking met niet-Europese partners, zoals exitplannen.
Kamerbrief 26 643 nr. 1537, 1 juli 2026 · Notitie Verkenning §1.1 · Herziening rijksbreed cloudbeleid 2026

Begrippenkader

Cloud, overheid, soeverein

Cloud

Net zo goed als bij grote marktpartijen. Cloud is een leveringsmodel met vijf karakteristieken: selfservice op afroep, brede netwerktoegang, gedeelde resources, snelle schaalbaarheid en gemeten dienstverlening.

Overheid

Overheidsbreed: waterschappen, provincies, gemeenten, uitvoeringsorganisaties en departementen als afnemer. Eén werkwijze voor allemaal, tegen versnippering en afhankelijkheid van enkele leveranciers.

De dienst moet dus schalen tot de cloudvraag van de hele overheid.

Soeverein

Clouddiensten verankerd binnen de Europese jurisdictie, waarbij data, activiteiten, infrastructuur en technologie afgeschermd zijn van externe afhankelijkheden en juridische claims, en beschermd tegen invloed of toegang door overheden uit andere landen.

Notitie Verkenning §1.2 afbakening en §1.4 definities · Cloud definities en begrippenlijst, vastgesteld door het OBDO op 16 april 2026 · Het Ontwerp §2, Cloudmanifesto: architectuuruitgangspunten 1, 2 en 4

Soevereiniteitsniveaus

Vijf niveaus van het EU Cloud Sovereignty Framework

Het raamwerk van de Europese Commissie toetst digitale autonomie op acht doelstellingen en vat de uitkomst samen in vijf niveaus.

De verkenning beschrijft er het Nederlandse ambitieniveau mee.

In Europese aanbestedingen is SEAL-2 de harde ondergrens. Het kader staat in verbrede vorm ook in het CADA-wetsvoorstel.

Zowel het vereiste als het geboden niveau telt: een afnemer bepaalt wat een toepassing nodig heeft, een aanbieder toont aan wat hij levert.

SEAL-4 · Volledige digitale soevereiniteit
Technologie en exploitatie onder volledige EU-controle, uitsluitend onderworpen aan EU-wetgeving, geen kritieke niet-EU-afhankelijkheden
SEAL-3 · Digitale veerkracht
EU-wetgeving van toepassing en afdwingbaar; EU-spelers oefenen betekenisvolle maar geen volledige invloed uit, marginale controle van niet-EU partijen
SEAL-2 · Data-soevereiniteit
EU-wetgeving van toepassing en afdwingbaar, maar wezenlijke niet-EU-afhankelijkheden blijven bestaan
SEAL-1 · Jurisdictionele soevereiniteit
EU-wetgeving formeel van toepassing, beperkt praktisch afdwingbaar
SEAL-0 · Geen soevereiniteit
Exclusieve controle van niet-EU partijen, bestuurd vanuit niet-EU rechtsgebieden
EU Cloud Sovereignty Framework v1.2.1, oktober 2025 · Notitie Verkenning §1, figuur 1 · Het Ontwerp §2, architectuuruitgangspunt 1

Verkenning

Vier scenario’s

Centraal
aangestuurdDecentraal,
overheid regisseert
A
Nieuwe soevereine overheidscloud. Volledig nieuw, centraal aangestuurd, los van de bestaande systemen opgebouwd.
B
Modernisering bestaande overheidscloudinfrastructuur. Huidige clouddiensten moderniseren en centraal samenvoegen.
C
Nieuwe clouddiensten conform overheidsstandaarden. Decentraal model waarin de overheid enkel regisseur is en eisen oplegt.
D
Aansluitmodel onder overheidsregie. Decentraal marktplaatsmodel waarin bestaande infrastructuur wordt aangesloten.
Greenfield · nieuw opgebouwdBrownfield · bestaand doorontwikkeld
Scenario A is het voorkeursscenario uit de Kamerbrief van 1 juli 2026; de Tweede Kamer bespreekt het op 19 november. Departementen en medeoverheden binden zich pas via de vraagbundeling.

Scenario A

Een nieuwe clouddienst is de meest passende route

Een nieuwe soevereine overheidsclouddienst “die greenfield en vanuit centrale regie naast bestaand aanbod binnen de rijksoverheid (ODC’s) en vanuit markt wordt neergezet.”
Waarom niet doorontwikkelen. De bestaande ODC’s stap voor stap soevereiner maken bleek lastig. De markt levert niet vanzelf een overheidsbrede dienst: de juridische en governancevragen rond overheidsbrede afname zijn nog open.
Waar mogelijk in de ODC’s. Daarmee beschikt de overheid praktisch en juridisch over hardware, fysieke toegang en locatie. Het gaat om de datacenterfaciliteiten en de juridische positie. Het bestaande beheermodel gaat niet mee.
Eerst IaaS. Een Haven-compliant containerplatform met VM-ondersteuning. Daarna PaaS, daarna SaaS. De werkplek valt buiten deze scope.
Ontworpen voor alle bestuurslagen, gericht op de middencategorie: geen platform voor miljoenen gelijktijdige consumenten, geen voorziening voor individuele ontwikkelaars.
Notitie Verkenning §3.3, §3.4 en §2.6 · Het Ontwerp §2.4.3

Vraagarticulatie

Analyse van de respons
Wie hebben gereageerd
100 gemeenten
29 uitvoeringsorganisaties
15 waterschappen
8 provincies
4 ministeries
Analyse vraagarticulatie respons, versie 0.1 inclusief gemeenten, 22 september 2026. Oranje regels: waar het beeld bij gemeenten afwijkt.

Stand van zaken

Waar we staan in september 2026

Verkenning. 19 november in de vaste Kamercommissie. Financiering 2027 geagendeerd in OBDO en BOD.
Het Ontwerp. Openbaar en breed reviewbaar. Deep dive op 24 september.
Proof of concept. Wordt schaalklaar gemaakt.
In voorbereiding. Businesscase, operating model en juridisch vervolgonderzoek.
Marktconsultatie over de soevereine overheidscloud.
Fieldlab. 23 tot en met 25 november.
De marktconsultatie is een apart spoor. Inkoop en aanbesteding komen vandaag niet aan bod.
Roadmap: van verkenning naar schaal

Blok 2

Het Ontwerp

Totstandkoming, vastlegging van besluiten en de belangrijkste keuzes.

De opdracht voor het ontwerp

Een architectuur die de hele stack beslaat, openbaar en toetsbaar

Wat. Een basisarchitectuur die overheids- en marktpartijen kunnen gebruiken om soevereine cloudinfrastructuur te bouwen.

Reikwijdte. De gehele technologiestack: datacenter en compute, netwerk, basisfunctionaliteit, platformservices, managed diensten en technische afhankelijkheden.

Vorm. Openbaar gepubliceerd, met besluiten vastgelegd in Architecture Decision Records.

Afbakening. De overheid heeft een deel van het dienstenaanbod van een hyperscaler nodig. Daarmee vervalt de tegenwerping dat Europese alternatieven voor het volledige aanbod ontbreken. Principe: eenvoud boven volledigheid.

Opdrachtgever: NDS Aanjaagteam Cloud. Opgeleverd 17 augustus 2026.
Belangrijkste frameworks, standaarden en wetten
EU Cloud Sovereignty Framework
Haven-standaard
Cyberbeveiligingswet / NIS2
AVG
BIO2
Wwke
Volledig overzicht in Het Ontwerp, Bijlage 3 (Wetgeving) en Bijlage 6 (Relevante standaarden en toetsingskaders).

Het startpunt

Eisen bij begin ontwerpproces

Gesteld in de Kamerbrief, 1 juli 2026
Een containerplatform dat voldoet aan de Haven-standaard
Open source, voor minder leveranciersafhankelijkheid
Zo soeverein mogelijk, waar mogelijk in de ODC’s van het Rijk
Openbaar, zodat anderen kunnen bijdragen en hergebruiken
Eerste applicaties uiterlijk eind 2026
Uitgewerkt in het manifest van het architectuurteam
1  Aantoonbaar soeverein: SEAL-4, pas toe of leg uit
2  Een échte clouddienst: de vijf karakteristieken van cloud computing
3  Secure by design, in elke laag van de dienst
4  Schaalbaar, voor de cloudvraag van de hele overheid
5  Open standaarden én open source, ook de architectuurdocumenten
6  Een modern platform, ook als op dag één niet alle workloads mee kunnen
7  Eenvoud boven volledigheid: een kleine, goed werkende set bouwblokken
8  Incrementeel: eerst een basis, die daarna verbeterd en uitgebreid wordt
Kamerbrief 26 643 nr. 1537, 1 juli 2026 · Cloud Manifesto, §2.1.1 principes en §2.1.2 uitgangspunten · Het Ontwerp §1.9.1

De vastgestelde richting

Gekozen uitgangspunten

Architectuur
Open architectuur en open standaarden, openbaar gepubliceerd en bruikbaar voor overheid en markt.
Technologie
Open source, met toetsing van de software supply chain aan het EUCSF. Alle software is OSI-approved, niet slechts OSI-compatible.
Soevereiniteit
SEAL-4 voor de hele stack, pas toe of leg uit. Boven de hardware-abstractielaag halen we het. Voor het silicium eronder leggen we uit waarom het vandaag nog niet kan, met een migratiepad en jaarlijkse herijking.
Huisvesting
ODC-gehuisvest, naast het bestaande takenpakket van de ODC's.
Uitzondering: CPU's, GPU's en netwerk-ASIC's, waarvoor geen Europese productie op schaal bestaat. ADR-002 (vastgesteld) legt de grens bij de hardware-abstractielaag; de herijking volgt onder meer RISC-V, de EU Chips Act en het European Sovereign Tech Package. Ambitie bekrachtigd door de stuurgroep NDS Cloud, Notitie Verkenning §4.1 · Het Ontwerp §1.2.3 en §1.2.4.

De inhoud

Keuzes op acht lagen

01  Datacenter
02  Hardware
03  Provisioning
04  Compute
05  Storage
06  Networking
07  Security
08  Diensten
Werkwijze
Brede vertegenwoordiging uit meerdere overheidslagen, en 58 reviewers overheidsbreed.
De achtste laag, Diensten, vraagt een operating model. Daar zit het meeste openstaande werk.

Hoe de besluiten zijn vastgelegd

Architecture Decision Records

Elke architectuurkeuze is een apart, navolgbaar besluit met context, afweging en consequenties. Er zijn geen keuzes die alleen in iemands hoofd zitten.

Status: Voorgesteld → Brons → Zilver → Goud → Vastgesteld. Zo is bij elke ADR zichtbaar wat vastligt en wat openstaat.

De ADR-set wordt consistent gehouden met wat er in de proof of concept draait.

Opbouw van de nummering
ADR-0xx  Overkoepelend architectuurbesluit
ADR-G##  Generieke besluiten
ADR-C##  Component-specifieke besluiten
ADR-X##  Externe perspectieven
Het Ontwerp, bijlagen · ADR-beheer in de architectuurrepository

Context bij de ontwerpkeuzes

De cloud van morgen is fundamenteel anders dan de cloud van vandaag

Traditioneel gebouwd
10U-chassis met dure blades + proprietary firmware
Grote centrale opslag met draaiende schijven
Een stapel los verkochte security-appliances
Intelligentie zit in gespecialiseerde hardware
Moderne overheidscloud
Uitwisselbare nodes zonder proprietary firmware
NVMe-opslag in de nodes zelf, verbonden via een snel Clos-netwerk (spine-leaf)
Opslag, netwerk en security geïntegreerd in software
Intelligentie zit in software onder onze zeggenschap
Ook onder Kubernetes zit vaak nog een traditionele setup. Die bouwwijze verklaart het kostenverschil, en waarom hyperscalers kunnen wat klassieke datacenters niet kunnen. Uniforme nodes zijn daarnaast beter te beheren en sneller uit te rollen en te vervangen. Dat maakt ze ook veiliger.
Het architectuurmodel volgt deze lijn: losse CNCF-componenten op bare-metal Kubernetes (ADR-001, vastgesteld) met een immutable open source besturingssysteem direct op de hardware (ADR-C02, vastgesteld). De netwerkfabric (ADR-G56) heeft nog de status Voorgesteld.

Dilemma's, organisatorisch

Niet-technische dilemma's

Er is nog geen breed gebruikte soevereine IAM-oplossing. Daarom federatief: afnemers brengen hun eigen identity provider mee, bij aanvang mogelijk niet soeverein, met een migratiepad op het tempo van de afnemer.
De ene open source is de andere niet. Licentie, governance en herkomst bepalen of een component bijdraagt aan soevereiniteit. Dat vraagt dat de overheid, samen met de Nederlandse industrie, actiever wordt in open source governance en bijdraagt aan de projecten waarvan zij afhankelijk is.
Een platform is nog geen dienst. Daar horen mensen en processen bij. Governance, organisatie-inrichting en exploitatie vallen buiten Het Ontwerp; daarover volgt nadere besluitvorming via het Target Operating Model.

Platform en dienst

Bouwblokken en een capability map

Architecture Building Blocks (ABB)
Een ABB is een abstractie van een voorziening. Waar de ADR's concreet en technisch zijn, maken de ABB's de architectuur bespreekbaar op het niveau waarop organisaties erover besluiten.
Capability Map
Beschrijft wat de leverende organisatie moet kunnen om de dienst te realiseren. De invulling volgt uit het Target Operating Model.
Clouddienstverlening inrichten is iets anders dan diensten leveren aan overheidsonderdelen binnen dezelfde kolom of bestuurslaag. Dat lukt alleen met een dienstverlener die stopt met klantspecifiek maatwerk.

Hetzelfde bouwblok, in het model

Positionering ABB

Stippellijn = bouwblok
Een ABB staat in het model als groepering. Die naam komt terug in de catalogus, in de matrix met de ADR's en in de bijlagen bij Het Ontwerp.
Groen vlak = de service
Een technologiedienst: de functie die andere bouwblokken kunnen afnemen, los van het product waarmee je hem invult.
Pijl = wat bedient wat
De fysieke netwerkconnectiviteit bedient de underlay, en die bedient de server en de opslag.
Dezelfde notatie wordt in bijlage 8.3a op 42 views toegepast, van een enkel rack tot het totaaloverzicht.
Bijlage 8.3a bij Het Ontwerp v0.9, view Positionering ABB, ArchiMate-export 26 augustus 2026

Architectuur in beeld

Van workload tot huisvesting in één plaat

Totaaloverzicht

Workloads van afnemende organisaties landen op tenantclusters, die draaien op Kubernetes master- en worker nodes.

Die nodes draaien direct op bare metal: servers, met bestandsopslag, blokopslag en de underlay-netwerkconnectiviteit eronder, en huisvesting als onderste laag.

Tussen workload en hardware zit geen hypervisorlaag. Dat is de kern van het architectuurmodel uit ADR-001.

Bijlage 8.3a bij Het Ontwerp v0.9, view Totaaloverzicht

Zelf lezen en reviewen

Het Ontwerp en de bijlagen staan online

Te downloaden op de site van de PGDI, inclusief de ADR’s, de ABB’s en de ArchiMate-export.

QR-code naar de downloadpagina op de PGDI
https://pgdi.nl/groups/view/7d10e3c4-540d-4b20-ac04-d4011a6a90dc/architectuurraad-en-architectuurwerkgroepen/files/e512fb49-e271-4980-8edb-9c740e970c00

Blok 3

De samenhang tussen de besluiten

Elke keuze legt de volgende vast. Hoe de ADR’s op elkaar ingrijpen, en hoe de proof of concept zich tot die besluiten verhoudt.

Blok 4

Kijkje achter de schermen

Hoe het er in de praktijk uitziet: van rack en switch tot de netwerkfabric onder de hele cloud.

ADR-002

Soevereiniteitsambitie en toetsingskader

Soevereiniteit gemeten met het EU Cloud Sovereignty Framework, per component en steeds actueel.

ADR-C01

Bare-metal provisioning

Van nieuwe server in het rack tot node in een cluster, zonder handwerk.

ADR-G73

Hypervisor-strategie

Fundament draait zonder hypervisor, met clusters op hele nodes.

ADR-G73 · Hypervisor-strategie

Veiligheid en energie zonder hypervisor

Veiligheid
Geen gedeelde hardware. Een node hoort bij één cluster van één afnemer. Aanvallen tussen buren via gedeelde CPU-caches (Spectre, MDS) en noisy neighbours vallen weg.
Geen centrale beheerlaag. Er is geen hypervisorbeheer dat alle afnemers tegelijk raakt (denk aan ESXiArgs).
Elk cluster een eigen domein. Eigen nodes, een eigen VRF en een eigen control plane.
Virtuele machines
Optioneel, via KubeVirt. Heeft een afnemer een VM nodig, dan draait die als Kubernetes-object op de eigen nodes van die afnemer. KVM draait als module in de Linux van de node; onder het platform ligt geen hypervisorlaag.
Uitbraak blijft binnen de afnemer. Een VM-escape komt niet verder dan de nodes van die afnemer.
Energie
Rekenkracht gaat naar werk. Geen hypervisor en geen gastbesturingssysteem per VM die rekenkracht en geheugen vragen.
Schalen met hele nodes. Clusters groeien en krimpen met de drukte; wat niet nodig is, gaat terug naar de pool.
Voorwaarde. Een afnemer heeft een hele machine, dus firmware en BMC moeten op orde zijn. Een machine hoort pas terug in de pool na het wissen van de disks en een controle van de firmware, met de BMC in een afgescheiden beheernetwerk.
ADR-001 · ADR-C03 Ondersteuning voor virtuele machines (vastgesteld) · ADR-G73 Hypervisor-strategie

Uitleg

Continuous auditing

Meetpunten in elke laag leveren doorlopend bewijs, dat steeds wordt vergeleken met de controls uit de normenkaders.

Proof of Concept

De architectuur is technisch getest

Parallel aan het ontwerp bouwden we een proof of concept van de architectuur, net groot genoeg om die te beproeven, onder andere bij Digilab.

Visie ontwikkelen en meters maken tegelijk.

De Machine. Detecteert nieuwe en defecte hardware, en richt nieuwe hardware volledig automatisch in.
Infrastructure as Code. Het hele platform, ook het netwerk, leggen we vast in code.
Soeverein tot in de firmware. Dat stelt eisen aan de hardware-inkoop.
Geen hypervisor. In de praktijk getest met metal-stack en Gardener.
De PoC is geslaagd. Hij wordt doorontwikkeld naar een kleinschalige productieomgeving, zodat voor eind 2026 de eerste pilot-applicaties gehost kunnen worden.
25+ leads: overheidsorganisaties willen meedoen

Tot slot

Dank voor de aandacht

Het Ontwerp is niet af. Wat vandaag is opgehaald gaat mee in de review en in de verdere besluitvorming.

Reacties blijven ook na vandaag welkom.

nds-cloud@minbzk.nl
QR-code naar Het Ontwerp op de PGDI
Het Ontwerp en de bijlagen