Die drie vragen bepalen samen je datasoevereiniteit. Ze klinken eenvoudig, maar de meeste organisaties kunnen ze niet alle drie beantwoorden. Dat komt niet door slordigheid: het antwoord ligt niet vast in één contract of één leverancierskeuze. Het is de optelsom van beslissingen die je in je infrastructuur hebt genomen, over latency, dataveiligheid, beschikbaarheid, kosten en de vrijheid om later nog een andere kant op te gaan.
Uit onderzoek van Nutanix noemt 80 procent van de IT-leiders soevereiniteit een hoge prioriteit of harde eis bij infrastructuurbeslissingen. In Nederland ziet 23 procent het als topprioriteit en 61 procent als belangrijk, blijkt uit onderzoek van Blauw Research. We nemen je graag mee in waarom soevereiniteit geen aan-uitknop is, welke keuzes hem bepalen, en hoe je hem behandelt als ontwerpvraag in plaats van als inkoopvraag.
Drie termen die vaak door elkaar lopen
De eerste vraag, waar staat je data, klinkt als de makkelijkste van de drie. Toch lopen daar drie begrippen doorheen die vaak worden verward.
- Dataresidentie gaat over de fysieke locatie. Staat je data in een datacenter in Nederland, in de EU, of ergens anders.
- Datalokalisatie is een juridische eis dat data een land of regio niet mag verlaten. Dat is een verplichting, geen keuze.
- Datasoevereiniteit is de vraag onder welke wetgeving je data uiteindelijk valt, wie toegang kan afdwingen, en wie de cryptografische sleutels beheert.
Het verschil is niet academisch. Data die fysiek in Amsterdam staat maar wordt beheerd door een Amerikaanse entiteit, valt mogelijk alsnog onder de Amerikaanse CLOUD Act. Residentie geregeld, soevereiniteit niet.
Waarom soevereiniteit geen aan-uitknop is
De markt verkoopt soevereiniteit graag als een keuze die je één keer maakt. Een soevereine cloud, een Europees datacenter, een vinkje bij de leverancier.
Zo werkt het niet. Het Cloud Sovereignty Framework van de Europese Commissie beoordeelt soevereiniteit langs meerdere assen tegelijk: strategische aansluiting, juridische afhankelijkheden, controle over data en AI, operationele onafhankelijkheid, transparantie in de toeleveringsketen, openheid van technologie, beveiliging en compliance, en afhankelijkheid van de onderliggende infrastructuur.
Acht dimensies. Geen enkele omgeving scoort op alle acht maximaal, en dat hoeft ook niet. De vraag is welke dimensies voor jouw organisatie zwaar wegen en welke minder.
Dat maakt soevereiniteit een uitkomst, geen product. De uitkomst van keuzes die je maakt op vijf terreinen die elkaar voortdurend beïnvloeden.
De vijf keuzes die je soevereiniteit bepalen
- Latency. Waar de verwerking plaatsvindt, bepaalt hoe snel je antwoord krijgt. Een AI-model dat meekijkt bij een klinische beslissing of een fraudesignaal afgeeft voordat een transactie doorgaat, kan de omweg naar een centrale cloud niet hebben. Kies je voor lokale verwerking om die reden, dan verandert daarmee ook je soevereiniteitspositie. Vaak in gunstige zin.
- Dataveiligheid. Wie kan er technisch bij, en wie kan er juridisch bij. Dat zijn twee verschillende vragen. Versleuteling helpt alleen als jij de sleutels beheert. Zodra de sleutel bij je leverancier ligt, is toegang een kwestie van wie welke bevoegdheid heeft.
- Beschikbaarheid. Draait je kritische toepassing door als de externe verbinding wegvalt? Voor een ziekenhuis of een gemeente is dat geen theoretische vraag. Lokaal draaien verhoogt je continuïteit én je controle, maar vraagt om capaciteit en beheer op locatie.
- Kosten en schaalbaarheid. Alles zelf on-premises draaien geeft maximale controle en maximale kosten. De publieke cloud draait het om. De meeste organisaties komen uit in het midden, niet uit compromis maar omdat verschillende workloads verschillende antwoorden verdienen.
- Keuzevrijheid. Kun je nog weg bij je huidige leverancier zonder je landschap opnieuw te bouwen? Dit is de keuze die het langst onzichtbaar blijft en het hardst aankomt op het moment dat je hem nodig hebt.
Elke keuze op één van deze vijf terreinen verschuift je positie op de andere vier. Dat is precies waarom je soevereiniteit niet kunt inkopen: je kunt hem alleen ontwerpen.
De afhankelijkheid die je zelf hebt opgebouwd
Soevereiniteit gaat meestal over de vraag welke overheid bij je data kan. Er is een tweede vorm die dichterbij ligt en die veel organisaties de afgelopen twee jaar pijnlijk hebben leren kennen.
De virtualisatielaag onder je datacenter is jarenlang een gegeven geweest. Je koos de standaard in de markt, bouwde je omgeving erop, en verlengde het contract zonder dat iemand daar een besluit van maakte. Tot de rekening opeens verdubbelde of verdrievoudigde, perpetual licenties verdwenen en je gedwongen werd naar bundels waarin je betaalt voor functionaliteit die je niet gebruikt.
Wat toen bleek: overstappen kon niet zomaar. De omgeving was gebouwd op aannames van dat ene platform. Beheertools, automatisering, kennis van je team, alles zat eraan vast. Je had geen leveranciersrelatie meer, je had een afhankelijkheid.
Dat is soevereiniteit in de meest praktische zin. Het Cloud Sovereignty Framework noemt operationele onafhankelijkheid en openheid van technologie niet voor niets als aparte dimensies. Ze staan los van de vraag waar je data fysiek staat, maar ze bepalen wel of je nog kunt bewegen.
De les is niet dat je je huidige platform moet vervangen. De les is dat de vraag “wat kost het me om hier weg te gaan” een ontwerpvraag is die je stelt voordat je iets bouwt, niet op het moment dat de offerte binnenkomt.
Dat betekent concreet: bouw op standaarden waar dat kan, zorg dat je workloads verplaatsbaar zijn, en beoordeel een platform niet alleen op wat het vandaag kost maar op wat het je later kost om ervan af te stappen. Containers helpen daarbij, niet omdat ze modern zijn, maar omdat ze de applicatie loskoppelen van de omgeving eronder.
Wat de Cyberbeveiligingswet hieraan toevoegt
Op 15 augustus 2026 treedt de Cyberbeveiligingswet in werking, de Nederlandse implementatie van de Europese NIS2-richtlijn. De Eerste Kamer stemde in op 7 juli. Ruim 8.000 Nederlandse organisaties vallen er direct onder, en via ketenverplichtingen werkt de wet door naar tienduizenden leveranciers.
Er is geen overgangstermijn.
Voor het soevereiniteitsvraagstuk is vooral die ketenverplichting relevant. De wet vraagt niet alleen dat jouw organisatie haar zaken op orde heeft, maar dat je ook kunt aantonen dat je leveranciers dat hebben. Waar je data staat, wie erbij kan en welke partijen in je keten zitten, wordt daarmee een vraag die je moet kunnen beantwoorden, niet alleen een vraag die je jezelf stelt.
Sectoren die er direct onder vallen: zorg, energie, transport, overheid, en meer. Voor veel organisaties in die sectoren is de vraag niet of ze onder de wet vallen, maar of ze kunnen aantonen wat ze hebben geregeld.
Volledige autonomie is niet het doel
Hier gaat het gesprek vaak mis. Soevereiniteit wordt gepresenteerd als iets dat je helemaal wel of helemaal niet hebt, en dat maakt het onhaalbaar.
Nederlandse IT-beslissers zijn daar realistischer in. Uit het onderzoek door Blauw research blijkt dat volledige autonomie als onrealistisch wordt gezien, maar dat er breed draagvlak is voor maximale of strategische soevereiniteit: zo veel mogelijk regie, binnen de grenzen van wat technisch en commercieel werkbaar is.
Dat is de werkbare houding. Je hoeft niet je hele landschap in een Nederlands datacenter te zetten. Je moet weten welke data en welke workloads dat wél nodig hebben, en die keuze bewust maken.
Praktisch betekent dat differentiëren. Algemene analytics kan prima bij een hyperscaler draaien. Gevoelige AI-inferentie op patiëntdata of burgergegevens hoort in een omgeving waar je de controle hebt. Dat is realistischer dan proberen alles in één keer soeverein te maken.
Het onderzoek van Nutanix laat zien dat organisaties precies dat doen. In de zorg draait 54 procent gecontaineriseerde applicaties on-premises of in een private cloud, tegen 47 procent in de publieke cloud. Geen exclusieve keuze, maar een verdeling.
Hoe je dit als ontwerpvraag aanpakt
- Behandel soevereiniteit als architectuurvraagstuk en het wordt hanteerbaar.
- Classificeer je data. Niet alle data is even gevoelig. Zonder onderscheid moet je alles op het zwaarste niveau beschermen, en dat is duur en traag.
- Bepaal per workload waar die hoort. Op basis van latency, dataclassificatie, compliance-eisen en kosten. Vaak blijkt maar een deel echt lokaal te moeten.
- Zorg dat workloads kunnen verhuizen. Dit is het punt dat de meeste organisaties onderschatten. Verandert de wetgeving, of verandert je risicobeoordeling, dan wil je een workload kunnen verplaatsen zonder hem opnieuw te bouwen. Containers en een consistente beheerlaag maken dat mogelijk.
- Beheer je eigen sleutels waar het ertoe doet. Versleuteling waarvan de sleutel bij een derde ligt, biedt bescherming tegen inbraak, niet tegen rechtmatige toegang door die derde.
- Leg vast wat je hebt geregeld. Voor NEN7510, AVG en straks de Cyberbeveiligingswet moet je kunnen laten zien waar data staat, wie erbij kan en wat er is gebeurd. Aantoonbaarheid is geen bijproduct, het is een ontwerpeis.
- Herbeoordeel periodiek. Je positie verschuift als wetgeving verandert, als je leverancier van eigenaar wisselt, of als je nieuwe workloads toevoegt. Eén keer inrichten is niet genoeg.
Hoe wij dit aanpakken
Bij co-one begint dit bij workload placement: per toepassing bepalen waar die hoort te draaien, op basis van de vijf afwegingen hierboven. Niet als eenmalige architectuurkeuze, maar als beslissing die je opnieuw kunt nemen als de eisen veranderen.
Keuzevrijheid is daarbij geen bijvangst, maar een ontwerpeis. We bouwen omgevingen waarin je workloads niet vastzitten aan de laag eronder, zodat een verandering in prijs, wetgeving of strategie geen migratieproject van achttien maanden wordt. Dat betekent soms een ander platform dan je gewend bent, en het betekent altijd dat we vooraf uitrekenen wat de uitstapkosten zijn.
Daaromheen bouwen we het fundament. Netwerk en connectiviteit die locaties en cloudomgevingen betrouwbaar verbinden. Observability zodat je ziet waar wat draait. Cyber resilience zodat een incident geen uitval van zorg of dienstverlening betekent, en zodat je herstelvermogen aansluit bij wat de Cyberbeveiligingswet van je vraagt.
Met Nutanix als strategische partner bouwen we omgevingen waarin dezelfde workload in je eigen datacenter, in een private cloud of op locatie kan draaien, met één beheerlaag eroverheen. Verandert je afweging, dan verplaats je de workload in plaats van dat je opnieuw begint.
Dat is wat soevereiniteit in de praktijk betekent: niet één omgeving die aan alle eisen voldoet, maar de vrijheid om per workload de juiste keuze te maken en die keuze later te herzien.
Waar je begint
- Breng in kaart welke data je verwerkt, hoe gevoelig die is en onder welke jurisdictie die nu valt.
- Check of je onder de Cyberbeveiligingswet valt, direct of via de keten. Vanaf 15 augustus geldt hij, zonder overgangstermijn.
- Bepaal per workload of de huidige plek nog de juiste is, gegeven latency, gevoeligheid en beschikbaarheidseisen.
- Kijk of je omgeving verplaatsing toestaat. Zo niet, dan is dat je eerste architectuurschuld.
- Reken uit wat het je zou kosten om je belangrijkste platform te verlaten. Kun je dat niet beantwoorden, dan weet je genoeg.
Weten waar jouw organisatie staat?
We beginnen met een goede analyse: welke toepassingen draaien waar, wat betekent dat voor je positie onder de AVG, NEN7510 en de Cyberbeveiligingswet, en welke verschuivingen leveren het meeste op. Concreet, binnen enkele weken. Dat vormt de basis voor verdere ontwikkeling.
Bronnen: 8th Annual Nutanix Enterprise Cloud Index en de healthcare-editie daarvan (juni 2026), onderzoek uitgevoerd door Wakefield Research in november 2025 onder 1.600 IT-leiders in veertien markten waaronder Nederland. Onderzoek Blauw in opdracht van Leaseweb, maart 2026, onder 383 Nederlandse IT-beslissers. Cloud Sovereignty Framework, Europese Commissie. Cyberbeveiligingswet: aangenomen door de Eerste Kamer op 7 juli 2026, inwerkingtreding 15 augustus 2026.
Meer nieuws




