Hoe te reageren op een onderzoek van de gegevensbeschermingsautoriteit naar uw afspraken met uw Amerikaanse cloudprovider

Een brief van uw nationale toezichthouder voor gegevensbescherming is geen routinematige nalevingsoefening. Wanneer een Autoriteit Persoonsgegevens vraagt naar uw afspraken met een Amerikaanse cloudprovider, stelt zij een gerichte vraag: hoe heeft u ervoor gezorgd dat gegevens die u via Amerikaanse platforms verwerkt, beschermd zijn tegen toegang door de Amerikaanse overheid?

Het onderzoek kan worden gestart door een klacht van een betrokkene, een nationaal auditprogramma of handhavingstrends na Schrems II. Wat de aanleiding ook is, het antwoord vereist altijd hetzelfde: een duidelijke, gedocumenteerde en technisch verifieerbare uitleg van hoe uw organisatie een risico heeft aangepakt dat niet alleen met contracten kan worden opgelost.

In deze post nemen we u mee in een vierstappenplan voor DPO’s en juridische en compliance-teams die zo’n verzoek hebben ontvangen: Beoordelen, Documenteren, Herstellen en Communiceren.

Executive Summary

Belangrijkste idee: Een onderzoek van de Autoriteit Persoonsgegevens naar afspraken met Amerikaanse cloudproviders is een directe toets van uw GDPR Hoofdstuk V-naleving — specifiek of uw Transfer Impact Assessments eerlijk zijn, uw aanvullende maatregelen technisch effectief zijn en uw documentatie over datasoevereiniteit standhoudt bij controle. Door de klant beheerde encryptiesleutels — in handen van de Europese organisatie, niet de provider — is de architecturale maatregel die de EDPB heeft aanbevolen als oplossing voor blootstelling aan Amerikaanse surveillanceregels.

Waarom dit belangrijk is: Onder GDPR Artikel 58 hebben toezichthouders brede onderzoeks- en corrigerende bevoegdheden — inclusief het opleggen van een tijdelijk of permanent verwerkingsverbod, het opschorten van datastromen en het opleggen van boetes tot €20 miljoen of 4% van de wereldwijde jaaromzet. De totale GDPR-boetes sinds 2018 zijn opgelopen tot meer dan €5,88 miljard. Slechte samenwerking met een toezichthouder kan op zichzelf al een overtreding zijn. Hoe u reageert — de kwaliteit van uw documentatie, de geloofwaardigheid van uw aanvullende maatregelen en uw bereidheid tot herstel — beïnvloedt het resultaat aanzienlijk.

5 Belangrijkste Leerpunten

1. Begrijp wat de toezichthouder daadwerkelijk vraagt voordat u reageert. De meeste verzoeken komen neer op één vraag: heeft uw provider technisch toegang tot de platte tekst van de gegevens die u via hem verwerkt? Alles daarbuiten — uw SCC’s, TIA’s, DPF-afhankelijkheid — is context voor dat antwoord.
2. Locatie van het EU-datacenter is geen verdediging. De CLOUD Act volgt het beheer van de provider, niet de locatie van de gegevens. Een Amerikaans bedrijf dat EU-infrastructuur exploiteert, behoudt het bezit en de controle over de daar opgeslagen gegevens. Toezichthouders in Europa kennen dit onderscheid en verwachten dat u dit direct adresseert in uw antwoord.
3. Het EU-VS Data Privacy Framework lost de CLOUD Act-blootstelling niet op. Het DPF regelt de overdrachtsregels voor gecertificeerde Amerikaanse bedrijven. Het voorkomt geen CLOUD Act- of FISA Section 702-verzoeken. Als DPF-afhankelijkheid uw belangrijkste maatregel is, moet u uitleggen waarom — en die uitleg is moeilijk geloofwaardig te maken.
4. Onvoldoende Transfer Impact Assessments zijn een verzwarende factor. Een TIA die CLOUD Act-risico identificeert en concludeert dat dit alleen door contractuele maatregelen wordt beperkt, kan erop wijzen dat het nalevingsproces niet te goeder trouw is uitgevoerd — niet alleen dat de uitkomst onjuist was.
5. Herstelmaatregelen nemen voordat u reageert, versterkt uw positie aanzienlijk. Een onderzoek van de toezichthouder met een herstelplan dat al in gang is gezet — ondersteund door bewijs dat klantbeheerde encryptie wordt ingezet — is een fundamenteel ander gesprek dan wanneer de organisatie nog steeds vertrouwt op dezelfde architectuur die ter discussie staat.

De Handhavingscontext: Waarom toezichthouders deze vraag stellen

Vragen van toezichthouders over afspraken met Amerikaanse cloudproviders zijn niet uit het niets ontstaan. Ze zijn het gevolg van een reeks juridische en politieke ontwikkelingen die begonnen met de Schrems II-uitspraak van het HvJ-EU in juli 2020 en sindsdien zijn geïntensiveerd. Dit begrijpen helpt DPO’s om hun antwoorden goed te formuleren en te voorkomen dat het verzoek als een op zichzelf staande administratieve gebeurtenis wordt gezien.

De Juridische Achtergrond: Schrems II, de CLOUD Act en de kwetsbaarheid van het DPF

Schrems II maakte het EU-VS Privacy Shield ongeldig en bevestigde dat standaard contractuele clausules aanvullende maatregelen vereisen wanneer Amerikaanse wetgeving hun effectiviteit ondermijnt. De EDPB-aanbevelingen 01/2020 identificeerden klantbeheerde encryptie — waarbij de Amerikaanse provider nooit toegang heeft tot de onversleutelde gegevens of sleutels — als de belangrijkste technische aanvullende maatregel om blootstelling aan Amerikaanse surveillanceregels te adresseren. Organisaties die na Schrems II TIA’s hebben afgerond zonder deze conclusie te trekken, moeten beoordelen of die beoordelingen adequaat waren.

De Amerikaanse CLOUD Act van 2018 versterkt dit probleem. Deze verplicht Amerikaanse bedrijven om gegevens die overal ter wereld zijn opgeslagen te overhandigen bij een geldig verzoek van de Amerikaanse overheid, ongeacht de opslaglocatie. GDPR Artikel 48 verbiedt overdracht van persoonsgegevens aan niet-EU-autoriteiten uitsluitend op basis van een buitenlands gerechtelijk of administratief bevel — en de CLOUD Act is geen internationale overeenkomst in de zin van die bepaling. Het conflict tussen beide kaders is structureel.

Het EU-VS Data Privacy Framework, aangenomen in juli 2023, lost de CLOUD Act-blootstelling niet op. Het regelt de overdrachtsregels voor gecertificeerde bedrijven — het voorkomt geen verzoeken van de Amerikaanse overheid. FISA Section 702 werd in april 2024 opnieuw goedgekeurd met een uitgebreidere reikwijdte. Begin 2025 verwijderde de regering-Trump drie van de vijf leden van de US Privacy and Civil Liberties Oversight Board — het orgaan dat toezicht houdt op de DPF-inlichtingenverplichtingen — waardoor er geen quorum meer was. De voorgangers van het DPF, Safe Harbour en Privacy Shield, zijn beide ongeldig verklaard door het HvJ-EU. Alleen DPF-certificering is geen adequate maatregel.

Waarom de handhaving toeneemt

Handhaving door toezichthouders heeft sinds 2018 verschillende fasen doorlopen. De beginperiode werd gekenmerkt door richtlijnen en oriëntatie. Sinds 2022 is de handhaving sterk toegenomen — waaronder de eerste GDPR-boete van een miljard euro, opgelegd aan Meta in 2023 voor onrechtmatige overdracht van gegevens naar de VS. De DLA Piper GDPR Fines Survey van 2024 registreerde €1,2 miljard aan boetes in Europa in dat jaar, waarbij de handhaving zich uitbreidde naar de financiële sector en energie. De totale GDPR-boetes sinds 2018 bedragen nu meer dan €5,88 miljard. Handhaving is niet langer beperkt tot grote organisaties of bekende namen. Toezichthouders onderzoeken steeds vaker middelgrote en sectorspecifieke organisaties, waarbij het EDPB’s Coordinated Enforcement Framework wordt gebruikt om nationale prioriteiten op elkaar af te stemmen. Afspraken over overdracht naar de VS zijn in elke grote Europese rechtsbevoegdheid een vast handhavingspunt.

Fase 1 — Beoordelen: Begrijp wat de toezichthouder daadwerkelijk vraagt

De eerste stap bij een verzoek is niet direct een antwoord opstellen. Het is begrijpen wat de aanleiding was, wat de autoriteit vraagt en hoe uw huidige architectuur er daadwerkelijk uitziet. Te snel reageren kan leiden tot een onvolledig antwoord dat meer problemen veroorzaakt dan het oplost.

Identificeer het type verzoek en de implicaties ervan

Vragen van toezichthouders over Amerikaanse cloudafspraken vallen in drie categorieën: klachtgestuurd (een betrokkene of concurrent heeft een klacht ingediend); auditgestuurd (een nationale of EDPB-gecoördineerde audit van het gebruik van Amerikaanse cloud in uw sector); of intelligencegestuurd (de toezichthouder heeft potentiële overtredingen geïdentificeerd via eigen monitoring). De categorie bepaalt wat de autoriteit al weet en hoeveel ruimte u heeft om uw antwoord te formuleren.

Breng uw daadwerkelijke technische blootstelling in kaart

Voer een eerlijke interne beoordeling uit voordat u ook maar één woord van uw antwoord schrijft. De centrale vraag is eenvoudig: heeft uw Amerikaanse cloudprovider technisch toegang tot de platte tekst van de gegevens die u via hem verwerkt? Beheert hij encryptiesleutels als onderdeel van zijn dienst? Als het antwoord op een van beide ja is, heeft u een daadwerkelijk risico — geen theoretisch — en moet uw antwoord daar rekening mee houden. Leg uw bevindingen naast uw Artikel 30-registers, uw bestaande TIA’s en uw overdrachtsmechanismen en identificeer elke relatie met een Amerikaanse provider die binnen de scope valt.

Fase 2 — Documenteren: Stel het bewijspakket samen

Toezichthouders verwachten documentair bewijs, geen beweringen. Onder GDPR Artikel 58 hebben zij het recht om toegang te eisen tot alle informatie die nodig is voor hun taken. GDPR Artikel 5(2) legt de verantwoordingsplicht volledig bij de verwerkingsverantwoordelijke — u moet naleving aantonen, niet alleen beweren.

Wat uw bewijspakket moet bevatten

De kernstukken zijn uw Transfer Impact Assessments voor elke Amerikaanse providerrelatie binnen de scope. Elke TIA moet aantonen dat u de relevante Amerikaanse wetten (CLOUD Act, FISA 702) heeft geïdentificeerd, heeft beoordeeld hoe deze de effectiviteit van uw SCC’s beïnvloeden, de aanvullende technische maatregelen heeft vastgesteld en heeft onderbouwd waarom deze maatregelen een wezenlijk gelijkwaardig beschermingsniveau bieden. TIA’s die zijn afgerond voordat u klantbeheerde encryptie heeft ingezet, moeten vóór indiening worden bijgewerkt — die update is op zichzelf bewijs van uw verantwoordingsplicht.

Ondersteunend technisch bewijs omvat architectuurdiagrammen die laten zien waar encryptie wordt toegepast en waar sleutels worden bewaard, procedures voor sleutelbeheer die aantonen dat sleutels onder EER-controle blijven, HSM-inzetrecords en audit logs die aantonen dat toegangscontroles operationeel zijn. Artikel 30-registers, gegevensverwerkingsovereenkomsten met uw Amerikaanse providers en eventuele DPIA-registraties voor risicovolle verwerkingen maken het pakket compleet.

Eén aspect dat DPO’s vaak onderschatten: u moet aantonen dat u niet alleen de sleutels beheert, maar dat uw provider operationeel geen toegang heeft tot platte tekst gegevens — niet voor support, niet voor diagnose, niet via een andere dienstweg. Als de architectuur van de provider dit niet ondersteunt, pak dit dan aan in de herstelstap voordat u uw antwoord indient.

Fase 3 — Herstellen: Pak tekortkomingen aan voordat u reageert

Als uit de beoordeling blijkt dat uw Amerikaanse provider technisch toegang heeft tot platte tekst gegevens of encryptiesleutels namens u beheert, is de vraag of u het kunt herstellen voordat u reageert of dat u de tekortkoming moet melden met een geloofwaardige planning. In beide gevallen is het nemen van herstelmaatregelen vóór uw reactie aanzienlijk beter dan het uitleggen van een tekortkoming zonder plan.

Klantbeheerde encryptie inzetten als herstelmaatregel

De herstelmaatregel die in de EDPB-richtlijnen wordt genoemd, is klantbeheerde encryptie: gegevens worden versleuteld voordat ze de infrastructuur van de Amerikaanse provider bereiken, met sleutels die de klant zelf genereert en onafhankelijk bewaart in hardware security modules binnen EER-rechtsbevoegdheid. Wanneer de Amerikaanse provider alleen ciphertext verwerkt en nooit sleutels in handen heeft, bereikt een CLOUD Act-verzoek de provider maar kan het geen leesbare gegevens opleveren. De architectuur lost op wat contracten niet kunnen.

Voor organisaties in Duitsland, Frankrijk, Nederland en het VK ondersteunt klantbeheerde encryptie rechtsbevoegdheidsspecifieke sleuteluitrol zonder dat aparte infrastructuur voor elke providerrelatie nodig is. Dit vereist geen migratie van Amerikaanse platforms — het vereist dat de encryptielaag onder uw controle valt voordat gegevens de Amerikaanse infrastructuur bereiken. Platforms die beveiligde e-mail, beveiligde bestandsoverdracht, beveiligde MFT en beveiligde webformulieren integreren binnen één encryptiemodel stellen organisaties in staat bestaande cloudinvesteringen te behouden en toch het CLOUD Act-gat te dichten waar de toezichthouder naar vraagt. Documenteer herstelmaatregelen in real time — een plan met mijlpalen en een verantwoordelijke persoon toont de verantwoordingshouding die toezichthouders positief waarderen.

Fase 4 — Communiceren: Hoe u reageert naar de autoriteit

Met uw risico in kaart gebracht, bewijs verzameld en herstelmaatregelen afgerond of in gang gezet, bent u klaar om te reageren. Hoe u communiceert — de toon, volledigheid en transparantie — heeft grote invloed op het resultaat.

Principes voor een effectieve reactie op de toezichthouder

Reageer binnen de gestelde termijn. Niet meewerken met een toezichthouder is op zichzelf al een overtreding onder GDPR Artikel 83. Als de termijn echt te kort is, neem dan tijdig contact op met de autoriteit om uitstel te vragen en leg uit waarom.

Wees direct over tekortkomingen. Toezichthouders hebben genoeg ontwijkende antwoorden gezien om deze te herkennen. Als uw eerdere TIA’s vertrouwden op contractuele maatregelen die onvoldoende waren, of als uw provider encryptiesleutels beheerde, erken dit dan direct samen met de genomen herstelmaatregelen. De EDPB en nationale toezichthouders beschouwen samenwerking en aantoonbare inzet voor herstel consequent als verzachtende factoren bij handhavingsbesluiten.

Begin met de technische architectuur. Het meest overtuigende bewijs is geen juridisch betoog — het is een heldere demonstratie dat uw Amerikaanse provider geen toegang heeft tot platte tekst gegevens. Architectuurdiagrammen, HSM-inzetrecords en RBAC-matrices vormen de kern van een overtuigend antwoord. Juridische duiding plaatst het technische bewijs in context; het vervangt het niet. Zorg dat uw DPO het antwoord goedkeurt onder GDPR Artikel 39, en als de DPO onvoldoende betrokken was bij het oorspronkelijke TIA-proces, geef dat aan als onderdeel van uw verantwoordingsverhaal.

Hoe Kiteworks Europese organisaties ondersteunt bij verzoeken van toezichthouders

Een verzoek van de toezichthouder over uw afspraken met Amerikaanse cloudproviders is evenzeer een kans als een risico. Organisaties die reageren met eerlijkheid, technisch bewijs en een geloofwaardige herstelhouding staan er fundamenteel anders voor dan organisaties die documentatie indienen die is gebaseerd op contractuele beweringen die geen stand houden bij controle. Goed reageren begint met eerlijk beoordelen — en zorgen dat uw architectuur past bij het antwoord dat u geeft.

Kiteworks biedt de technische architectuur die een reactie op een toezichthouder geloofwaardig maakt. Het Private Data Network gebruikt klantbeheerde encryptie — sleutels in handen van de Europese organisatie in rechtsbevoegdheid-gecontroleerde HSM’s, nooit toegankelijk voor Kiteworks of voor verzoeken van de Amerikaanse overheid. Wanneer een toezichthouder vraagt of uw Amerikaanse provider technisch toegang heeft tot uw platte tekst gegevens, is het antwoord nee — en de architectuurdocumentatie om dit te bewijzen is direct beschikbaar.

Kiteworks ondersteunt rechtsbevoegdheidsspecifieke sleuteluitrol in Duitsland, Frankrijk, Nederland, het VK en andere Europese rechtsbevoegdheden, waarmee wordt voldaan aan de Schrems II-aanvullende maatregelvereisten van de EDPB. Uitgebreide audit logs, toegangscontroles en gegevensbeheer-documentatie ondersteunen het bewijspakket dat toezichthouders eisen.

Wilt u meer weten over datasoevereiniteit en reageren op verzoeken van toezichthouders over afspraken met Amerikaanse cloudproviders? Plan een persoonlijke demo.

Aanvullende bronnen 

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