De drie dimensies van soevereiniteit: data-, operationele- en technische soevereiniteit

Datasoevereiniteit: waar staat data, wie kan erbij en welke wetten gelden?

Datasoevereiniteit is waar het gesprek over soevereiniteit meestal begint. Het gaat om waar data wordt opgeslagen, hoe het wordt verwerkt en wie er toegang toe kan krijgen. Voor Europese organisaties draait het vaak om dataresidentie binnen de EU, naleving van de AVG en duidelijkheid of persoonlijke of gevoelige data een bepaald rechtsgebied verlaat.

Maar het gaat ook over encryptie, customer-managed keys en controle over de toegangspaden tot data. Zeker voor gereguleerde workloads hangen vertrouwen, compliance en contractuele verplichtingen niet alleen af van waar data staat, maar ook van de mate waarin een organisatie kan aantonen wie data heeft gelezen of gebruikt.

De fysieke locatie van data is daarom maar één deel van het vraagstuk. De ingewikkeldere vragen gaan over jurisdictie en controle. Welke juridische entiteit levert de dienst? Welk rechtsstelsel kan die partij verplichten om informatie te verstrekken? Wie heeft toegang tot data, metadata en supportsystemen? Wie beheert de encryptiesleutels? En kan de klant voorkomen dat een provider toegang krijgt wanneer dat nodig is?

De Amerikaanse CLOUD Act wordt vaak genoemd in dit verband. Het is echter te simpel om te zeggen dat Amerikaanse autoriteiten zomaar toegang kunnen krijgen tot Europese cloudomgevingen. De wet kan providers die eronder vallen verplichten om data die zij in bezit, beheer of onder controle hebben te bewaren of te verstrekken, ook wanneer die data zich buiten de VS bevindt. Voor bestuurders zit de kern daarom in de formulering possession, custody or control. De locatie is belangrijk, maar is slechts één onderdeel van het soevereiniteitsverhaal.

Dat is ook waarom de sovereign cloud-initiatieven van hyperscalers belangrijk zijn. AWS, Microsoft en Google reageren allemaal op dezelfde Europese behoefte: organisaties willen profiteren van de schaal en innovatiekracht van hyperscale cloud, maar willen tegelijkertijd meer garanties over de locatie van data, wie de omgeving kan beheren, wie toegang heeft tot supportsystemen, waar encryptiesleutels worden beheerd en hoeveel afhankelijkheid van wereldwijde infrastructuur overblijft.

De aanpak rondom deze garanties verschilt per provider. AWS positioneert de European Sovereign Cloud als een aparte cloud binnen de EU, met Europese governance, operationele teams binnen de EU en technische scheiding van bestaande AWS-regio’s. Microsoft benadert sovereign cloud breder, met mogelijkheden binnen public cloud, private cloud en clouds die door partners worden beheerd. Daaronder vallen onder andere dataresidentie, lokale controle op toegang, extern sleutelbeheer in managed HSM, confidential computing en hybride of disconnected oplossingen. Google biedt eveneens verschillende niveaus, van data boundary controls binnen de public cloud tot dedicated sovereign oplossingen met lokale partners en Google Distributed Cloud in connected of air-gapped vorm.

Dit zijn betekenisvolle ontwikkelingen. Ze kunnen niet-Europese operationele toegang beperken, de onderbouwing richting toezichthouders versterken, organisaties meer controle geven over sleutelbeheer en betere opties bieden voor gevoelige workloads. Tegelijkertijd tonen ze aan dat hyperscalers soevereiniteit inmiddels beschouwen als een criterium dat meeweegt op boardniveau, en niet langer alleen als een niche binnen compliance.

Zorgvuldige beoordeling blijft echter wel noodzakelijk. Een sovereign cloud-dienst van een provider met een Amerikaans hoofdkantoor kan alleen als buiten het bereik van Amerikaanse zeggenschap worden beschouwd wanneer het juridische, contractuele én technische model die conclusie ondersteunt.

Een beter verdedigbare conclusie is dat dergelijke oplossingen de blootstelling kunnen verkleinen en organisaties meer controle kunnen geven. De resterende juridische en operationele risico’s moeten vervolgens per workload worden beoordeeld.

Voor Europese boards is de vraag daarom breder dan alleen waar data wordt opgeslagen. Welke juridische entiteit heeft het contract met ons? Welk rechtsgebied is van toepassing? Waar worden data, metadata, logs en back-ups opgeslagen? Wie heeft toegang tot de management plane? Wie verzorgt support? Wie beheert de encryptiesleutels? Wat gebeurt er wanneer een overheid een bevel tot verstrekking uitvaardigt? Welke contractuele afspraken zijn daadwerkelijk afdwingbaar? Welk bewijs kunnen we aan toezichthouders en klanten tonen?

Een veelvoorkomende misvatting is dat opslag in Europa data automatisch veilig maakt. Datasoevereiniteit gaat over veel meer dan locatie. Het gaat ook over juridische zeggenschap, toegang, operationele controle, encryptie, metadata, supportprocessen en de mogelijkheid om die controle aan te tonen.

Datasoevereiniteit is zichtbaar, omdat het direct raakt aan regelgeving, zorgen van klanten en publieke perceptie. Maar dat datasoevereiniteit het meest zichtbare onderdeel is, betekent niet dat daarmee het hele soevereiniteitsvraagstuk is afgedekt. Een afspraak over dataresidentie zonder duidelijkheid over toegang, zeggenschap en jurisdictie kan een gevoel van zekerheid geven zonder dat daar voldoende controle tegenover staat.

Operationele soevereiniteit: wie kan de dienst beheren, wijzigen of onderbreken?

Operationele soevereiniteit draait om controle in de dagelijkse praktijk. De centrale vraag is eenvoudig: als er iets belangrijks gebeurt, wie heeft dan de bevoegdheid, de toegang en de mogelijkheid om te handelen?

Daarvoor moet je verder kijken dan de locatie waar een systeem wordt gehost. Wie kan wijzigingen goedkeuren en doorvoeren? Wie heeft toegang tot productieomgevingen? Wie kan administratoraccounts aanmaken of verwijderen? Wie kan tijdens een incident logs inzien? Wie kan back-ups herstellen, diensten opnieuw starten, configuraties aanpassen of integraties afsluiten? En als de primaire leverancier niet beschikbaar is: wie kan de dienstverlening dan draaiende houden?

Juist deze operationele details bepalen hoeveel controle een organisatie onder druk daadwerkelijk heeft. Een platform kan op papier aan alle eisen voldoen, maar wanneer alleen een externe leverancier het kan herstellen, incidenten kan onderzoeken of kritieke configuraties kan aanpassen, blijft de operationele soevereiniteit beperkt.

This is why the assumption "on-premises equals control" is too simple. An on-premises environment can still depend on a vendor for firmware, licenses, identity services, managed security, remote support, or scarce internal skills. If the organization owns the hardware but relies on a single supplier to operate or recover the service, control is weaker than it appears.

Daarom is ook de aanname dat on-premises automatisch meer controle betekent te eenvoudig. Een on-premises omgeving kan nog steeds afhankelijk zijn van een leverancier voor firmware, licenties, identity services, managed security, remote support of specialistische kennis. Een organisatie kan de hardware zelf bezitten en toch sterk afhankelijk blijven van één leverancier om een dienst te beheren of te herstellen.

Het omgekeerde geldt eveneens. Ook binnen een omgeving van een hyperscaler kan een organisatie veel operationele controle behouden. Bijvoorbeeld door identity governance goed in te richten, duidelijke grenzen voor support vast te leggen, toegang door de provider te beheersen, uitgebreide logging toe te passen, herstelprocedures regelmatig te testen en solide contractuele afspraken te maken. Volledige onafhankelijkheid is bovendien niet voor iedere workload noodzakelijk. Hoeveel controle nodig is, hangt af van het risico en de bedrijfskritische aard van de toepassing.

Voor interne applicaties met een beperkt risicoprofiel kunnen eenvoudige supportafspraken en recoveryplannen voldoende zijn. Bij kritieke systemen, zoals betalingsplatformen, zorgdiensten of publieke dienstverlening, ligt de lat hoger. Dan worden strengere toegangscontroles, geteste exitstrategieën, documentatie die direct bruikbaar is voor audits en operationele continuïteit bij veranderingen aan leverancierszijde essentieel.

Ook regelgeving beweegt in deze richting. NIS2 breidt de eisen rond cybersecurity-risicomanagement en rapportage uit naar meer kritieke sectoren. DORA stelt, specifiek voor financiële instellingen, eisen aan operationele weerbaarheid, waaronder ICT-risicomanagement, incidentafhandeling, het testen van weerbaarheid en het beheersen van risico’s bij derde partijen. De gemene deler is duidelijk: organisaties moeten hun externe afhankelijkheden kennen, beheersen en kunnen verantwoorden.

Daarmee maakt operationele soevereiniteit een abstract risico concreet. Uiteindelijk gaat het om bedrijfscontinuïteit: kan een organisatie haar dienstverlening voortzetten, aantonen dat zij controle houdt en onder druk zelf beslissingen nemen?

Technische soevereiniteit: hoeveel vrijheid heb je om van koers te veranderen?

Technische soevereiniteit draait om portabiliteit, interoperabiliteit en het voorkomen van afhankelijkheden waar je later nauwelijks nog vanaf kunt. De vraag is hoeveel ruimte een organisatie heeft om technologie te verplaatsen, vervangen, integreren of opnieuw te ontwerpen zonder dat de kosten of inspanning een verandering praktisch onmogelijk maken.

Deze dimensie ligt dicht tegen architectuur aan, maar heeft ook directe gevolgen voor de business. Sterke afhankelijkheid van specifieke technologie kan de onderhandelingspositie verzwakken, strategische opties beperken en toekomstige veranderingen duurder maken.

De mate van technische soevereiniteit wordt onder meer bepaald door dataformaten, API’s, providerspecifieke platformdiensten, automation tooling, identity management, deploymentstrategieën en beschikbare kennis. Providerspecifieke diensten kunnen juist veel snelheid en innovatie opleveren. Tegelijkertijd wordt een toekomstige migratie vaak complexer naarmate een organisatie hier sterker op leunt.

Ook hier ligt een veelvoorkomende misvatting op de loer: open source staat niet automatisch gelijk aan soevereiniteit. Open source kan bepaalde afhankelijkheden verminderen, zeker wanneer standaarden breed worden ondersteund, de community volwassen is en portabiliteit goed is geregeld. Maar ook open-sourceoplossingen vragen om support, security-updates, lifecyclemanagement, integratie en specialistische kennis. Slecht beheerde open source kan daardoor net zo goed nieuwe afhankelijkheden creëren.

Technische soevereiniteit zegt dus vooral iets over de bewegingsruimte die een organisatie op langere termijn behoudt. Of een workload voldoende soeverein is, hangt uiteindelijk af van de combinatie van technische flexibiliteit, operationele controle en datagovernance binnen de specifieke context.

De afwegingsmatrix

Het relatieve belang van de drie dimensies verschilt per organisatie en per workload.

Voor publieke organisaties kunnen alle drie zwaar wegen. Data kan gevoelig zijn, de continuïteit van dienstverlening kan maatschappelijk of politiek van groot belang zijn en technische afhankelijkheid kan op de langere termijn een strategisch risico vormen wanneer publieke diensten beheersbaar moeten blijven.

In de zorg en financiële sector wegen data- en operationele soevereiniteit vaak extra zwaar. Patiëntgegevens, financiële data, betalingen en gereguleerde rapportages vragen om juridische duidelijkheid, auditability en robuuste dienstverlening.

Voor veel digitale bedrijven in de private sector kan technische soevereiniteit juist belangrijker zijn. Daar spelen snelheid, onderhandelingspositie, kostenbeheersing en het voorkomen van te grote afhankelijkheid van één platformmodel vaak een belangrijke rol.

Ook binnen één organisatie verschilt de benodigde mate van soevereiniteit per workload. Een publieke website, een HR-systeem, een customer analytics-platform, een betaalomgeving en een nationale digitale identiteitsdienst vragen ieder om een andere vorm en mate van controle.

De praktische realiteit

De drie dimensies bewegen niet altijd in dezelfde richting. Meer controle op het ene vlak kan ten koste gaan van flexibiliteit op een ander.

Sterkere datasoevereiniteit kan bijvoorbeeld strengere eisen stellen aan dataresidentie, sleutelbeheer en juridische bescherming. Dat kan de keuze uit clouddiensten beperken, automatisering bemoeilijken of de operatie complexer maken.

Meer operationele soevereiniteit kan betekenen dat een organisatie meer lokaal moet kunnen beheren, strengere toegangsprocessen nodig heeft en herstel buiten het primaire providermodel moet kunnen uitvoeren en testen. Dat geeft meer zekerheid, maar vraagt ook om extra mensen, governance, monitoring en soms dubbele voorzieningen.

Meer technische soevereiniteit kan lock-in verminderen door te kiezen voor open standaarden en portabiliteit. Maar wie providerspecifieke diensten zoveel mogelijk vermijdt, kan ook snelheid verliezen, extra integratiewerk creëren en minder eenvoudig profiteren van innovatie die daadwerkelijk businesswaarde oplevert.

Dat is de kern van de afweging. keuzes rondom soevereiniteit kunnen risico’s verkleinen, maar brengen vaak ook extra kosten, complexiteit en een lagere snelheid met zich mee. De juiste keuze is de keuze die past bij het risico, de bedrijfskritische aard en het afhankelijkheidsprofiel van de workload.

De juiste balans vinden

In plaats van te vragen of een organisatie soeverein is, is een nuttigere vraag: welke dimensies van soevereiniteit zijn voor deze workload relevant, en welke mate van afhankelijkheid zijn we bereid te accepteren?

Dat is in essentie een governancevraagstuk. Soevereiniteit krijgt pas praktische waarde wanneer het helpt bepalen waar controle essentieel is, waar afhankelijkheid acceptabel blijft, waar leveranciers meer garanties moeten bieden en waar extra complexiteit simpelweg niet opweegt tegen de voordelen.

De volgende stap is daarom om afhankelijkheden zichtbaar te maken. Veel organisaties hebben moeite om de vragen over hun huidige en gewenste situatie met voldoende zekerheid te beantwoorden. Er zijn aannames, architectuurdiagrammen, contracten en gedeeltelijke inventarisaties, maar vaak ontbreekt een gevalideerd beeld van waar de kritieke afhankelijkheden daadwerkelijk zitten.

Juist daar lopen discussies over soevereiniteit vaak vast. Niet omdat organisaties het belang niet zien, maar omdat ze onvoldoende zicht hebben op hun daadwerkelijke afhankelijkheden. Zonder dat inzicht wordt het moeilijk om onderbouwde keuzes te maken.

De volgende blog gaat daarom dieper in op deze zichtbaarheid: waarom inzicht in afhankelijkheden de noodzakelijke basis vormt voor beslissingen waar bestuurders, technologieleiders en riskteams gezamenlijk achter kunnen staan.