Door Bertrand de Neve, De Neve IT Consulting B.V.
Maandagochtend, zwarte schermen
Stel je voor. Het is maandagochtend, de beste tijd van de week om fris aan een nieuwe werkweek te beginnen. Je klapt thuis aan de keukentafel je laptop open, koffie erbij, en wilt inloggen. Er gebeurt niets. Geen e-mail, geen toegang tot het ERP-systeem, geen documenten, geen klantdata. Alles zwart.
De eerste gedachte is meestal: we zijn gehackt. Dus bel je de IT-afdeling. Maar het antwoord is nuchterder én ingewikkelder dan een cyberaanval: er is niets gehackt. Door een geopolitieke ontwikkeling zijn de clouddiensten voor Europese afnemers tijdelijk bevroren of ontoegankelijk geworden, bijvoorbeeld door aangescherpte sanctieregels of buitenlandse exportrestricties. Je organisatie ligt stil, en op dat moment heb jij daar zelf geen enkele invloed op.
Dit is geen doemscenario, het is een risicoscenario, en dat is een belangrijk verschil. Het gaat er niet om of dit morgen gebeurt, maar om de vraag: als het gebeurt, kun je dan nog functioneren? Precies dát is waar goed risicomanagement voor bedoeld is. En die vraag weegt het zwaarst bij organisaties die onze democratie, veiligheid en vrijheid feitelijk bewaken: defensie, politie, en de instanties die onze vitale infrastructuur en financiële stabiliteit overeind houden. Juist zij kunnen zich geen scenario permitteren waarin een besluit in een ander land, buiten hun eigen invloed, hun handelingsvermogen raakt. Tegelijk is dit geen makkelijke opgave: ook deze organisaties werken, net als vrijwel iedereen, met gangbare internationale platformen voor identiteit, samenwerken en communicatie, en de afweging hoeveel risicomitigatie daar bovenop nodig is, is niet eenvoudig of vrijblijvend.
We wisten het “waarom”, het “hoe” bleef liggen
Digitale soevereiniteit is de laatste tijd niet weg te denken uit het nieuws. Beleidsmakers, bestuurders en journalisten zijn het inmiddels grotendeels eens over het “waarom”: we moeten minder afhankelijk worden van een handvol buitenlandse techgiganten voor onze meest kritieke processen. Goede bedoelingen genoeg.
Het probleem zit in het “hoe dan”. De afgelopen decennia is er nauwelijks structureel ontworpen aan soevereiniteit. Exitstrategieën kregen bij de inrichting van IT-landschappen zelden serieuze aandacht, alsof het plannen van een vertrek een vorm van wantrouwen was in plaats van goed vakmanschap. Wie er destijds voor pleitte, werd nogal eens weggezet als overdreven voorzichtig of als doemdenker. Het resultaat: organisaties die weten dát ze iets moeten doen, maar intern niet uitkomen met wie, wat en hoe — en die vaak ook niet de mogelijkheid hebben om dit zelf uit te zoeken zonder eerst kostbare tijd te verliezen aan trial-and-error. Daar komt bij dat veel van dat vakmanschap de afgelopen jaren juist buiten de deur is belegd, bij destijds goedkope arbeid en managed services uit het Verre Oosten en elders, waardoor de kennis om zelf weer grip te krijgen op de eigen infrastructuur bij veel organisaties simpelweg is weggeorganiseerd.
Dat gat tussen inzicht en actie is precies waar ik al maanden, op een zeer pragmatische en hands-on manier, in duik. In mijn eigen onderzoeks- en ontwikkelomgeving ontwerp en bouw ik met regelmaat werkende soevereine oplossingen, niet als theoretische oefening, maar als concreet bewijs dat het kan. Daardoor word ik niet gehinderd door interne discussies of het ontbreken van kennis, en kan ik organisaties die de stap willen of moeten maken, versneld op weg helpen. Het is een aanpak, eerst zelf bouwen en doorgronden voordat ik het adviseer, die ik mijn hele loopbaan al hanteer, en die zich telkens weer bewijst.
Laat ik meteen helder zijn over wat dit artikel niet is. Het is geen pleidooi tegen Amerikaanse bedrijven, technologie of mensen. Amerikaanse leveranciers hebben decennialang uitstekende, betrouwbare producten geleverd waar Europa terecht dankbaar gebruik van heeft gemaakt, en dat blijft ook zo. Dit gaat over iets anders: structureel risicomanagement rond eenzijdige afhankelijkheid van één jurisdictie, wie die jurisdictie ook is. Diezelfde logica geldt onverkort voor afhankelijkheid van Chinese leveranciers, of van andere landen waar rechtsstatelijkheid, toezicht en democratische controle minder stevig verankerd zijn. Het is geen kwestie van vriend of vijand, maar van spreiding, controle en een realistische inschatting van wat er kan gebeuren als je alle eieren in één juridisch mandje legt. Sterker nog, het is minstens zo goed een pleidooi vóór iets: digitale soevereiniteit kan ons ook mooie dingen brengen. Denk aan AI-modellen die getraind zijn op Europese waarden, normen en context, en die daarmee bijdragen aan een sterkere, weerbaardere democratie in plaats van alleen aan het beperken van risico.
Twee krachten die frontaal op elkaar botsen
Om te begrijpen waarom dit onderwerp nu zo urgent is, moet je twee krachten naast elkaar leggen die recht tegenover elkaar staan.
Aan de ene kant staat buitenlandse wetgeving zoals de Amerikaanse CLOUD Act, die autoriteiten de juridische bevoegdheid geeft om data op te eisen ongeacht waar de servers fysiek staan (zelfs in Amsterdam of Frankfurt), zolang de leverancier onder de reikwijdte van die wet valt. Daarnaast spelen extraterritoriale sanctieregels en exportcontroles die de toegang tot diensten plotseling kunnen afknijpen. Vergelijkbare of ingrijpendere bevoegdheden bestaan, vaak met minder transparantie en rechtsbescherming, in andere jurisdicties buiten de EU. Aan de andere kant staat de Europese wetgeving rondom NIS2 (in Nederland vertaald naar de Cyberbeveiligingswet, in nauwe samenhang met de Wet weerbaarheid kritieke entiteiten voor de CER-richtlijn), die organisaties in vitale en belangrijke sectoren verplicht om precies dit soort leveranciers- en ketenrisico’s aantoonbaar te mitigeren.
En daar zit een flinke angel in. NIS2 kan bestuurders namelijk persoonlijk aansprakelijk stellen als de risico’s in de toeleveringsketen niet aantoonbaar op orde zijn. Soevereiniteit is daarmee geen technisch feestje van de IT-afdeling meer, maar een bestuurlijke verantwoordelijkheid. De kernvraag is simpel te stellen en lastig te beantwoorden: wie heeft de uiteindelijke fysieke én juridische controle over jouw data, en wie kan op het cruciale moment zeggen “sorry, je mag er niet meer in”?
Het is een beetje alsof je een prachtig, state-of-the-art kantoor huurt: mooie bureaus, goede koffie, alles piekfijn. Maar een buitenlandse overheid heeft de reservesleutel. Contractueel kunnen zij, op een moment dat hén uitkomt, gewoon de sloten vervangen. Dan sta jij buiten.
De grootste misvatting: locatie is niet hetzelfde als controle
De meest gemaakte fout die ik in de praktijk tegenkom, is dat organisaties denken dat ze afgedekt zijn omdat hun data fysiek in een Europees datacenter staat — in de Eemshaven of in Frankfurt. Dat is een misvatting, en geen kwade opzet van de leverancier, gewoon een blinde vlek in hoe veel inkoop- en risicoprocessen nog zijn ingericht. Wetten als de CLOUD Act kijken niet naar waar de schijven fysiek draaien, maar naar de jurisdictie van de juridische entiteit die zeggenschap heeft over dat datacenter. Is de eigenaar van dat Frankfurtse datacenter een dochteronderneming van een moederbedrijf buiten de EU? Dan kan die entiteit wettelijk verplicht zijn data te overhandigen zodra een buitenlandse rechter of overheid dat eist, ook als dat op gespannen voet staat met de AVG.
Dat betekent niet dat elke buitenlandse leverancier per definitie een probleem is. Het betekent wel dat elke organisatie die het serieus wil aanpakken, haar softwareportfolio bewust langs een geopolitieke meetlat legt, naast de gebruikelijke technische en financiële afwegingen, en op basis daarvan een weloverwogen keuze maakt: welke afhankelijkheid is acceptabel, en welke niet? IT is, of we dat nu willen of niet, geopolitiek geworden. Soevereiniteit by design, ontwerpen met die realiteit in het achterhoofd, is echter nog nauwelijks gemeengoed.
Van sleutelbeheer tot fundering: identiteit als startpunt
Wie in eigen huis wil bepalen wie er naar binnen mag, begint bij identiteit. Veel organisaties draaien vandaag volledig op een Amerikaanse identity provider — logisch, want het werkt naadloos en iedereen kent het. Maar wie de controle over wie er mag inloggen kwijtraakt, raakt in feite alles kwijt.
Er bestaan inmiddels volwassen, Europese en open-source alternatieven waarmee je zelf bepaalt waar je identiteitsplatform draait: bij een Europese provider, of gewoon in je eigen datacenter. Jij beheert de gebruikersdatabase, en cruciaal: jij bezit de cryptografische sleutels. Geen juridische achterdeur meer.
Het mooie is dat dit niet betekent dat je op maandagochtend je bestaande identiteitsplatform moet slopen en tienduizend medewerkers een nieuwe inlog moet geven. Via federatie kun je een Europese identity-laag als een soort diplomatieke buffer tussen je medewerkers en de bestaande provider plaatsen. In de dagelijkse praktijk merkt niemand iets: het vertrouwde inlogscherm blijft gewoon werken. Maar zodra de verbinding met de niet-soevereine partij wegvalt, door sancties of een storing, weet die buffer nog steeds precies wie er op de gastenlijst staat en neemt hij zelfstandig het roer over. Je behoudt het dagelijkse gebruiksgemak, maar creëert tegelijk een volledig soevereine nooduitgang.
Meer lezen: “Transformatie naar soevereiniteit: bouwen aan een nieuwe fundering terwijl de winkel openblijft“.
Het onderschatte fundament: DNS
Er is nog een kwetsbaar punt dat vaak over het hoofd wordt gezien: DNS, het telefoonboek van het internet dat domeinnamen vertaalt naar IP-adressen. Veel organisaties beleggen dit zonder er verder bij stil te staan bij één grote, niet-Europese partij. Dat is een blinde vlek, want DNS-verkeer kan in theorie via een rechtmatig bevel worden omgeleid of geblokkeerd. Je kunt dan de mooiste soevereine servers hebben draaien, als de verwijzing naar jouw domein wordt verstoord, ben je voor je gebruikers alsnog onbereikbaar. Ook hiervoor bestaan volwassen, Europese en open oplossingen waarmee je zelf de fysieke en juridische controle houdt over welk IP-adres de buitenwereld te zien krijgt.
Meer lezen: “Van kwetsbaarheid naar continuïteit: een multi-cloud failover-architectuur voor digitale soevereiniteit“.
Compute en state loskoppelen: je werkplek soeverein maken
Voor de dagelijkse werkplek — documenten, e-mail, videobellen, bestandsdeling — leunen de meeste organisaties zwaar op grote Amerikaanse kantoorsuites. Ook hier zijn volwassen open-source ecosystemen ontstaan die dit soort functionaliteit op enterprise-niveau leveren: geen hobbyprojecten uit 2005, maar productieklare platformen.
Het architectonische principe dat hier het verschil maakt, is de scheiding tussen compute en state: de rekenkracht die tijdelijk is, en de daadwerkelijke data die apart, veilig en onwrikbaar wordt opgeslagen, vaak versleuteld met sleutels die uitsluitend jij beheert. Zelfs als de applicatieserver wordt overgenomen of uitvalt, blijft je data onschendbaar in je eigen kluis staan. Brein en geheugen zijn losgekoppeld.
Meer lezen: “Van idee naar soevereine cloud: mijn reis naar digitale autonomie“.
Niemand hoeft de stekker eruit te trekken: het stappenplan
Een organisatie die vastzit in een niet-soevereine architectuur, kan natuurlijk niet aanstaande vrijdag de stekker eruit trekken. Dat wordt chaos. Er bestaat gelukkig een beproefd, stapsgewijs pad, dat opvallend genoeg niet begint met bouwen, maar met kijken.
Stap 1: zichtbaarheid. Je kunt niet beschermen wat je niet ziet. De eerste stap is een nulmeting van je werkelijke SaaS-voetafdruk, inclusief de schaduw-IT die afdelingen buiten IT om hebben ingekocht. Zonder dat overzicht heeft elk verhaal over soevereiniteit of exitstrategieën geen fundament.
Stap 2: geopolitieke risicobeoordeling. Zoals eerder beschreven: niet de locatie van het datacenter telt, maar de jurisdictie van de moedermaatschappij. Elke leverancier verdient die toets.
Stap 3: exit by design. Dit is het technische hart van de oplossing: infrastructuur zo bouwen dat je er altijd, relatief eenvoudig, weer uit kunt stappen. In plaats van applicaties onlosmakelijk te verweven met de unieke tools van één specifieke cloudleverancier, verpak je ze in gestandaardiseerde, draagbare eenheden, vergelijkbaar met de introductie van de zeecontainer in de scheepvaart: voorheen moest elk product apart worden ingeladen, met de gestandaardiseerde container maakte het opeens niet meer uit wat erin zat. Zo’n eenheid til je met hetzelfde gemak van de ene cloud naar de andere, zonder de applicatie zelf te hoeven herschrijven. Voor data betekent exit by design dat je vastlegt dat alles altijd exporteerbaar moet zijn in open, leesbare standaarden in plaats van een gesloten formaat waar je op het moment van vertrek alleen nog een onleesbare brei uit krijgt.
Stap 4: een geteste noodvoorziening. Voor het scenario waarin de verbinding met een niet-soevereine partij plotseling wegvalt, richt je een break glass-protocol in: een lokaal systeem dat zelfstandig verder kan, gevoed door strikt gecontroleerde, eenrichtingssynchronisatie van alleen de noodzakelijke gegevens. En minstens zo belangrijk: dit test je periodiek, net als een brandoefening, door bewust en gepland de verbinding te verbreken en te kijken of het echt werkt.
“Maar ik vind toch nooit die specialisten”
Een terechte en veelgehoorde zorg: het bouwen en vooral veilig beheren van dit soort platformen vraagt om schaars, hooggekwalificeerd personeel. Ruil je een geopolitiek risico dan niet gewoon in voor een personeelstekort-risico?
Het antwoord is dat soevereiniteit niet betekent dat je alles zelf, on-premises, in eigen beheer hoeft te bouwen en draaien. Er is een sterk en groeiend Europees ecosysteem van gespecialiseerde partijen ontstaan die precies deze complexiteit als dienst leveren. Het verschil met de traditionele hyperscaler-aanpak is dat de architectuur open en gestandaardiseerd blijft: je koopt expertise in, maar je blijft zelf eigenaar van je data en configuratie. Je bent klant, geen gevangene. Uitvoering besteed je uit, de strategische controle houd je zelf.
Het contract is minstens zo belangrijk als de techniek
Techniek en slimme protocollen zijn machteloos als je juridisch met handen en voeten vastzit aan een wurgcontract. NIS2 dwingt organisaties daarom om ketenbeveiliging niet langer op basis van vertrouwen, maar op basis van harde, contractuele afspraken in te richten: het recht op onafhankelijke, periodieke audits en sluitende beveiligingswaarborgen.
Een exitstrategie mag nooit een paniekerige bijlage zijn die je pas opstelt als het al misgaat. Vooraf leg je vast onder welke triggers je boetevrij mag vertrekken: structurele schendingen van uptime, datalekken, maar ook geopolitieke gebeurtenissen zoals een overname van je leverancier door een buitenlandse partij of nieuwe sancties. Je spreekt vooraf een redelijke overgangstermijn en vaste tarieven voor transitie-ondersteuning af, zodat een leverancier niet uit rancune de dienstverlening staakt zodra jij vertrekt.
Een cruciale steun in de rug komt van de EU Data Act, die de uittredingskosten (switching charges) die providers jarenlang als lock-in-middel gebruikten, wettelijk afbouwt en verbiedt. Belangrijker nog: providers worden nu ook verplicht om technische migratiebarrières actief weg te nemen en interoperabiliteit te faciliteren. De spelregels op de cloudmarkt zijn daarmee fundamenteel in het voordeel van de afnemer gekanteld.
De laatste, vaak vergeten stap: aantoonbare vernietiging
Zelfs als de exit technisch en contractueel geslaagd is, ligt er mogelijk nog ergens een volledige kopie van je meest gevoelige bedrijfsdata op een afgedankte server bij je oude leverancier. Op “verwijderen” drukken haalt alleen de verwijzing weg; de data zelf blijft fysiek aanwezig totdat die daadwerkelijk overschreven wordt. Onder de standaarden die in NIS2-context worden aangehaald, zoals NIST SP 800-88 en DIN 66399, gaat het om cryptografisch wissen: sleutels vernietigen of schijven meermaals overschrijven, zodanig dat data ook forensisch onherstelbaar is. Het enige geldige bewijs daarvan is een formeel, geauditeerd certificaat van vernietiging. Zonder dat document ben je als organisatie en bestuurder in theorie nog steeds kwetsbaar voor aansprakelijkheid als die data later alsnog op straat belandt.
Voor 10% techniek, voor 90% cultuur
Als er één les is die ik uit al deze bouwstenen wil meegeven, dan is het deze: digitale soevereiniteit is voor een klein deel een kwestie van containers, servers en protocollen. Het overgrote deel is een kwestie van mensen, cultuur en fundamenteel anders leren nadenken over afhankelijkheid en eigenaarschap, ongeacht van welk land die afhankelijkheid komt. Het is geen project dat je bij de IT-afdeling neerlegt en afvinkt, het is een organisatiebrede manier van werken die risico’s verkleint en tegelijk de veerkracht van je organisatie vergroot.
Dat opent ook een interessant, minder alarmerend en meer constructief toekomstperspectief. Naarmate Europese organisaties bewuster omgaan met waar hun meest waardevolle data en processen landen, en welke partij daar uiteindelijk zeggenschap over heeft, groeit er vanzelf ruimte voor een sterker, evenwichtiger Europees technologielandschap, niet als tegenreactie tegen één land, maar als volwassen aanvulling naast bestaande, gewaardeerde internationale samenwerkingen. De keuze wie vandaag mede de sleutel van jouw bedrijfsnetwerk in handen heeft, is dus geen politieke stellingname. Het is gewoon goed risicomanagement, met impact op de lange termijn.
Waar dat in de praktijk toe kan leiden, ervaar ik op dit moment zelf aan den lijve. In mijn eigen R&D-omgeving werk ik momenteel aan de implementatie van een EU-soeverein taalmodel, een LLM die volledig binnen Europese infrastructuur en jurisdictie draait, zonder de data-afhankelijkheden die de grote Amerikaanse AI-platformen vandaag kenmerken. De eerste bevindingen zijn veelbelovend, en ook leerzaam op punten waar de theorie en de praktijk nog niet helemaal overeenkomen. Daarover binnenkort meer, in een volgend artikel.
Zelf de regie pakken
Ik help organisaties in Nederland en de bredere EU die kritieke processen, data en infrastructuur beheren, om deze stap niet als abstracte theorie of als geopolitiek statement te laten liggen, maar nuchter, concreet en pragmatisch te zetten: van identiteit en DNS tot werkplek, en van exit-by-design architectuur tot een verantwoorde transitie weg bij een leverancier, ongeacht welke partij of welk land daarbij aan de andere kant van de tafel zit. Als architect en transformatiecoach heb ik affiniteit met de relevante wet- en regelgeving, zoals NIS2 en de Cyberbeveiligingswet, maar ik ben geen jurist. In de praktijk werk ik daarom nauw samen met de sleutelpersonen binnen de klantorganisatie zelf, zodat de specifieke waarden, normen en verantwoordelijkheden van die organisatie leidend blijven en niemand het overzicht verliest. Net zo goed werk ik samen met de IT delivery-organisatie: de IT-leiders en engineers die de daadwerkelijke realisatie voor hun rekening nemen. Dankzij mijn brede, multidisciplinaire profiel kan ik daarbij de brugfunctie vervullen tussen strategie, planning en uitvoering, zodat besluiten op bestuurlijk niveau daadwerkelijk landen in werkende, beheersbare techniek, en andersom de praktijkervaring van de uitvoering weer terugvloeit naar strategie en planning. Alles gebouwd volgens de principes die ook in mijn eigen R&D-omgeving dagelijks de praktijktoets doorstaan: zero-touch geautomatiseerde pijplijnen, shift-left security, scheiding van verantwoordelijkheden, en volledige aantoonbaarheid richting NIS2 en de Cyberbeveiligingswet.
Heb je vragen over wat dit voor jouw organisatie betekent, of wil je weten waar je het beste kunt beginnen? Neem gerust contact met me op.
Bertrand de Neve De Neve IT Consulting B.V. — deneveit.nl
Tags: #digitalesoevereiniteit #nis2 #cyberbeveiligingswet #wetweerbaarheidkritiekeentiteiten #exitstrategie #cloudact #eudataact #dataeigenaarschap #identityfederation #keycloak #opensource #eucloud #devsecops #it-architecture
Disclaimer Dit artikel is uitsluitend bedoeld voor informatieve en educatieve doeleinden. De beschreven inzichten, architectuurprincipes en aanpakken weerspiegelen persoonlijke ervaringen en inzichten opgedaan tijdens een specifiek leer- en R&D-traject. Aan de inhoud van dit artikel kunnen geen rechten worden ontleend. De auteur aanvaardt geen aansprakelijkheid voor eventuele schade, directe of indirecte gevolgen voortvloeiend uit het gebruik van de in dit artikel beschreven informatie of methodieken. Wet- en regelgeving waarnaar verwezen wordt, waaronder NIS2, de Cyberbeveiligingswet, de Wet weerbaarheid kritieke entiteiten en de EU Data Act, is aan verandering onderhevig — raadpleeg altijd de meest recente officiële bronnen. Voor toepassing in uw specifieke situatie wordt professioneel en, waar relevant, juridisch advies aanbevolen.
Dit artikel is tot stand gekomen met assistentie van een AI-systeem. De technische implementatie, de inhoudelijke keuzes, de conclusies en de eindredactie zijn volledig van de auteur.
Cover foto : Rotterdam, door Bertrand de Neve