Digitale soevereiniteit: echt of schijn?

Het woord duikt overal op: in aanbestedingsdocumenten, in Kamerbrieven, op de websites van tientallen leveranciers die je een "soevereine cloud" beloven. De term is populair geworden, en daarmee ook uitgehold. Achter het label schuilt een vraag die zelden hardop wordt gesteld: heb je werkelijk grip, of heb je alleen een adres in Europa?

Een datacenter in Amsterdam onder een Amerikaans contract is geen soevereiniteit. Het is locatie.

Hieronder lees je hoe je het verschil toetst, welke architectuurkeuzes werkelijk tellen, en welke vragen je in het volgende leveranciersgesprek stelt.

Soevereiniteit gaat over grip en zeggenschap. Het gaat niet over waar je data staat, maar over wie erbij kan, wie je eruit kan zetten, en wat er overblijft als de relatie verstoord raakt.

Veel definities stoppen bij opslag: data in Nederland, in een EU-datacenter, bij een gecertificeerde partij. Dat klinkt solide, maar het is onvolledig.

Valt de partij die jouw data beheert onder Amerikaanse jurisdictie, en kan zij bij die data, dan reikt de Cloud Act tot jouw gegevens. Een Amerikaans bevel kan die partij dwingen toegang te verlenen, vaak onder een zwijgplicht, zodat jij het niet te weten komt en er weinig tegenin te brengen hebt. De FISA-wetgeving voegt daar voor inlichtingendoelen nog een laag aan toe. Waar de servers staan, doet er dan veel minder toe dan het lijkt. De juridische werkelijkheid volgt de organisatiestructuur, niet het postadres van het datacenter.

Voor overheden weegt dat onderscheid zwaarder dan voor bijna elke andere sector. Een ministerie, provincie of uitvoeringsorganisatie kan niet zeggen: de leverancier deed het. Publieke dienstverlening blijft publieke verantwoordelijkheid, ook als de techniek is uitbesteed. Digitale soevereiniteit is daarom een bestuursvraag en hoort op de bestuurstafel, niet alleen bij inkoop. En als het antwoord op die vraag vooral neerkomt op "dat staat in het contract", ben je er nog niet. Contracten zijn nodig, maar echte zeggenschap zit ook in architectuur: in sleutels, in exitmogelijkheden, in dataminimalisatie, in bewijsbaarheid.

Echte zeggenschap beantwoordt drie vragen: wie heeft de sleutels, wie kan er gedwongen worden, en wat overleeft een breuk? Als je die drie vragen niet kunt beantwoorden, heb je nog geen soevereiniteit. Je hebt een gevoel van rust.

Digitale autonomie speelt op een ander schaalniveau dan de beveiliging van één systeem. Het gaat om de vraag of een overheid haar eigen koers nog kan varen als een handvol buitenlandse leveranciers de infrastructuur van publieke diensten in handen heeft.

Dat is geen hypothetisch probleem. Kijk naar de afhankelijkheden die zijn gegroeid in de afgelopen tien jaar: e-mail, werkplekken, clouddiensten, communicatieplatforms. Veel van die diensten draaien op infrastructuur die je niet kunt dwingen, niet kunt auditen, en die je morgen kan uitzetten zonder dat jij een rechtsmiddel hebt. Een leverancier die buiten jouw juridische bereik opereert, staat buiten jouw grip op data. En als die leverancier besluit de tarieven te verhogen, zijn dienstverlening te beëindigen of wordt overgenomen door een partij die jij niet vertrouwt, dan heb je een probleem dat je niet hebt voorzien omdat je het hebt weggedelegeerd.

Dat klinkt abstract, maar het komt snel dichtbij. Denk aan burgerportalen, vergunningverlening, uitkeringen, belastingen, registers, toezicht, zorguitwisseling en identiteitsdiensten. Draait de infrastructuur onder die diensten op partijen die je niet kunt dwingen, maar die jou wel kunnen afsluiten, dan is je autonomie beperkt. Je hoeft daar niet alarmistisch over te doen. Je hoeft alleen de vraag te stellen: als morgen de voorwaarden veranderen, kunnen we dan door?

Daar zit de institutionele spanning die elke ambtenaar kent. Als er iets misgaat, ga je het uitleggen: aan de Kamer, aan de pers, aan de burger. De toeslagenaffaire heeft die reflex vastgezet: niemand in de publieke sector wil de volgende zijn die een datalek, een systeemuitval of een oncontroleerbare afhankelijkheid moet verantwoorden. Zeker niet als achteraf blijkt dat de infrastructuur werd beheerd door een partij op een ander continent, onder een andere rechtsorde.

Digitale autonomie is de structurele respons op dat risico. Het zorgt dat je niet afhankelijk bent van een partij die je niet kunt dwingen en die je kan uitzetten. Dat vraagt om andere ontwerpkeuzes, niet om andere retoriek.

Schijn-soevereiniteit is het gevoel van grip zonder de grip zelf. Je herkent het aan een patroon. De leverancier toont een Europese vlag, noemt zijn product een soevereine cloud, en wijst naar het datacenter in Frankfurt. De juridische structuur staat er los van.

Onder dat datacenter zit een moederbedrijf. Dat moederbedrijf is gevestigd in de Verenigde Staten en valt onder Amerikaans recht. Daarmee reiken de Cloud Act en FISA tot elke dochter waarover het zeggenschap heeft, en tot alle data waar die dochters bij kunnen. Dat zijn niet de kleine lettertjes, maar de werkelijke spelregels. De dochteronderneming in Europa heeft weinig te zeggen als de holding moet voldoen aan een Amerikaans bevel.

Het label helpt daarbij niet. "Sovereign cloud", "EU cloud", "lokale regio", "data residency": het klinkt geruststellend, maar het zegt iets over plaats en organisatorische inrichting, niet automatisch over sleutels, dwang en overlevingsvermogen. Op precies die drie punten vallen de meeste "soevereine" oplossingen om.

De sleutels. Wie beheert de encryptiesleutels, en wie kan er gedwongen worden die te overhandigen? Als de leverancier de sleutels beheert, heb jij beperkte grip op data. Je vertrouwt erop dat de leverancier ze niet uitlevert. Maar vertrouwen is iets anders dan zeggenschap; het blijft een aanname.

De rechtsmacht. Onder welk rechtssysteem valt de partij die jouw data beheert, en het moederbedrijf dat daarboven zit? Een dochteronderneming in Amsterdam biedt je geen bescherming als het concern is blootgesteld aan Amerikaanse wetgeving. De rechtsmacht volgt de organisatie, niet het adres van de server.

De breuk. Wat overleeft een geopolitieke of commerciële breuk? Als de relatie met de leverancier eindigt, als de leverancier wordt overgenomen, als er sancties komen: wat houd jij dan over? Als het antwoord "niets" is, of "de data, maar zonder de sleutels", dan is er nooit echt zeggenschap geweest.

Wat niet kan worden afgepakt, hoeft ook niet te worden teruggegeven. Dat is de kern van het onderscheid tussen echte en schijn-soevereiniteit.

Je prikt niet door de ruis heen met nog een opinie, maar met betere vragen. Deze vragen zijn bedoeld voor concrete gesprekken met leveranciers, marktconsultaties en aanbestedingsvoorbereidingen. Ze dienen niet als juridische checklist, maar als technisch-architecturele toets. Een leverancier die op deze vragen geen helder antwoord geeft, heeft een reden voor die onduidelijkheid.

1. Waar liggen de sleutels, en kan de leverancier ze inzien? Als de leverancier de encryptiesleutels beheert, of ze kan inzien, dan is jouw zeggenschap over de data beperkt. Vraag wie de sleutels genereert, waar ze liggen, en onder wiens rechtsmacht de sleutelbeheerder valt. De scherpste variant van de vraag: verlaten de sleutels ooit onze handen? Wie de sleutels beheert, bepaalt wie zeggenschap heeft. Dat maakt sleutelbeheer de kern van de zaak, niet een technisch detail.

2. Onder welk rechtssysteem valt de partij die de data beheert, en het moederbedrijf daarboven? Vraag specifiek naar het concern, niet naar de Nederlandse entiteit. Een dochteronderneming in Utrecht geeft je geen bescherming als de holding in Delaware geregistreerd is en onderworpen is aan de Cloud Act. Vraag ook of de leverancier onderscheid maakt tussen datahosting, support, logging, monitoring en sleutelbeheer. Soms zit de gevoeligheid niet in de opslag zelf, maar in de beheerprocessen eromheen.

3. Als ik morgen wil overstappen, neem ik dan mijn data en sleutels mee, of zit ik vast? Portabiliteit is geen luxe. Exit is ook geen paragraaf aan het einde van het contract; het is een ontwerpprincipe. Als je data exporteerbaar is maar de sleutels niet meekomen, of de formaten gesloten zijn, zit je vast. Een goede leverancier kan uitleggen hoe je weggaat. Een leverancier die dat niet kan, verkoopt afhankelijkheid.

4. Deel ik de data zelf, of alleen wat nodig is? Dataminimalisatie is een ontwerpkeuze, geen nalevingsoefening. Gegevens bij de bron laten betekent dat je niet meer deelt dan nodig is voor de specifieke functie op het specifieke moment. Wissel je minder data uit, dan is er minder blootstelling bij een incident en minder om te overhandigen bij een juridische vordering.

5. Bouw ik een centrale kopie die één doelwit wordt, of blijft de data verspreid bij de eigenaren? Een centrale dataopslag is een honeypot. Eén inbreuk, één juridische vordering, één leverancierswissel, en alles is weg of gecompromitteerd. Voor overheden is dat extra riskant, niet alleen technisch maar ook maatschappelijk: als burgers het gevoel krijgen dat de overheid alles op één plek verzamelt, verlies je snel draagvlak. Dat je geen centrale kopie aanhoudt, is een bewuste keuze om het aanvalsoppervlak te verkleinen.

Als je gegevens bij de bron laat, bij de eigenaar, en je deelt alleen de minimaal benodigde informatie op het moment dat het nodig is, dan heb je niets te overhandigen. Geen kluis om te kraken, geen kopie om te vorderen. De sterkste soevereiniteit is niet een sterkere kluis bouwen. Het is de kluis weglaten.

6. Wie kan er meekijken zonder dat ik het merk, en kan ik dat achteraf aantonen? Herleidbaarheid en onweerlegbaarheid zijn twee aparte eisen. Herleidbaar wil zeggen: je kunt reconstrueren wie wat wanneer heeft gezien. Onweerlegbaar wil zeggen: dat bewijs staat vast, ook als de leverancier het liever niet bevestigt. Vraag hoe de logging werkt, wie erbij kan, of logs achteraf aanpasbaar zijn, en hoe je een audit uitvoert die niet door de leverancier zelf wordt beheerd. Als de leverancier de enige is die de logs kan lezen, is de leverancier ook de enige getuige.

7. Werkt dit naast mijn bestaande systemen, of moet ik eerst alles migreren? Big-bang-migraties mislukken vaker dan ze slagen. Een oplossing die als aanvulling naast je bestaande systemen werkt, bijvoorbeeld via een connector, plug-in of digitale brievenbus, verlaagt het risico. Je kunt stap voor stap valideren, leren, bijsturen, zonder je afhankelijk te maken van een volledig nieuwe infrastructuur voordat je iets hebt aangetoond.

8. Als er iets misgaat, kan ik dan bewijzen wat er is gebeurd, of moet ik het geloven op gezag van de leverancier? Bij een incident wil je feiten. Niet de interpretatie van de leverancier, niet een samenvatting achteraf. Als de logs bij de leverancier liggen en alleen de leverancier ze kan lezen en uitleggen, dan sta je bij een politieke verantwoording met lege handen. Zonder zeggenschap over je eigen audit kun je publieke verantwoording niet dragen.

Begin klein. Dat klinkt als een cliché, maar het is een architectuurprincipe. Voor veel overheidsorganisaties is een groot programma of een totale migratie juist de verkeerde start: de druk op continuïteit is te hoog, legacy is te belangrijk, en publieke dienstverlening mag niet stilvallen omdat de architectuur mooier moet.

Kies daarom één proces waar gevoelige data wordt gedeeld, gekopieerd of betwist. Een ketenproces met meerdere organisaties, een vergunningstroom, een verantwoordingsproces, of een dossier waarin bewijsbaarheid belangrijk is. Breng daar drie dingen in kaart:

1. Welke gegevens worden nu gekopieerd?
2. Wie heeft technisch toegang tot die gegevens?
3. Wat kun je bewijzen als er later discussie ontstaat?

Vaak zie je dan snel waar soevereiniteit weglekt. Niet in grote geopolitieke abstracties, maar in praktische ontwerpkeuzes: een exportbestand dat blijft rondzwerven, een beheerpartij met te brede toegang, een centrale kopie die eigenlijk niet nodig is, een log die alleen de leverancier kan uitleggen, een exit die op papier bestaat maar technisch nauwelijks uitvoerbaar is.

Laat nieuwe componenten naast je bestaande systemen draaien. Aanvulling, geen vervanging. Zo hoef je de bestaande werking niet op het spel te zetten om iets nieuws te leren. Elke stap een go/no-go, voordat je de volgende zet.

Kies voor een vendor-neutrale architectuur. Open standaarden, exporteerbare data, sleutelbeheer onder eigen regie. Als je vandaag vastlegt hoe je morgen kunt overstappen, dwing je jezelf om keuzes te maken die zeggenschap opleveren in plaats van afhankelijkheid. Dat is een beslissing die je vroeg in het proces maakt, niet achteraf.

Zet dataminimalisatie niet op de agenda voor "later". Gegevens bij de bron laten is een ontwerpkeuze die je maakt bij de eerste schets, niet bij de evaluatie achteraf. Hoe later je die keuze maakt, hoe duurder hij wordt om terug te draaien.

Dat is minder spectaculair dan een grote soevereiniteitsaankondiging. Maar het is vaak sterker. Echte grip ontstaat niet door één label op de hele omgeving te plakken. Ze ontstaat door per gegevensstroom te weten wie kan lezen, wie kan dwingen, wie kan afsluiten en wat overeind blijft als het moeilijk wordt. Stapje voor stapje, maar vandaag beginnen.

Sinds 2018 werkt een klein aantal partijen, waaronder mintBlue, aan infrastructuur waarbij de sleutels bij de eigenaar blijven en gegevens bij de bron worden gelaten. Samenwerking met overheden loopt via pilots en proof-of-concepts, gericht op specifieke processen en dossiers. Geen grootschalige uitrol, geen vervanging van bestaande systemen. Wel een manier om te toetsen of de benadering in een specifieke context werkt, en om te leren voordat je schaalt.

De echte vraag is niet waar je data staat. De echte vraag is wie het kan afpakken, en of je dan nog door kunt.