EU-vereisten voor datasoevereiniteit: Wat de GDPR vereist versus wat soevereiniteit daadwerkelijk inhoudt

Vraag de meeste compliance-teams wat EU-datasoevereiniteit vereist en ze zullen naar de GDPR wijzen. Vraag hun juridisch adviseur wat Schrems II vereist en ze beschrijven Transfer Impact Assessments en Standaard Contractuele Clausules. Vraag hun CISO wat er gebeurt als er een Amerikaanse dagvaarding bij het hoofdkantoor van hun cloudprovider binnenkomt, en het wordt stil in de kamer.

De verwarring is begrijpelijk. “Dataresidentie“, “datalokalisatie” en “datasoevereiniteit” worden in de meeste zakelijke gesprekken door elkaar gebruikt — maar ze zijn juridisch en architectonisch verschillend. Een organisatie kan op papier aan elke GDPR-dataresidentieplicht voldoen en toch structureel blootgesteld blijven aan toegang door buitenlandse overheden. Begrijpen waar de vereisten van de GDPR eindigen en waar echte datasoevereiniteit begint, is geen academisch verschil. Het is het compliance-gat dat gegevensbeschermingsautoriteiten nu actief handhaven.

Samenvatting voor het management

Belangrijkste idee: De GDPR stelt vereisten voor dataresidentie en overdracht van EU-persoonsgegevens — maar GDPR-naleving en datasoevereiniteit zijn niet synoniem. Dataresidentie bepaalt waar data moet worden opgeslagen. Datasoevereiniteit bepaalt wie toegang heeft en onder welke rechtsbevoegdheid. Voor organisaties die gebruikmaken van cloudinfrastructuur met een Amerikaans hoofdkantoor, biedt GDPR-conforme dataresidentie in een datacenter in Frankfurt geografische naleving, maar laat data juridisch toegankelijk voor Amerikaanse overheidsverzoeken onder de CLOUD Act — een structurele blootstelling die Standaard Contractuele Clausules niet kunnen oplossen. Echte datasoevereiniteit vereist architecturale controles — door de klant beheerde encryptiesleutels, single-tenant Europese inzet, beleidsmatig afgedwongen geofencing — die ongeautoriseerde toegang technisch onmogelijk maken, niet alleen contractueel verboden.

Waarom dit belangrijk is: Oostenrijkse, Franse en Italiaanse gegevensbeschermingsautoriteiten hebben al geoordeeld dat bepaalde Amerikaanse cloudconstructies in strijd zijn met de GDPR. GDPR-boetes kunnen oplopen tot 4% van de wereldwijde jaaromzet. De NIS 2-richtlijn voegt strafrechtelijke aansprakelijkheid voor het management toe. Uit het Kiteworks 2026 Data Security and Compliance Risk Report blijkt dat 33% van de organisaties het afgelopen jaar een incident met betrekking tot datasoevereiniteit heeft meegemaakt, ondanks dat 44% zichzelf als goed geïnformeerd beschrijft. Organisaties die residentie verwarren met soevereiniteit zijn niet compliant — ze zijn blootgesteld.

Belangrijkste inzichten

1. Dataresidentie, lokalisatie en soevereiniteit zijn juridisch verschillend. Residentie bepaalt waar data fysiek wordt opgeslagen. Lokalisatie vereist dat data binnen het land van verzameling blijft. Soevereiniteit bepaalt wie toegang heeft en onder welke rechtsbevoegdheid. Voldoen aan één betekent niet automatisch voldoen aan de andere.
2. De GDPR stelt residentievereisten, maar geen volledige soevereiniteit. Artikelen 44–49 beperken grensoverschrijdende overdrachten — maar naleving voorkomt niet dat een verzoek op basis van de Amerikaanse CLOUD Act toegang krijgt tot data die door een aanbieder met een Amerikaans hoofdkantoor in een EU-datacenter wordt opgeslagen. Locatie is geen rechtsbevoegdheid.
3. Schrems II heeft residentie als onvoldoende herijkt. Door Transfer Impact Assessments te vereisen en klantgestuurde encryptie aan te wijzen als noodzakelijke aanvullende maatregel, heeft het HvJ-EU vastgesteld dat geografische locatie geen vervanging is voor rechtsbevoegdheidscontrole.
4. Architecturale soevereiniteit dicht wat contracten niet kunnen. Standaard Contractuele Clausules binden partijen, maar kunnen een juridisch verzoek van de Amerikaanse overheid niet buiten werking stellen. Door de klant beheerde encryptiesleutels buiten de infrastructuur van de aanbieder maken het technisch onmogelijk voor de aanbieder om leesbare data te produceren, ongeacht welk juridisch verzoek wordt ontvangen.
5. NIS 2 en DORA breiden soevereiniteitsverplichtingen uit voorbij de GDPR. De NIS 2-richtlijn en DORA leggen extra verplichtingen op rond soevereiniteit in de toeleveringsketen, incidentrapportage en managementaansprakelijkheid, bovenop de GDPR. Organisaties in gereguleerde sectoren moeten aan alle drie de kaders tegelijk voldoen.

Definitie van de termen: wat residentie, lokalisatie en soevereiniteit echt betekenen

Dataresidentie verwijst naar de fysieke geografische locatie waar data wordt opgeslagen en verwerkt. Een dataresidentievereiste betekent: deze data moet op servers binnen deze rechtsbevoegdheid worden opgeslagen. De GDPR creëert feitelijke residentievereisten via haar beperkingen op overdracht — door te beperken waar persoonsgegevens naartoe mogen, worden organisaties onder druk gezet om data binnen de EU te houden. Maar residentie is een kwestie van locatie, niet van controle. Data kan fysiek in Duitsland staan, maar tegelijkertijd juridisch toegankelijk blijven voor een buitenlandse overheid.

Datalokalisatie is een strengere vorm van residentie: de eis dat data niet alleen lokaal wordt opgeslagen, maar binnen het land van verzameling blijft. Sommige nationale regels en sectorspecifieke voorschriften binnen de EU leggen lokalisatieverplichtingen op bovenop de GDPR — vooral voor zorgdata, financiële transacties en overheidsgegevens.

Datasoevereiniteit is het breedste concept. Het verwijst naar het principe dat data wordt beheerst door de wetten van de rechtsbevoegdheid waar het zich bevindt — en dat de controlerende organisatie daadwerkelijke juridische en technische controle heeft over wie toegang krijgt. Soevereiniteit wordt niet bereikt door simpelweg een EU-datacenter te kiezen. Een Amerikaanse aanbieder die een datacenter in Frankfurt exploiteert, is geen soevereine Europese infrastructuurkeuze; het is een Europees adres met Amerikaanse juridische blootstelling.

Het praktische gevolg: een organisatie kan aan elke GDPR-dataresidentie-eis voldoen — EU-datacenters, gedocumenteerde overdrachtsmechanismen, conforme subverwerkers — en toch geen datasoevereiniteit bereiken als de aanbieder een Amerikaans hoofdkantoor heeft en de encryptiesleutels beheert.

Wat de GDPR echt vereist voor dataresidentie en overdrachten

De GDPR bevat geen algemene verplichting dat EU-persoonsgegevens binnen de EU moeten worden opgeslagen. Hoofdstuk V (Artikelen 44–49) beperkt wanneer EU-persoonsgegevens buiten de EU/EER mogen worden overgedragen — via adequaatheidsbesluiten, Standaard Contractuele Clausules, Bindende bedrijfsvoorschriften of andere goedgekeurde mechanismen. In de praktijk zorgt Hoofdstuk V voor sterke residentiedruk: als er geen geldig overdrachtsmechanisme is voor een bepaalde bestemming, moet de data in de EU blijven.

Voor de meeste organisaties die Amerikaanse cloudproviders gebruiken, zijn SCC’s het belangrijkste mechanisme — aangevuld, sinds Schrems II, met Transfer Impact Assessments die beoordelen of de Amerikaanse wetgeving de effectiviteit van deze SCC’s ondermijnt. De eis van GDPR Artikel 32 voor “passende technische en organisatorische maatregelen” wordt sinds Schrems II door gegevensbeschermingsautoriteiten geïnterpreteerd als een vereiste voor aantoonbare technische controles die in verhouding staan tot het vastgestelde risico. De EDPB-aanbevelingen 01/2020 noemen klantgestuurde encryptie met sleutels die uitsluitend binnen de EER worden beheerd als de technische maatregel die toegang onder de CLOUD Act kan voorkomen. Hier komen de GDPR-residentievereisten en soevereiniteitsarchitectuur samen: echte Artikel 32-naleving voor overdrachten door Amerikaanse aanbieders vereist dezelfde klant-sleutel-controlearchitectuur die soevereiniteit vereist.

Het CLOUD Act-gat: waarom residentie geen soevereiniteit is

De Amerikaanse CLOUD Act verplicht Amerikaanse bedrijven om data die zij beheren te overhandigen bij een geldig verzoek van de Amerikaanse overheid, ongeacht waar die data fysiek is opgeslagen. Een Amerikaanse aanbieder met een datacenter in Frankfurt is geen Europese organisatie — het is een Amerikaanse organisatie met Europees vastgoed. Het verzoek vereist geen Europese rechterlijke uitspraak, informeert de datacontroller of betrokkene niet, en de aanbieder moet voldoen ongeacht het contract met de Europese klant. Standaard Contractuele Clausules leggen vast wat de aanbieder van plan is te doen; ze kunnen niet veranderen wat de Amerikaanse wet verplicht.

Het EU-VS Data Privacy Framework (2023) biedt een overdrachtsmechanisme, maar heft de CLOUD Act niet op. Het past het toezicht op Amerikaanse inlichtingenoperaties aan; het voorkomt niet dat CLOUD Act-verzoeken aanbieder-gecontroleerde data bereiken. Privacyvoorvechters zijn al juridische procedures gestart. Permanente compliance-infrastructuur bouwen op DPF betekent voortdurende juridische onzekerheid accepteren.

De enige controle die dit gat sluit is architecturaal: door de klant beheerde encryptie met sleutels die volledig buiten de infrastructuur van de aanbieder worden gehouden. Wanneer de aanbieder geen toegang heeft tot de sleutels, levert een CLOUD Act-verzoek alleen ciphertext op — juridisch verkregen, maar onleesbaar. De aanbieder is technisch niet in staat om aan een decryptieverzoek te voldoen, ongeacht de juridische druk. Architectuur voorkomt wat contracten niet kunnen. Dit is precies wat de EDPB bedoelt met een “technische aanvullende maatregel” die voldoende is om CLOUD Act-blootstelling te adresseren — en het is de standaard die Europese gegevensbeschermingsautoriteiten nu hanteren bij handhaving.

Het bredere EU-soevereiniteitskader: NIS 2 en DORA

De GDPR is de basis, maar voor de meeste organisaties die zaken doen in de EU is het niet het enige soevereiniteitskader waaraan ze moeten voldoen. Twee aanvullende EU-regelgevingen leggen soevereiniteitsverplichtingen op die bovenop de GDPR komen — en in sommige opzichten verder gaan.

De NIS 2-richtlijn, omgezet door EU-lidstaten in oktober 2024, bestrijkt essentiële sectoren — energie, transport, bankwezen, zorgprocessen, digitale infrastructuur — en belangrijke sectoren zoals producenten en professionele dienstverlening. De soevereiniteitsdimensie is Artikel 21: beveiliging van de toeleveringsketen. Organisaties moeten cyberbeveiligingsrisico’s in hun ICT-toeleveringsketen beoordelen, inclusief de soevereiniteitsstatus van cloudproviders. Een aanbieder met een Amerikaans hoofdkantoor die onder de CLOUD Act valt, is een soevereiniteitsrisico in de toeleveringsketen dat NIS 2 vereist te documenteren en aan te pakken. NIS 2-nalevingsfouten kunnen leiden tot boetes tot €10 miljoen of 2% van de wereldwijde jaaromzet, met directe persoonlijke aansprakelijkheid voor het senior management — aansprakelijkheid die de GDPR niet bij individuen legt.

DORA-nalevingsvereisten, vanaf januari 2025 afdwingbaar voor financiële instellingen in de EU, gaan verder: Artikel 30 vereist expliciet dat contracten met ICT-aanbieders datasoevereiniteit, sleutelbeheer en exitstrategieën adresseren. Voor organisaties in de financiële sector creëren GDPR, DORA en nationale bankgeheimwetten een drievoudige soevereiniteitsverplichting die niet kan worden afgedekt door alleen GDPR-naleving.

Wat echte EU-datasoevereiniteitsnaleving in de praktijk vereist

Door de klant beheerde encryptiesleutels. De EDPB noemt dit de primaire technische aanvullende maatregel voor overdrachten door Amerikaanse aanbieders. Sleutels in de eigen HSM van de klant, buiten de infrastructuur van de aanbieder, zorgen ervoor dat een CLOUD Act-verplichte openbaarmaking alleen ciphertext oplevert. Deze ene architecturale controle voldoet aan GDPR Artikel 32, DORA Artikel 30 sleutelbeheervereisten en de NIS 2-soevereiniteitsbeoordeling van de toeleveringsketen — tegelijkertijd, voor alle drie de kaders.

Single-tenant Europese inzet. Toegewijde infrastructuur in een specifiek EU-datacenter, onder operationele controle van de klant, biedt gedocumenteerde dataresidentie die voldoet aan GDPR Hoofdstuk V en de bewijsstandaard die gegevensbeschermingsautoriteiten hanteren bij Transfer Impact Assessment-beoordelingen. Rechtsbevoegdheid volgt controle, niet coördinaten.

Beleidsmatig afgedwongen geofencing. Geofencing-controles die technisch voorkomen dat data buiten aangewezen geografische regio’s komt — afgedwongen op infrastructuurniveau, niet alleen in beleid — worden door de EDPB geclassificeerd als een “technische aanvullende maatregel” in plaats van een “contractuele aanvullende maatregel”. Alleen de eerste wordt als voldoende beschouwd voor overdrachten met CLOUD Act-blootstelling.

Onveranderlijke audittrails. GDPR Artikel 30, NIS 2-incidentrapportage en DORA ICT-risicodocumentatie vereisen allemaal hetzelfde fundament: manipulatiebestendige registratie van elke data-toegang, overdracht en verwerkingsactiviteit met gedocumenteerde geografische scope. Risicobeheer door derden moet verifiëren dat leveranciers dit bewijs op verzoek kunnen leveren, niet alleen beweren dat ze het bijhouden.

Hoe Kiteworks architecturale soevereiniteit levert voor EU-naleving

Het verschil tussen GDPR-dataresidentievereisten en echte EU-datasoevereiniteit is het verschil tussen waar uw data zich bevindt en wie daadwerkelijk toegang heeft. Een organisatie kan data in Frankfurt opslaan, Standaard Contractuele Clausules ondertekenen en een conforme Transfer Impact Assessment bijhouden — en toch slechts één CLOUD Act-dagvaarding verwijderd zijn van het overhandigen van de data van EU-klanten aan Amerikaanse onderzoekers zonder kennisgeving. Dat is de structurele realiteit van het gebruik van door de VS gecontroleerde infrastructuur voor Europese data, en het is waarop Europese gegevensbeschermingsautoriteiten nu handhaven.

Echte EU-datasoevereiniteit vereist architectuur die dicht wat contracten niet kunnen: door de klant beheerde encryptiesleutels die het voor aanbieders technisch onmogelijk maken om leesbare data te produceren, single-tenant Europese inzet die data onder Europese rechtsbevoegdheid plaatst, en beleidsmatig afgedwongen geofencing die residentie tot een technische realiteit maakt in plaats van een contractuele verklaring. Kiteworks levert die architectuur. Uw data, uw rechtsbevoegdheid, uw controle.

Kiteworks is ontworpen rond één organiserend principe: uw data moet onder uw controle blijven — in uw rechtsbevoegdheid, versleuteld met uw sleutels, ontoegankelijk voor iedereen die u niet heeft geautoriseerd, inclusief Kiteworks zelf. Dat is wat architecturale soevereiniteit in de praktijk betekent.

Het Kiteworks Private Data Network verenigt elk kanaal voor gevoelige contentcommunicatie — e-mail, bestandsoverdracht, MFT, webformulieren en API’s — op één platform, beheerd door uniforme soevereiniteitscontroles. Door de klant beheerde encryptie (BYOK/BYOE) met FIPS 140-3 Level 1 gevalideerde encryptie en AES-256 Encryptie in rust zorgt ervoor dat Kiteworks klantdata niet kan ontsleutelen — niet op basis van een belofte, maar door architectuur. Wij hebben nooit de sleutels. Wanneer een overheidsverzoek bij Kiteworks binnenkomt, levert het alleen ciphertext op. Dat is de door de EDPB vereiste aanvullende maatregel, geleverd op infrastructuurniveau.

Europese inzetopties — on-premises, private cloud met een Europese aanbieder, of door Kiteworks gehoste EU-infrastructuur — waarborgen dataresidentie technisch. Beleidsmatig afgedwongen geofencing houdt content binnen aangewezen regio’s. Zero-trust beveiligingscontroles regelen toegang met elke interactie vastgelegd in een uniforme, onveranderlijke audittrail, zichtbaar via het CISO-dashboard. Vooraf geconfigureerde compliance-rapportages voor GDPR, NIS 2, DORA en ISO 27001 bieden bewijs voor Transfer Impact Assessments, Artikel 30-registraties en sleutelbeheer — soevereiniteit die u kunt aantonen aan een toezichthouder, niet alleen kunt beweren aan een klant.

Wilt u zien hoe Kiteworks datasoevereiniteitsnaleving ondersteunt voor organisaties die in de EU opereren? Plan vandaag nog een demo op maat.

Aanvullende bronnen

• Blog Post
  Datasoevereiniteit: een best practice of wettelijke verplichting?
• eBook 
  Datasoevereiniteit en GDPR
• Blog Post 
  Voorkom deze valkuilen bij datasoevereiniteit
• Blog Post 
  Best practices voor datasoevereiniteit
• Blog Post 
  Datasoevereiniteit en GDPR [Inzicht in gegevensbeveiliging]