Voorkom CLOUD Act-risico’s: Beveilig Europese data architectonisch

Hoe voorkom je toegang van de Amerikaanse overheid tot Europese data: een architecturale aanpak van het CLOUD Act-probleem

Europese organisaties die gevoelige data verwerken via cloudplatforms met een Amerikaans hoofdkantoor, staan voor een structureel complianceprobleem dat noch het contractenrecht noch dataresidentie kan oplossen.

De Clarifying Lawful Overseas Use of Data (CLOUD) Act van 2018 verplicht Amerikaanse bedrijven om data, waar ook ter wereld opgeslagen, te overhandigen aan de Amerikaanse overheid bij een geldig verzoek—ongeacht waar die data zich bevindt of wat afspraken over gegevensbescherming bepalen.

Voor organisaties die onder de GDPR, NIS2 en DORA vallen, ontstaat hierdoor een direct conflict tussen de platforms waarop zij vertrouwen en de wettelijke verplichtingen die zij dragen.

Samenvatting

Belangrijkste punt: De US CLOUD Act creëert een onoplosbaar conflict tussen de wettelijke verplichtingen van Amerikaanse aanbieders en Europese datasoevereiniteitswetgeving. Oplossingen zoals standaard contractuele clausules, inzet van EU-datacenters en andere maatregelen nemen dit risico niet weg, omdat de CLOUD Act kijkt naar de controle van de aanbieder, niet naar de locatie van de data. Encryptiesleutels die door de Europese organisatie zelf worden beheerd—en dus niet door de aanbieder—zijn de enige architecturale maatregel die Amerikaanse overheidsverzoeken technisch onuitvoerbaar maken ten aanzien van de daadwerkelijke datainhoud.

Waarom dit relevant is: GDPR Artikel 48 verbiedt het overdragen van persoonsgegevens aan niet-EU autoriteiten uitsluitend op basis van een buitenlands vonnis of bestuursbesluit. Een organisatie die data verwerkt via een Amerikaans platform dat onder de CLOUD Act-rechtsbevoegdheid valt, kan structureel in overtreding zijn—niet door een specifiek incident, maar door de architectuur zelf. NIS2 en DORA voegen verplichtingen toe voor risicobeheer in de ICT-toeleveringsketen, waardoor dit risico voor kritieke sectoren en de financiële sector toeneemt.

5 Belangrijkste Inzichten

1. De CLOUD Act volgt de controle van de aanbieder, niet de locatie van de data. Data opslaan in een datacenter in Frankfurt of Amsterdam dat wordt beheerd door een Amerikaans bedrijf, plaatst deze data niet onder Duitse of Nederlandse rechtsbevoegdheid. De Amerikaanse wetshandhaving kan de aanbieder verplichten deze te overhandigen, ongeacht de fysieke opslaglocatie.
2. Standaard Contractuele Clausules en Data Processing Agreements kunnen Amerikaanse wettelijke dwang niet opheffen. De CLOUD Act verplicht aanbieders te voldoen aan geldige Amerikaanse overheidsverzoeken, zelfs als dit in strijd is met buitenlandse wetgeving. SCC’s en DPA’s zijn contractuele instrumenten zonder juridische kracht tegenover Amerikaanse rechterlijke of bestuurlijke bevelen aan de aanbieder.
3. Het EU-VS Data Privacy Framework lost het CLOUD Act-risico niet op. Het DPF regelt de regels voor overdracht van persoonsgegevens voor gecertificeerde Amerikaanse bedrijven, maar voorkomt niet dat Amerikaanse autoriteiten CLOUD Act-verzoeken indienen. FISA Section 702, in april 2024 met een uitgebreidere reikwijdte verlengd, blijft een afzonderlijke en onopgeloste zorg onder de Europese privacywetgeving.
4. Transfer Impact Assessments die eerlijk worden uitgevoerd, zullen CLOUD Act-risico als onbeheerst identificeren zonder technische maatregelen. De Schrems II-aanbevelingen van de EDPB noemen expliciet encryptiesleutels onder controle van de klant, bewaard binnen de EER, als de belangrijkste technische aanvullende maatregel tegen Amerikaanse surveillancerechtgeving.
5. Door de klant beheerde encryptie maakt CLOUD Act-verzoeken technisch onuitvoerbaar op de datainhoud. Wanneer de Europese organisatie—en niet de Amerikaanse aanbieder—de encryptiesleutels beheert in een HSM-integratie onder controle van de eigen rechtsbevoegdheid, kan de aanbieder geen leesbare data leveren, zelfs niet onder wettelijke dwang. De architectuur lost op wat contracten niet kunnen.

Waarom de CLOUD Act een structureel probleem vormt voor Europese organisaties

Het cruciale verschil is tussen de locatie van data en de controle over data. De meeste Europese organisaties die zijn overgestapt op Amerikaanse cloudplatforms, deden dat met het idee “onze data staat in de EU” als geruststelling. Die geruststelling is grotendeels ongegrond.

Hoe de CLOUD Act werkt en waarom EU-datacenters geen bescherming bieden

De CLOUD Act verplicht Amerikaanse bedrijven om elektronische communicatie en gegevens in hun bezit, bewaring of controle te bewaren, back-uppen en te verstrekken bij een geldig juridisch verzoek—ongeacht de opslaglocatie. Het doorslaggevende criterium is controle, niet geografie. Een Amerikaanse cloudprovider die een datacenter in Frankfurt exploiteert, blijft een Amerikaans bedrijf met controle over de data die daar is opgeslagen. Wanneer het Amerikaanse ministerie van Justitie of de FBI een verzoek indient, is de locatie Frankfurt juridisch niet relevant.

Het probleem wordt versterkt doordat CLOUD Act-verzoeken vaak voorzien zijn van geheimhoudingsbevelen—de Amerikaanse aanbieder mag de Europese klant wiens data wordt ingezien, wettelijk niet informeren. Een organisatie kan dus structureel in overtreding zijn van GDPR Artikel 48, dat het overdragen van persoonsgegevens aan niet-EU autoriteiten zonder internationale overeenkomst verbiedt, zonder ooit te weten dat er een verzoek is geweest. De CLOUD Act is niet zo’n overeenkomst.

Waarom contractuele bescherming het gat niet dicht

De CLOUD Act bepaalt expliciet dat Amerikaanse aanbieders moeten voldoen aan geldige verzoeken, zelfs als dit in strijd is met buitenlandse wetgeving. Een contractuele toezegging van de aanbieder om een verzoek aan te vechten of de klant te informeren, is ondergeschikt aan de Amerikaanse wettelijke verplichtingen. Dit is geen theoretisch punt. Het Schrems II-arrest van het HvJEU verklaarde het EU-VS Privacy Shield ongeldig op precies deze grond—dat de Amerikaanse wet autoriteiten toegang gaf tot EU-persoonsgegevens op een manier die onverenigbaar is met de GDPR, en EU-burgers onvoldoende rechtsbescherming bood. Het Hof bevestigde dat standaard contractuele clausules niet kunnen worden vertrouwd wanneer de Amerikaanse wet hun effectiviteit ondermijnt, en dat aanvullende technische maatregelen vereist zijn.

Hoe het overdrachtskader van de GDPR samenkomt met CLOUD Act-risico

GDPR Hoofdstuk V—Artikelen 44-49—regelt internationale overdrachten van persoonsgegevens. Voor Europese organisaties die Amerikaanse platforms gebruiken, is inzicht in dit kader geen keuze. Of het gebruik van een Amerikaanse cloudprovider een voortdurende internationale overdracht vormt, en op welke juridische grondslag, heeft directe gevolgen voor de naleving van de GDPR.

Artikelen 44-49, Schrems II en wat Transfer Impact Assessments moeten behandelen

Organisaties die vertrouwen op Artikel 46 SCC’s moeten, na Schrems II, Transfer Impact Assessments uitvoeren om te beoordelen of de Amerikaanse wetgeving de effectiviteit van SCC’s voor hun specifieke overdrachten aantast. De EDPB-aanbevelingen 01/2020 beschrijven dit proces in detail. Cruciaal is dat de EDPB sterke encryptie vóór datatransmissie identificeerde—waarbij de decryptiesleutels uitsluitend onder EER-controle blijven—als de technische aanvullende maatregel die het risico van Amerikaanse surveillancerechtgeving kan adresseren. Standaard cloudencryptie, waarbij de aanbieder de sleutels beheert als onderdeel van de dienst, voldoet hier niet aan: de aanbieder behoudt technische toegang tot de platte tekst en blijft onderhevig aan CLOUD Act-verzoeken daarvoor.

Waarom het EU-VS Data Privacy Framework het probleem niet oplost

Het DPF, aangenomen door de Europese Commissie in juli 2023, stelt gecertificeerde Amerikaanse bedrijven in staat EU-persoonsgegevens te ontvangen zonder aparte SCC’s. Het voorkomt niet dat Amerikaanse autoriteiten CLOUD Act- of FISA Section 702-verzoeken indienen bij gecertificeerde bedrijven. FISA Section 702 werd in april 2024 met een bredere reikwijdte verlengd. Het Europees Parlement waarschuwde in mei 2023 dat het DPF “geen essentiële gelijkwaardigheid creëert.” Het EDPB’s reviewrapport van november 2024 riep op tot herbeoordeling binnen drie jaar. Begin 2025 verwijderde de Trump-regering drie van de vijf leden van de US Privacy and Civil Liberties Oversight Board—het orgaan dat toezicht houdt op de DPF-inlichtingenverplichtingen—waardoor het zonder quorum kwam te zitten. De twee voorgangers van het DPF, Safe Harbour en Privacy Shield, werden beide ongeldig verklaard door het HvJEU. Organisaties die DPF-certificering als hun belangrijkste CLOUD Act-mitigatie zien, bouwen op aantoonbaar wankele fundamenten.

NIS2 en DORA vergroten het risico

De GDPR is niet het enige kader dat verplichtingen creëert die relevant zijn voor CLOUD Act-risico. Voor organisaties in kritieke infrastructuur en de financiële sector voegen NIS2 en DORA specifieke vereisten toe voor risicobeheer van derde partijen, waarbij afhankelijkheid van Amerikaanse aanbieders direct in het vizier komt.

NIS2-beveiliging van de toeleveringsketen en DORA ICT-derdepartijrisico

NIS2, van kracht vanaf oktober 2024, verplicht essentiële en belangrijke entiteiten om de beveiliging van de ICT-toeleveringsketen te beoordelen—including de blootstelling van hun aanbieders aan toegangseisen van niet-EU-overheden onder Artikel 21. Een organisatie die niet heeft geëvalueerd of de CLOUD Act-blootstelling van haar Amerikaanse cloudprovider een risico in de toeleveringsketen vormt, is mogelijk niet compliant met de NIS2-verplichtingen voor risicobeheer, ongeacht of er daadwerkelijk een verzoek is geweest. Boetes kunnen oplopen tot €10 miljoen of 2% van de wereldwijde jaaromzet voor essentiële entiteiten.

DORA, van toepassing vanaf januari 2025, verplicht financiële entiteiten om concentratierisico’s door afhankelijkheid van ICT-aanbieders te beoordelen, vertrouwelijkheidsverplichtingen te evalueren en gedocumenteerde exitstrategieën te onderhouden voor kritieke ICT-relaties. De CLOUD Act creëert een specifiek concentratierisico dat DORA vereist te evalueren en adresseren. De ECB’s gids van juli 2025 over uitbesteding van clouddiensten onderstreept dit, met nadruk op risicogebaseerde beoordeling van de juridische blootstelling van cloudproviders voor door de ECB gecontroleerde banken.

De architecturale oplossing: door de klant beheerde encryptie

De EDPB-richtlijn definieert de vereiste nauwkeurig: de Amerikaanse aanbieder mag nooit toegang hebben tot de onversleutelde data of de encryptiesleutels. Dit is een architecturale vereiste, geen contractuele. Voldoen hieraan vereist platforms waarbij datasoevereiniteit in de encryptielaag zelf is ingebouwd—met sleutels onder controle van de Europese klant, opgeslagen in HSM’s binnen de eigen rechtsbevoegdheid van de klant.

Hoe door de klant beheerde encryptie CLOUD Act-risico adresseert

Door de klant beheerde encryptie werkt volgens een eenvoudig principe: data wordt versleuteld voordat deze de infrastructuur van de Amerikaanse aanbieder bereikt, met sleutels die de klant zelf genereert en onafhankelijk opslaat. Wanneer een Amerikaanse autoriteit een CLOUD Act-verzoek indient, kan de aanbieder de versleutelde data overhandigen—maar niet de leesbare inhoud, omdat deze de sleutels niet bezit. Het verzoek is technisch onuitvoerbaar op de daadwerkelijke informatie. Voor GDPR-doeleinden voldoet deze architectuur direct aan de aanvullende maatregel van de EDPB. De data-exporteur—de Europese organisatie—behoudt exclusieve controle over de decryptiesleutels binnen de EER. De data-importeur—de Amerikaanse aanbieder—verwerkt alleen ciphertext. Dit is de specifieke configuratie die de EDPB heeft aangewezen als oplossing voor Amerikaanse surveillancerechtgeving.

Rechtsbevoegdheid-specifieke sleuteluitrol voor multinationale organisaties

Voor organisaties die actief zijn in Duitsland, Frankrijk, Nederland en het VK ondersteunt door de klant beheerde encryptie een rechtsbevoegdheid-specifieke sleuteluitrol. Duitse organisaties plaatsen HSM’s in Duitsland, waarmee wordt voldaan aan de GDPR en de strafrechtelijke geheimhoudingsplicht uit §203 StGB. Franse organisaties beheren sleutels in Frankrijk en behouden het beroepsgeheim onder de Code de la Santé Publique. Nederlandse organisaties houden sleutels in Nederland, waarmee wordt voldaan aan de handhavingsverwachtingen van de AP. Britse organisaties plaatsen sleutels in het VK, conform de ICO-richtlijnen voor aanvullende overdrachtsmaatregelen. Deze architectuur vereist niet dat Amerikaanse cloudplatforms worden verlaten—wel dat de encryptielaag onder Europese controle valt voordat data de Amerikaanse infrastructuur bereikt.

Het documentatiepakket voor toezichthouders opbouwen

De juiste architectuur inzetten is noodzakelijk, maar niet voldoende. Gegevensbeschermingsautoriteiten, NIS2-toezichthouders en DORA-bevoegde autoriteiten verwachten gedocumenteerd bewijs. Voor organisaties die CLOUD Act-risico hebben geadresseerd met door de klant beheerde encryptie, volgt de documentatie een duidelijke structuur.

Bewijs voor Transfer Impact Assessments en voortdurende compliance

Een Schrems II-conforme Transfer Impact Assessment voor relaties met Amerikaanse aanbieders moet het volgende documenteren: de relevante Amerikaanse wetten (CLOUD Act, FISA 702); een beoordeling van hoe deze de effectiviteit van SCC’s aantasten; de genomen technische aanvullende maatregelen; de onderbouwing dat deze maatregelen een wezenlijk gelijkwaardig beschermingsniveau bieden; en een monitoringverplichting voor wijzigingen in het DPF-besluit. Ondersteunend bewijs omvat architectuurdiagrammen, procedures voor sleutelbeheer, HSM-uitrolrapportages en audit logs die aantonen dat toegangscontroles operationeel zijn. Voor NIS2 en DORA voeg je risicobeoordelingen van de toeleveringsketen toe over CLOUD Act-blootstelling van de aanbieder, evaluaties van concentratierisico, exitstrategieën en RBAC-matrices die tonen wie wat kan ontsleutelen.

Hoe Kiteworks Europese organisaties in staat stelt CLOUD Act-risico architecturaal te adresseren

Het CLOUD Act-probleem is reëel, structureel en kan niet contractueel worden uitgesloten. Europese organisaties die gevoelige data verwerken via Amerikaanse platforms zonder door de klant beheerde encryptiesleutels, hebben een compliance-gat dat eerlijke Transfer Impact Assessments zullen blootleggen, waar GDPR-toezichthouders steeds vaker tegen optreden en dat NIS2- en DORA-kaders voor derde partijen vereisen te adresseren. De architecturale oplossing die de EDPB heeft goedgekeurd, is vandaag beschikbaar. Het vereist dat de encryptielaag zich bevindt waar deze hoort: onder Europese controle, voordat data de Amerikaanse infrastructuur bereikt.

Kiteworks biedt Europese organisaties een Private Data Network dat CLOUD Act-risico direct adresseert via door de klant beheerde encryptie. Encryptiesleutels blijven onder exclusieve controle van de Europese klant, opgeslagen in HSM’s binnen de rechtsbevoegdheid van de klant. Wanneer Kiteworks data verwerkt, verwerkt het alleen ciphertext—waardoor platte tekst technisch ontoegankelijk is voor Amerikaanse overheidsverzoeken aan Kiteworks.

Het platform ondersteunt rechtsbevoegdheid-specifieke inzet—Duitse organisaties beheren sleutels in Duitsland, Franse organisaties in Frankrijk, Nederlandse organisaties in Nederland, Britse organisaties binnen het VK—en voldoet daarmee aan de aanvullende Schrems II-maatregelen van de EDPB en levert het gedocumenteerde bewijs dat Transfer Impact Assessments vereisen. Kiteworks integreert Kiteworks secure email, Kiteworks secure file sharing, secure MFT en Kiteworks secure data forms binnen één architectuur—waardoor door de klant beheerde encryptie consequent geldt voor alle data-uitwisselingskanalen.

Meer weten over hoe Kiteworks Europese organisaties ondersteunt bij het adresseren van CLOUD Act-risico? Plan vandaag nog een demo op maat.

Aanvullende bronnen 

• Blog Post  
  Data Sovereignty: een best practice of wettelijke vereiste?
• eBook  
  Data Sovereignty en GDPR
• Blog Post  
  Voorkom deze valkuilen bij Data Sovereignty
• Blog Post  
  Data Sovereignty beste practices
• Blog Post  
  Data Sovereignty en GDPR [Inzicht in gegevensbeveiliging]