Autoriteit Persoonsgegevens beboet Uber voor te late melding datalek

Taxibedrijf Uber heeft een boete van 600.000 euro gekregen van de Autoriteit Persoonsgegevens. Dat meldde Tweakers eerder deze week. Uber was te laat met het melden van een datalek, dat de gegevens van 174.000 Nederlandse klanten en chauffeurs betrof. De boete is lager dan je onder de AVG zou verwachten, maar dat komt omdat het datalek onder de oude Nederlandse wet werd uitgedeeld. Verrassend daarbij is dat de hostingpartij van Uber eveneens aangesproken wordt, en wel als zelfstandig verantwoordelijke. Dit terwijl gewoonlijk hosters juist als verwerker worden gezien die de data beheren in opdracht van hun klanten.

Het meest opmerkelijke aspect van het lek vond ik nog dat Uber bewust het lek onder de pet hield: de hackers die het datalek hadden gevonden, kregen een ton in dollars betaald om het maar geheim te houden. Dat is nou net niet de bedoeling onder de meldplicht datalekken, vandaar dat de boete relatief hoog uitviel. Terecht, wat mij betreft. Ook in Engeland vielen boetes, mede om die reden.

Wat mogelijk nog een dingetje wordt, is dat in het boetebesluit hostingbedrijf UTI eveneens wordt aangesproken voor het datalek. Dit omdat zij (mede)verantwoordelijke is voor de verwerkingen rondom de hosting van de gegevens, waarbij de beveiliging niet op orde bleek. En dat is raar, want de standaardopvatting is dat hosters slechts verwerkers zijn. Ze handelen in opdracht en doen wat de klant zegt, niet meer en niet minder.

In dit geval ging UTI echter wel verder dan gewoon klassiek hosten. Zo nam het bedrijf zelf beslissingen over de beveiliging en de wijze van opslag. Maar het belangrijkste nog is dat UTI en Uber gezamenlijk besloten wat er precies moest gebeuren. Dat is geen klassieke klant/leverancier relatie maar klinkt meer als een strategisch partnerschap. En dan is het niet zo gek dat er een vermoeden ontstaat dat je samen beslist voor welke doeleinden (en met welke middelen) je persoonsgegevens online zet.

Wat volgens mij de doorslag gaf, is dat UTI ook naar buiten trad als de aanbieder van de Uber-app (haar naam stond er in de appstore bij) en zelfstandig besloot hoe om te gaan met het datalek. Dan positioneer je jezelf wel heel erg in de rol van de eindbeslisser. Dat er dan een verwerkersovereenkomst is die wat anders zegt, helpt dan verder niet meer.

Hosters die nu denken, ik sla data op en beslis hoe deze te beveiligen dus ik ben verantwoordelijke, zo snel gaat het niet. Het blijft een afweging uit de totaliteit van omstandigheden. Een hoster die generieke software heeft voor beheer van gegevens en met zijn klant duidelijk afspreekt waar die aan toe is, zal weinig te vrezen hebben. Ook als je zelf je beveiligingsbeleid opstelt – zorg er voor dat de klant dit mag reviewen en er formeel al dan niet mee akkoord gaan, en je komt al een heel eind.

Beheer je clouddiensten of SaaS en bepaal je dus ook precies wat de software gaat doen, dan geldt deze les voor alles dat je aan de software toevoegt. Een klantendag voor elke nieuwe feature (of een stemmingsronde met unanimiteit) gaat te ver, maar zorg er wel voor dat de klant weet wat hij gaat krijgen en daar wat van kan vinden.

Arnoud

Tandartspraktijk krijgt patiëntendatabase niet terug van leverancier, mag dat in Nederland?

Een Amerikaanse tandartspraktijk heeft patiënten gewaarschuwd voor een mogelijk datalek omdat de softwareleverancier die de patiëntendatabase beheerde die niet wil teruggeven nu het contract is beëindigd, las ik bij Security.nl. Daarmee kan de tandarts de praktijk niet goed voortzetten, en dat is voor de patiënten natuurlijk heel vervelend. Het riep gelijk bij mij de vraag op, zou dat in Nederland / Europa net zo werken, met name gezien de AVG? Die Amerikaanse tandarts moet nu met de licentievoorwaarden betogen dat hij ergens recht op heeft, wat zonder de tekst te kennen geen sterk verhaal is. En oh ja, tentamenvraag, is dat een datalek, je database niet terugkrijgen?

Om maar met die tentamenvraag te beginnen, die is te makkelijk: ja, dat is een datalek – als je geen backup hebt. Onder een datalek of eigenlijk “inbreuk op de beveiliging” rekent de AVG ieder incident dat leidt tot ongeoorloofd gebruik maar ook verlies van persoonsgegevens. Het achterliggende idee is dat je als betrokkene – hier dus patiënt – je rechten jegens de verantwoordelijke niet goed kunt uitoefenen door zulk verlies. In dit geval, je kunt je patiëntgegevens niet inzien, je kunt niet (of veel moeilijker) bewijzen dat je hebt betaald of juist dat afgesproken is dat je niet hoefde te betalen voor iets. Als je er last van hebt, dan is het een datalek.

Stel nu even dat dit allebei Europese partijen waren geweest. Ook dan had dit de uitkomst van de zaak kunnen zijn, puur afgaande op de contractuele afspraken. Bij een business-to-business contract is het immers goed mogelijk om te zeggen, als de dienst eindigt dan gooit de dienstverlener de data weg. Dat dat onhandig is voor de klant, is iets dat die maar vooraf had moeten bedenken en een artikel over had moeten opnemen.

De AVG maakt dit niet anders. Die zegt alleen dat je inderdáád zo’n artikel had moeten opnemen in de verwerkersovereenkomst (art. 28 lid 3 punt g AVG). Maar heb je dat artikel niet, dan staat er in de AVG geen zelfstandige plicht waar je op terug kunt vallen als tandarts. Je hebt dan dus een héél serieus probleem, want je bent niet AVG compliant op meerdere punten (je data is niet gezekerd, je hebt een datalek, je verwerkersovereenkomst rammelt, je artikel 5-compliance is mislukt). Afspraken maken dus, en tot die tijd geen data bij die provider stallen.

Zelfs als je die afspraak wel hebt, is het erg nuttig om alsnog te borgen dat je daadwerkelijk een kopie van de data ergens hebt. Want alle mooie contractuele frases ten spijt, dingen kunnen kwijt raken of ontoegankelijk worden (denk faillissement, mega-grote brand, dikke vinger, ruzie over betalingen) en dan heb je precies hetzelfde probleem.

Toegang tot data regel je praktisch, niet alleen juridisch.

Arnoud

Als een security onderzoeker een datalek ontdekt, is dat dan een datalek?

Een vraag via Twitter:

Suppose during a contracted test a security testers stumbles upon a number of personal data… Is that a data breach? #gdpr – no clue yet…

Van een datalek is onder de AVG/GDPR sprake bij “een inbreuk op de beveiliging die per ongeluk of op onrechtmatige wijze leidt tot de vernietiging, het verlies, de wijziging of de ongeoorloofde verstrekking van of de ongeoorloofde toegang tot doorgezonden, opgeslagen of anderszins verwerkte gegevens” (artikel 4 definitie 12). Kernwoorden hierbij zijn dat de beveiliging geschonden is en dat die persoonsgegevens vervolgens per ongeluk of onrechtmatig zijn verwerkt.

Je kunt als security-onderzoeker bij een opdracht ontdekken dat persoonsgegevens kwetsbaar zijn voor zulk onrechtmatig verwerken. Dat kan per toeval of door gericht onderzoek naar security-kwetsbaarheden. Een simpel voorbeeld is dat je een standaardwachtwoord gebruikt (het bekende admin/admin voorbeeld) of een trucje uithaalt om een beveiliging te omzeilen, dat is immers deel van security onderzoek bij een bedrijf.

Met zulk handelen wordt dan een beveiliging geschonden, en vervolgens krijg je toegang tot persoonsgegevens die niet voor jou bestemd zijn. Dat zou volgens de letter dan een datalek zijn.

Alleen, gezien de aard van het onderzoek zou ik het raar vinden om deze toegang als “onrechtmatig” te kwalificeren. Het is deel van je werk, het kan gebeuren dat je dit tegenkomt. Daar is dan niets onrechtmatigs (of per ongeluks) bij. Ook zou ik dit geen ‘inbreuk’ in de zin van de wet noemen – die term heeft een ondertoon van illegaal gedrag, en een ingehuurde security onderzoeker handelt natuurlijk niet illegaal in zijn werk.

Natuurlijk moet je als onderzoeker wel gebonden zijn aan geheimhouding, het is immers niet de bedoeling dat je die gegevens vervolgens ergens anders voor gaat gebruiken. Maar dat staat standaard in de algemene voorwaarden (of apart getekende NDA) lijkt me zo.

Belangrijk is wel dat deze constatering door de security onderzoeker moet leiden tot een nader onderzoek. Want als de onderzoeker erbij kon, dan konden anderen dat misschien ook. En dát zou dan wel een datalek opleveren.

Arnoud

Moet je ieder theoretisch mogelijk datalek al melden bij de toezichthouder?

Een lezer vroeg me:

Bij ons bedrijf loopt een discussie over de meldplicht datalekken. Wij kunnen niet uitsluiten dat geen van onze medewerkers ooit in een phishing-truc trapt, of dat iemand via een uiterst geavanceerde hack binnendringt en data steelt op een manier dat de logging wordt omzeild. Moeten we dan elke dag een datalek melden? Immers, je moet lekken melden tenzij je kunt uitsluiten dat er data is gelekt.

Nee, dat hoeft niet in dit soort theoretische gevallen.

Allereerst is een beveiligingsfout pas een datalek als er daadwerkelijk iets is gebeurd én je daar weet van hebt. Is je een datalek niet opgevallen, dan heb je niets om te melden en dan hoef je dus ook niet te melden. (De lat ligt bij “had moeten weten” volgens mij, dus als een normaal oplettend iemand het had geweten dan kun jij niet zeggen “lalala datalek hoe bedoel je”).

Kun je uitsluiten dat er iets is gebeurd, dan hoef je niet te melden dat die fout er zat. Logbestanden zijn een goede manier om uit te sluiten dat via een gemanipuleerde URL data is opgevraagd bijvoorbeeld. Ook de aanwezigheid van bijvoorbeeld een firewall die het verzenden van data via een bepaalde poort verhindert, zou ik genoeg vinden om niet van een datalek over die poort te spreken.

Het idee is dat je pas iets moet melden als je concreet een incident hebt. Het heeft weinig zin om te zeggen “misschien ben ik gephisht” of “mogelijk zat er een intruder op mijn netwerk die de klantdatabse heeft gedownload buiten ons IDS om”. Met zo’n melding kan er geen onderzoek of wat dan ook volgen.

Ten tweede: als je weet hebt van een datalek, dan moet je het melden tenzij de kans op schade voor betrokkenen minimaal is. In de praktijk komt dat neer op of je kunt uitsluiten dat er misbruik wordt gemaakt van de persoonsgegevens. Het is hier dus niet tenzij je kunt uitsluiten dat er een lék is geweest, maar uitsluiten dat er scháde door het lek is. Arnoud

Arnoud

Hoe is het een datalek om de namen van personeel in je metadata te laten staan?

De Autoriteit Persoonsgegevens, waarbij bedrijven datalekken verplicht moeten melden, heeft zelf per ongeluk de namen van werknemers openbaar gemaakt. Dat gniffelde Nu.nl en heel wat meer media naar aanleiding van de ontdekking van onderzoeker Mischa van Geelen van beveiligingsbedrijf NFIR. Die had gezien dat namen van personeel te vinden was in de metadata van zo’n 800 pdf-documenten, terwijl beleid van de AP is om geen namen van individuele medewerkers naar buiten toe te communiceren. Ohooh de juf laat een scheetje, en het doet ook wat knullig aan natuurlijk om op die manier namen te lekken, maar is dit nu werkelijk iets om je druk over te maken?

Natuurlijk zijn namen van personeelsleden persoonsgegevens. Daar moet je als werkgever dus zorgvuldig mee omgaan, en lijsten van medewerkers zomaar aan derden geven of op internet zetten lijkt me niet echt de bedoeling. Als het toch gebeurt, zou ik echter wel moeite hebben met de conclusie dat dit dús een meldwaardig datalek is. Als er meer bij staat, zoals salaris of andere gevoelige zaken, dan zonder meer, maar alléén een naam? Welke negatieve gevolgen ondervindt iemand van de onthulling dat hij bij organisatie X werkt?

Helemaal heb ik er moeite mee omdat het hier gaat over de naam van de ambtenaar die beleidsdocument Y heeft geschreven bij organisatie X. Natuurlijk kan het beleid zijn van de AP om die niet te publiceren, maar daarmee is het nog niet automatisch een noemenswaardig datalek dat die gegevens tóch op straat komen. Volgens mij is het doodnormaal dat bij publicaties van bedrijven de namen van de werknemer(s) in kwestie genoemd wordt (en afhankelijk van hoe je de Auteurswet leest, is het zelfs een récht van de werknemer), dus daarmee zie ik niet hoe het onrechtmatig is. Laat staan dus meldplichtwaardig.

Maar goed, het was even leuk lachen. Ik neem aan dat al die bedrijven zelf keurig datalekbeleid hebben en ondertussen AVG compliant zijn?

Arnoud

Mag een site me tegen betaling zeggen of ik gehackt ben?

Wat is dit nu weer voor een dienst: Is mijn data gelekt.nl. “Ismijndatagelekt.nl biedt internetgebruikers de mogelijkheid om te checken of er inloggegevens van hen op internet te vinden zijn. Deze internetgebruikers kunnen hierop dan actie ondernemen en zichzelf beter beschermen”, zo staat er in de “over ons”. Wil je echter weten om welke gegevens het gaat, dan moet je even € 4,95 afrekenen alvorens je een rapportje ontvangt. Ik heb het geprobeerd maar niets gekregen, dus in de tussentijd maar even een blogje: eh, mag dat?

Zoals ik het begrijp, zoekt men in openbare bronnen naar gelekte bestanden met logingegevens zoals emailadressen en wachtwoorden. Deze combineert men dan om zo gegeven een e-mailadres te kunnen melden welke sites er gehackt zijn, en welke informatie op straat ligt (e-mailadres, wachtwoordhash, wachtwoord, beveiligingsvragen, et cetera). Dat bundelen en ter informatie verstrekken aan de slachtoffers lijkt me een prima idee.

Het doet ahem wat raar aan dat je moet betalen om die informatie te krijgen. Je zou zeggen dat als je weet dat iemand slachtoffer is van een misdrijf, je die persoon gratis helpt. Maar goed, dat is een ethische discussie. Een slotenmaker vraagt ook geld als hij een door inbraak vernield voordeurslot gaat vervangen, en je gestolen fiets wordt ook niet gratis vervangen. Ik kan in ieder geval geen juridische grond bedenken waarom je géén geld mag vragen om die informatie te delen.

Waar het wel mis mee gaat, is dat er nul identiteitsverificatie plaatsvindt. Je moet een vinkje aanvinken met “Ja, ik ben de eigenaar van dit e-mailadres” maar dat doorstaat natuurlijk de giecheltoets niet: geen redelijk mens zal denken dat dát identiteitsfraude tegenhoudt. En vervolgens krijg je dus – althans, dat zegt men – de gegevens toegemaild naar een willekeurige e-mailadres. Dus de bekende gelekte wachtwoorden, beveiligingsvragen et cetera van een willekeurig gekozen e-mailadres.

En ja daar weet ik wel wat juridisch op, dat noemen we volgens mij een datalek. Een inbreuk op de organisatorische beveiliging (namelijk de check, spreken we hier met de eigenaar) die leidt tot een onrechtmatige verstrekking van persoonsgegevens waardoor de betrokkene nadeel kan ondervinden (namelijk het misbruiken van zijn account). Dus nee, dit mag niet.

(Ik weet het, die informatie staat allemaal al in openbare bronnen dus kwaadwillenden kunnen het toch al vinden. Maar dat boeit onder de Wbp of de AVG werkelijk helemaal niets: als jij informatie bijeen brengt en herpubliceert dan ben jij daar verantwoordelijk voor. En nee, niks notice/takedown of beperkte aansprakelijkheid.)

Arnoud

Duh, natuurlijk is iemands OV-saldo in kunnen zien een datalek

Via de website van de ov-chipkaart is eenvoudig te checken wat het saldo is van een willekeurige ov-chipkaart, las ik op de blog van Loran Kloeze. De saldochecker van Trans Link Systems blijkt te werken zonder ingelogd te zijn, enkel door invullen van een kaartnummer krijg je het huidige saldo op die kaart te zien. De vraag is dan, is dat een datalek? Het antwoord is, eh, nee dat is geen vraag dat spreekt voor zich. Toch?

De saldochecker is een simpel en op zich handig tooltje waarmee je je saldo kunt checken. Bij een anonieme kaart kan ik me voorstellen dat je dit als feature aanbiedt, maar bij een persoonsgebonden kaart klopt het volgens mij niet dat er buiten het account om persoonlijke informatie te achterhalen is.

En ja, het saldo op je persoonsgebonden kaart is een persoonsgegeven. Die kaart staat op naam en dus zijn alle gegevens die met de kaart samenhangen persoonsgegevens, geen twijfel over mogelijk. Dat het niet triviaal is om naam en adres van de kaarthouder te achterhalen, doet daarbij niet ter zake. Die link is er, dus zijn het persoonsgegevens.

Helemaal als je de update van Kloeze leest: ook je geboortedatum is te achterhalen zonder inlog, wanneer je via de webshop van de NS iets koopt, geeft TLS je geboortedatum door enkel op basis van een OV-chipkaartnummer.

TLS zegt hierover:

Goed gezien, geen authenticatie. Saldo inzichtelijk, dit is een grote wens van vele reizigers. Wekelijks meer dan 30.000 raadplegingen. Probeer het uit! ^MdeG

Ik denk niet dat ze bedoelen dat het een grote wens van veel reizigers is om elkaars saldo in te zien. Maar het is en blijft een datalek, je bent eenvoudigweg niet bevoegd om andermans saldo in te zien dus daar moet een authenticatiestap tussen.

Arnoud

Is het een datalek om een domeinnaam te laten vervallen?

Door het laten verlopen van een domeinnaam heeft Samsung miljoenen gebruikers risico laten lopen, zo laat de Portugese beveiligingsonderzoeker Joao Gouveia op Twitter weten. Dat las ik bij Security.nl. De domeinnaam hoort bij een door Samsung opgeheven dienst (S Suggest), die gebruikers populaire applicaties laat zien die gegarandeerd compatibel met hun apparaat zijn. De onderzoeker ziet nu miljoenen verzoeken vanaf Samsung-telefoons naar de domeinnaam. Is dat nu ook al een datalek?

Het is natuurlijk een blunder eerste klas. Een domeinnaam kost een paar euro, en een simpele “This service is not available anymore”-autoresponder moet ook geen bakken geld kosten. Maar zelfs de domeinnaam nergens heen laten wijzen had gekund, dan waren mensen ook wel snel gestopt met die app. En nu zou een kwaadwillende het protocol kunnen reverse engineeren en nepdata sturen, bijvoorbeeld suggesties voor phishing-apps die mensen dan klakkeloos installeren “want Samsung zegt dat deze compatibel is”.

Maar of het een datalek is? Daarvoor is vereist dat via dit domein persoonsgegevens lekken. Enkel dat een telefoon verbinding maakt met een app is denk ik niet genoeg daarvoor. (Tenzij je zegt dat headers zoals X-Asid persoonsgegevens zijn.)

Als de verbinding succesvol is en er wordt dan persoonlijke informatie opgestuurd door de app, dan komt die nu dus bij een ongeautoriseerd persoon terecht. Dus dan zou ik het wel een datalek noemen. Maar dat is wel een stevige als, en bovendien eentje die zich pas ruime tijd later kan voordoen.

Desondanks kan ik er niet bij dat Samsung dit heeft laten vallen.

Arnoud

Geldt de meldplicht datalekken ook voor defaced websites?

Tweakersgebruikers melden maandag defacement van verschillende websites, waarbij de site zelf is vervangen door een boodschap die afkomstig lijkt te zijn van een Turkse groepering. Dat las ik op Tweakers gisteren. Of er een link is met de gebeurtenissen rond de Turkse minister van Familiezaken Kaya, is onduidelijk. Maar diverse lezers vroegen me wel: moet je dit nu melden aan de klant, valt dit onder de meldplicht datalekken?

De meldplicht datalekken geldt voor alle datalekken waarbij persoonsgegevens zijn betrokken. Een datalek is een inbreuk op de beveiliging van persoonsgegevens waardoor deze kunnen worden misbruikt, of gebruikt op een manier die niet toegestaan is. Doet zo’n datalek zich voor, dan moet dat in principe worden gemeld bij de toezichthouder (tenzij de impact minimaal is) en vaak ook bij de betrokkenen (tenzij de data encrypted was of de impact wederom minimaal is). Dit geldt nu onder de Wbp, en vanaf volgend jaar ook onder de Privacyverordening.

Voor andere data of andere soorten misbruik van persoonsgegevens geldt de meldplicht niet. Mijn standaardvoorbeeld is de hack bij een accountant waarbij de nog geheime jaarcijfers van een bv of nv worden gestolen: heel vervelend maar géén datalek in de zin van de wet en dus ook niet meldingsplichtig.

Bij een defacement worden pagina’s vervangen door andere teksten en/of afbeeldingen, in dit geval dan met een politieke strekking. Ik vraag me af of daarbij persoonsgegevens worden geraakt. Het kan natuurlijk altijd, maar het ligt voor mij niet voor de hand dat iemand die inbreekt om een tekst/afbeelding ergens neer te kwakken, ook persoonsgegevens van gebruikers kopieert of zelfs maar die langs ziet komen. Dus ik zou dit niet direct als datalek aanmerken.

Het is natuurlijk wel zo netjes om dit als bedrijf te melden aan je klant. Ik zou zelf vinden dat je dit verplicht bent vanuit je zorgplicht als goed opdrachtnemer. En vaak staat het ook in de algemene voorwaarden: bij gebleken misbruik of inbraken zal de hoster de klant informeren over genomen maatregelen, daaruit volgt dan ook een plicht tot melden dat een defacement heeft plaatsgevonden. Maar een datalek is het niet.

Arnoud

Wie is aansprakelijk voor dat #cloudbleed-lek van Cloudflare?

Door een bug in de html-parser van CloudFlare konden gevoelige gegevens van klanten van het bedrijf lekken en stond data in de cache van zoekmachines. Na een melding van Google heeft de dienst voor optimilisatie van websites het lek in zeven uur gedicht. Dat meldde Tweakers, met meer details in The Register. De clouddienst had een klassieke buffer overflow-fout, waardoor willekeurige data van andere websites of databases meegestuurd kon worden bij een opvraging van een webpagina. En via Twitter de vraag (dank, Sven): “Is CF responsible for ‘breaches’ at each of those exposed companies?”

Volgens Tweakers zou er geen misbruik zijn gemaakt van de bug, die ontdekt werd door Google’s anti-zerodayproject Project Zero. Maar het lijkt mij nogal ernstig: de bug zorgde voor een abusievelijke opname van data in webpagina’s, maar onzichtbaar voor gewone gebruikers. De data kon echter van alles bevatten, van wachtwoorden tot persoonsgegevens. En dat wordt dan ook nog gecrawled door Google en collega’s, dus in caches overal zit nog dergelijke data. Auw. Wie gaat dat vergoeden?

In het algemeen is er geen wettelijke regeling wie aansprakelijk is voor het lekken van vertrouwelijke informatie. Dit wordt dan ook eigenlijk altijd contractueel geregeld: klant en leverancier spreken af welke data vertrouwelijk moet worden behandeld, welke schade of boete mag worden geclaimd en wanneer sprake is van een overtreding (dan wel overmacht of andere situatie zonder aansprakelijkheid). Dat kan gaan van “leverancier vergoedt elke cent van elke gelekte byte” tot “leverancier is nooit aansprakelijk, hooguit bij opzettelijk lekken”. Of klanten Cloudflare kunnen aanspreken, is dus een kwestie van in de contracten duiken.

Specifiek voor persoonsgegevens ligt dat iets anders in Europa. Daar zegt de wet (de Wbp, en straks de Privacyverordening) dat de aansprakelijkheid voor schade door datalekken ligt bij de (verwerkings-)verantwoordelijke, oftewel de partij die bepaalt waarom die gegevens zijn verzameld en wat daarmee gebeurt (juridisch: die doel en middelen vaststelt van de verwerking). Dat is dus in principe de partij die zaken doet met de personen, bijvoorbeeld een webwinkel of forum die klant- of gebruikersgegevens krijgt.

Alle partijen die die gegevens vervolgens opslaan of gebruiken in opdracht van die verantwoordelijke, heten bewerkers en zijn naar de betrokkenen toe op dit mnoment niet direct aan te spreken. Het is de verantwoordelijke die de claims krijgt – maar hij kan ze wel verhalen natuurlijk op die bewerkers. Daarvoor wordt het juridisch instrument van de bewerkersovereenkomst gehanteerd, een aanvulling op het ICT-contract die specifieke afspraken over persoonsgegevens bevat. Als klant moet je je dus melden bij je webwinkel, forum et cetera met je schadeclaim, en zij kunnen het dan bij hun hoster verhalen die het weer bij Cloudflare gaat halen.

Onder de Privacyverordening wordt dat strenger, dan kun je ook bij verwerkers (zoals ze dan gaan heten) direct een schadeclaim indienen als benadeelde partij. Dan mag je dus als klant of gebruiker van een internetdienst die bij Cloudflare zit, direct bij Cloudflare je schade gaan halen. En ja, Cloudflare valt onder de Privacyverordening ook al zitten ze nog zo hard in de VS.

Het blijft bij privacyclaims echter altijd een hele lastige wat die schade dan precies is, in geld uitgedrukt. Daar zijn ook onder de Verordening geen concrete handvatten over. Ik blijf het herhalen: het wordt tijd voor een staffel met forfaitaire schadebedragen, van zeg 50 euro voor lekken NAW gegevens tot 2.500 voor lekken medisch dossier.

Arnoud