over mij

Gegevens in de cloud volgens de privacyregels: (hoe) kan dat nog wel?

7 January 2022 | 12 minuten lezen | Deel dit blog viaFacebook,LinkedIn,Twitter,WhatsApp
In de afgelopen twee corona-jaren zijn veel bedrijven noodgedwongen digitaler gaan werken. In de praktijk gaat dit om veelgebruikte (samenwerkings)diensten, zoals die van Atlassian, Miro, Microsoft 365, Akamai, Cloudflare, Google Ads en Facebook. Deze diensten hebben een eigen (private) cloud of maken gebruik van de public clouds van AWS, Google, Azure, Digital Ocean... enz. enz. Een kreet als the cloud is everywheredekt wat dat betreft nog het best de lading: je ontkomt bijna niet aan de cloud. In dit blog leg ik je uit waar je in de cloud privacy-wise rekening mee moet houden.
cloud doorgifte  - franksblog.nl
Foto van Alina Grubnyak (Unsplash)
TLDR; de aanleiding voor dit blog is een recente uitspraak van een Duitse rechter. Uit deze uitspraak volgt waarom je bij clouddiensten altijd alle (sub)verwerkers, de infrastructuur en het (eventuele) doorgifte-mechanisme juridisch goed moet toetsen en vastleggen.[Update 14/1/2022: Het belang van wat ik in dit blog een 'DIA' (ook wel DTIA, TIA of DPTIA) noem is erg actueel. In een uitspraak van de Oostenrijkse toezichthouder wordt bijvoorbeeld vastgesteld dat er voor GA niet sprake kan zijn van rechtmatige doorgifte naar de VS. ]

Essentie AVG: rechtmatige doorgifte in vier stappen

Bij gebruik van clouddiensten zijn de regels (hoofdstuk 5 AVG) over doorgifte van persoonsgegevens naar derde landen het meest belangrijk. Een derde land is elk land buiten de EER (Europese Unie landen + Liechtenstein, Noorwegen en IJsland). Dit is sinds de uitspraken Schrems I en Schrems II van het Europese hof voor de meeste lezers vast geen onbekende kost. Het gaat dus om de juiste invulling van de rechtsregels uit de Schrems uitspraken. De EDPB en EDPS
Even kort over deze afkortingen:
  • EDPB staat voor de European Data Protection Board. De EDPB bestaat uit alle nationale toezichthouders en brengt onder meer adviezen en opinies over de AVG uit.
  • EDPS: staat voor de European Data Protection Supervisor. De EDPS is de 'privacy toezichthouder' voor de EU-instellingen en -organen. Je kan het ook wel de Europese evenknie van de Autoriteit Persoonsgegevens in Nederland noemen.
hebben de regels gelukkig vertaald in guidance. Er is volgens de EDPB sprake van doorgifte wanneer...
  1. ...de AVG van toepassing is op de verantwoordelijke of verwerker die gegevens doorgeeft naar een land buiten de EER. Deze partij wordt ook wel de "data-exporteur" genoemd. De AVG moet is al snel van toepassing op de data-exporteur. Dit betekent dat deze partij er in ieder geval persoonsgegevens verwerkt. Verder hoeft de data-exporteur niet in de EER te zijn gevestigd. Ik wil hier niet te lang bij stilstaan, maar de AVG geldt ook voor elk bedrijf in de VS die in de EU producten of diensten verkoopt (en daarbij persoonsgegevens verwerkt).
  2. ...de data-exporteur persoonsgegevens aan een data-importeur (via transmissie) 'beschikbaar stelt'. De data-importeur is altijd een andere verantwoordelijk of verwerker. Dus niet een medewerker van een Nederlands bedrijf dat in in India zijn of haar werkzaamheden tijdelijk uitvoert. Er is in ieder geval sprake van ‘doorgifte van persoonsgegevens’ bij: (i) remote-support / toegang op afstand door een verwerker in bijvoorbeeld India; en (ii) de opslag van gegevens door een derde partij in bijvoorbeeld de VS.
  3. ...de data-importeur is een land buiten de EER gevestigd.
Er is pas sprake van 'doorgifte van persoonsgegevens' als de activiteit aan alle drie de voorwaarden voldoet.De EDPB heeft verder ook een 6-stappenplan opgesteld, waarmee organisaties eigen activiteiten kunnen en moeten beoordelen. Op mijn beurt vertaal ik dit naar een aantal stappen die je in het kader van de cloud altijd moet doen:
  1. Breng de keten van alle (sub)verwerker(s) en landen in kaart
  2. Bepaal het doorgifte-mechanisme
  3. Doe eventueel een doorgifte impact assessment (DIA)
  4. Leg de afwegingen/conclusies die volgen uit stap 1-3 altijd schriftelijk vast (en evalueer deze periodiek)

Stap 1: Breng alle (sub)verwerker(s) en landen in kaart

Het in kaart brengen van de infrastructuur, leveranciers, partners en alle andere derden In praktijk zijn dit verwerkers, subverwerkers, verantwoordelijken en derden. Dit is dus de gehele keten die betrokken is bij de (verwerkings)activiteit. is wat mij betreft altijd het startpunt. Waarom? Alleen dan weet je of er (mogelijk) sprake is van doorgifte. Laten we Google Analytics (GA) als voorbeeld nemen:
  • Als Nederlandse onderneming sluit je een overeenkomst met Google Ierland.
  • De verwerkersovereenkomst (‘Google Ads Data Processing Terms’) maakt (na acceptatie in het account) onderdeel uit van de overeenkomst. In de verwerkersovereenkomst staan alle afspraken over de rol van Google als verwerker.
  • Google verwerkt voor GA de volgende (op z'n hoogst indirect herleidbare) persoonsgegevens: ‘Online identifiers, including cookie identifiers, internet protocol addresses and device identifiers; client identifiers’.
  • De gegevens kunnen in de wereldwijde Google cloud worden opgeslagen. De datacenters bevinden zich in 4 landen buiten de EER (Chili, Singapore, Taiwan en VS).
  • Google maakt gebruik van subverwerkers voor onder meer ‘customer support’ en ‘it-facility management’. De subverwerkers zijn in zo’n 19 landen buiten de EER gevestigd (Argentinië, Australië, Brazilië, Canada, Colombia, Filipijnen, Israël, Japan, Kenia, Maleisië, Peru, Mexico, Singapore, Taiwan, Turkije, UK, Verenigde Arabische Emiraten, VS en Zwitserland).
  • Het ligt voor de hand dat support regionaal wordt geleverd. Google mag echter volgens de overeenkomst van alle subverwerkers in de 19 landen gebruikmaken.
  • Conclusie: Bij het gebruik van GA is er dus (mogelijk) sprake van doorgifte naar zo’n 20 landen buiten de EER, waarbij sprake is van (1) opslag en/of (2) toegang op afstand.
Nu zit het 'm zoals vaker in de details. Als je de keten van verwerkers goed in kaart wil brengen dan is de medewerking van de verwerker (als data-importeur of -exporteur) vereist. Dit is veel gevallen tevens de 'maker/beheerder van de dienst'. Deze partij is vaak beter op de hoogte van de exacte cloud architectuur en bijhorende (support) diensten. Alleen deze partij kan goed aangeven welke gegevens wel of niet worden doorgeven. Het gaan dan om vragen als: heeft een supportmedewerker in India eigenlijk toegang tot de brongegevens in GA? Dit zijn de details die van belang kunnen zijn voor de eventuele DIA (stap 3 + 4).
Google datacenters, cloud, doorgifte - franksblog.nl
Een weergave van alle Google datacenters, welke voor GA mogen worden gebruikt.

Stap 2: Bepaal het doorgifte-mechanisme

De AVG vereist een doorgifte-mechanisme wanneer er sprake is van doorgifte. Er zijn een aantal opties:
  1. Er is een adequaatheidbesluit van de Europese Commissie voor één van de 13 landen. De Commissie toetst bij zo’n besluit of een land buiten de EER een vergelijkbaar beschermingsniveau als de AVG kan waarborgen.
  2. Er wordt gebruik gemaakt van één van de passende waarborgen, zoals de contractuele De standard contractual clauses (hier te vinden) is een door de Europese Commissie goedgekeurde overeenkomst voor de doorgifte van persoonsgegevens.standard contractual clauses tussen twee partijen en/of binding corporate rules voor doorgifte binnen een concern. Bij het gebruik van dit mechanisme moet altijd een DIA worden gedaan (zie stap 3 + 4).
  3. Afwijkingen voor specifieke situaties (‘derogations’), oftewel uitzonderingssituaties. Het kan bijvoorbeeld gaan om uitdrukkelijke toestemming van de betrokkene voor enkel het doorgeven van de gegevens. De betrokkene moet dan wel zijn ingelicht over de risico’s van doorgifte naar het specifieke land. Ook bij gebruik van dit mechanisme is een DIA vereist (zie stap 3 + 4).
Als we het hebben over de ‘grote clouddiensten’ dan valt hier in de praktijk niet veel te kiezen. De standaardvoorwaarden van een clouddienst beschrijven namelijk welk doorgifte-mechanisme van toepassing is. Google hanteert voor GA (en ook Ads) bijvoorbeeld het adequaatheidsbesluit voor de doorgifte naar Zwitserland en de UK. Voor de VS en andere landen baseert Google zich op de standard contractual clauses. In de regel maken de meeste populaire clouddiensten (M365, Azure, GCP en AWS enz.) van deze clausules gebruik. In dat geval zijn stap 3+4 van belang.

Stap 3 + 4: Doe eventueel een DIA en documenteer zaken goed

De DIA is een aanvullende juridisch toets die je vaak moet uitvoeren. Er is alleen geen DIA vereist wanneer er een adequaatheidsbesluit voor het derde land is. In dat geval heeft de Europese Commissie namelijk al vastgesteld dat het land een 'veilige haven voor persoonsgegevens' is. Bij de andere doorgifte-mechanismen is dit niet het geval. Dit betekent dat er een DIA moet worden gedaan voor alle passende waarborgen (bijv. binding corporate rules en de standard contractual clauses) en de uitzonderingsituaties.De Europese rechter vindt zo’n DIA-toets noodzakelijk, omdat landen als de VS ruime informatievergaar ('intelligence') bevoegdheden aan overheidsinstanties (bijv. de NSA) toekennen. Dit soort bevoegdheden maken een grove inbreuk op de grondrechten (o.m. privacy en uitingsvrijheid) van EU burgers. In de nieuwste standard contractual clauses is de verplichting tot de uitvoer van een DIA zelfs contractueel vastgelegd: “The Parties agree to document the assessment under paragraph (b) and make it available to the competent supervisory authority on request.”, waarbij paragraph b de inhoud van de DIA-toets is.Stapsgewijs ziet een DIA er wat mij betreft als volgt uit:
  • Bepaal de omvang van de overheidsbevoegdheden in het derde land: Bepaal of er in het derde land wetgeving van toepassing is die (mogelijk) een inbreuk op de grondrechten van betrokkenen maakt. Dit is bijvoorbeeld het geval wanneer de persoonsgegevens door een overheidsinstantie (eventueel na rechterlijke goedkeuring) kunnen worden opgevraagd, afgevangen of anderszins geraadpleegd.
  • Toets de bevoegdheden en daadwerkelijke praktijk aan het EU-recht (inclusief EVRM): Bepaal vervolgens of de bevoegdheid en/of daadwerkelijke praktijk verder gaat dan wat in de EU acceptabel wordt geacht. Dit is in feite het spiegelen van het rechtsstelsel en de daadwerkelijke praktijk in het andere land aan de grondrechten in de EU, plus de rechtspraak van het Hof van Justitie en het EHRM De rechtspraak van het Europees Hof voor de Rechten van de Mens (EHRM) maakt onderdeel uit van het EU-recht. Dit volgt (onder meer) uit het Handvest van de grondrechten. Lees dit artikel als je dit beter wilt begrijpen.. De exacte kaders daarvoor zijn een blog op zichzelf. Is de inbreuk acceptabel, dan ben je in feite klaar met de toets. De uitkomst van de DIA is dan positief.
  • Neem eventueel aanvullende maatregelen: Als de inbreuk onder de huidige omstandigheden niet acceptabel is dan zijn er nog steeds 'reparatiemogelijkheden'. Je kan dan nagaan of de omvang van de inbreuk met aanvullende maatregelen tot een (naar maatstaven voor EU-recht) acceptabel niveau kan worden teruggebracht. Een voorbeeld van zo’n maatregel is bijvoorbeeld versleuteling in-transit van de verbinding tussen de data-exporteur en data-importeur, ingeval de overheid in het derde land de telecommunicatie of onderzeese internetkabels standaard aftapt. De EDPB heeft in de bijlage van deze opinie een aantal mogelijke maatregelen opgenomen.
  • Kom tot een eindconclusie (na het nemen van aanvullende maatregelen): Een DIA kan na het nemen van aanvullende maatregelen twee conclusies hebben, namelijk: of (i) de inbreuk op de grondrechten van betrokkene is ‘acceptabel’ (of zelfs nihil) en de doorgifte kan doorgang vinden; of (ii) de inbreuk is niet acceptabel en je organisatie dient te stoppen met de clouddienst.
  • Vergeet geen enkele subverwerker EN de doorgifte(s) vanuit het derde land: Vergeet ook niet de rol van subverwerkers en de eventuele doorgifte vanuit het derde land naar weer een ander derde land. Bijvoorbeeld: de doorgifte van Google vanuit de VS naar Brazilië. Al deze omstandigheden moeten ook in de DIA worden meegenomen. Het gaat om de volledige keten van (onder)leveranciers!
Nog steeds te ingewikkeld? Er zijn gelukkig ook templates om je op bij de hand te nemen. Op de website van de IAPP staan er een aantal.Het uitvoeren van een DIA is dus niet altijd vereist, maar het documenteren van zaken wel. Je moet altijd ad-hoc kunnen aantonen dat er 1) niet sprake is van doorgifte; of 2) dat het specifieke adequaatheidsbesluit voor land X de doorgifte ook dekt. Als verantwoordelijke moet je de naleving van de AVG immers altijd kunnen aantonen (artikel 5 lid 2 AVG): ook wel de “verantwoordingsplicht” (accountability). De 'DIA verplichting' geldt overigens ook direct voor de verwerker die ook data-exporteur of -importeur is. Je ontkomt hier niet aan!Tot slot, evalueer en heroverweeg je conclusies altijd periodiek. De toekomst brengt altijd weer nieuwe inzichten en/of wijzigingen in de (cloud) infrastructuur. Neem dit mee in de documentatie en DIA.

Duitse Cookiebot zaak: het belang van een DIA en documenteren

Het belang van dit stappenplan (en dan met name het documenteren van zaken) blijkt ook uit een recente Duitse (kort geding) uitspraak over het gebruik van het Deense Cookiebot. Even kort de belangrijkste feiten en conclusies:
  • De rechter heeft een verbod op het gebruik van Cookiebot aan een Duitse universiteit opgelegd.
  • Cookiebot is een oplossing waarmee websites om toestemming voor cookies en vergelijkbare technieken kunnen verzoeken
    Meer over cookies, banners en toestemming...
    • ...in dit blog lees je welke andere technieken onder de 'cookiewet' vallen...
    • ...en in deze hoe je zelf een banner kan maken.
    . Voor de levering van deze dienst wordt een ip-adres, cookie-id en een unieke sleutel/id per bezoeker verwerkt. Cookiebot slaat deze informatie samen met de permissie (bijv. ‘ja/nee marketing cookies’) op, zodat toestemming volgens de eisen van de AVG aantoonbaar is. Eigenlijk best tragisch dat juist deze 'compliance clouddienst' het onderwerp van een rechtszaak is.
  • Cookiebot maakt verder op de achtergrond gebruik van het content delivery network (CDN) van het Amerikaanse Akamai Technologies Inc. Een CDN is simpel gezegd een regionaal of wereldwijd netwerk van servers om websitebestanden (html), (javascript) plugins en andere content (in cache) zo snel mogelijk in de browser te laden. De 'CDN servers' staan met elkaar in verbinding, oftewel het is ook een clouddienst.
  • De rechter concludeert dat er sprake is van doorgifte. Het is in zijn ogen irrelevant of het ip-adres en cookie-id ook daadwerkelijk in de VS worden verwerkt. Akamai valt als 'provider of electronic communication service or remote computing service' namelijk onder de CLOUD Act. Dit betekent dat Akamai kan worden verplicht om de gegevens over te dragen aan een Amerikaanse overheidsinstantie als de NSA, ongeacht waar ter wereld de gegevens zijn opgeslagen.
  • De universiteit is verantwoordelijk voor de doorgifte, aangezien deze heeft besloten om Cookiebot te gebruiken. De universiteit kan echter geen doorgifte-mechanisme onderbouwen die van toepassing is op de doorgifte van gegevens door Cookiebot en Akamai. Een niet ingevulde versie van de standard contractual clauses is nadrukkelijk niet voldoende.
Waar brengt ons dat? Uit deze zaak zou kunnen worden afgeleid dat het gebruik van elke clouddienst met een Amerikaanse moeder en/of zelfs aandeelhoudersrelatie wordt geraakt. En dat dus elke Amerikaanse clouddienst vanwege de CLOUD Act moet worden vermeden. Dat zou verstrekkende gevolgen hebben.De spreekwoordelijke soep moet wat mij betreft niet zo heet worden gegeten. In deze zaak wordt de universiteit met name op de vingers getikt voor het niet invullen van haar verantwoordingsplicht. Er zijn immers geen (ingevulde) standard contractual clauses tussen Cookiebot en Akamai plus een DIA beschikbaar. Het ligt voor de hand dat de rechter tot een ander oordeel was gekomen, ingeval deze documentatie er wel zou zijn.Er is bijvoorbeeld ook veel (juridisch) commentaar op de conclusie dat het (mogelijk) van toepassing zijn van de CLOUD Act automatisch ook leidt tot doorgifte naar de VS. De precieze achtergrond van die argumenten laat ik even voor wat ze zijn, maar het geeft wel stof tot nadenken over het gemis van deze argumentatie vervat in een DIA en/of andere documentatie.

Samenvattend: doe de vier stappen

Wat het Duitse voorbeeld goed illustreert is de complexiteit van de cloud. De houder van een website denkt gebruik te maken van een Deens bedrijf (Cybot is de leverancier van Cookiebot), echter is de IT infrastructuur in de cloud (deels) Amerikaans (Akamai). Nu is Cookiebot qua cloud infrastructuur nog redelijk eenvoudig. Denk ook aan het voorbeeld van GA, waarbij er sprake is van doorgifte naar zo’n 20 landen/subverwerkers. Doorloop dus altijd deze stappen:
  1. Breng alle (sub)verwerker(s) en landen in kaart
  2. Bepaal het doorgifte-mechanisme
  3. Doe eventueel een doorgifte impact assessment (DIA)
  4. Leg je afweging in stap 1-3 altijd schriftelijk vast (en evalueer deze periodiek)
Doe je deze stappen, dan zit je altijd goed. Althans een stuk beter dan de universiteit in Duitsland met Cookiebot. Je zult alleen merken dat het behoorlijk wat werk is om dit voor elke relatie/overeenkomst te doorlopen…

Meer lezen?

Bekijk mijn andere blogs.

© 2021 Frank de Vries. Alle rechten voorbehouden
Privacy
RSS Feed