Een lezer vroeg me:
De laptop van mijn leidinggevende is recent gestolen. Helaas was het systeem niet versleuteld, waardoor gevoelige persoonsgegevens (zoals mijn naam, geboortedatum, BSN, handtekening en medische gegevens) door de dief te lezen zouden kunnen zijn. Ik ben netjes geïnformeerd en het lek wordt gemeld, maar ik vind dit niet genoeg. Wat kan ik juridisch doen tegen mijn werkgever?Allereerst: erg jammer en vervelend dat er anno 2020 nog steeds werkgevers zijn die dus dit soort gevoelige gegevens rondsjouwen zonder zelfs maar full-disk encryptie. Het is erg pijnlijk om daar via een datalekmelding achter te moeten komen.
De procedure is zo te lezen netjes gevolgd: de werknemer moet worden geïnformeerd en de AP ook, want de gegevens zijn zeer gevoelig en misbruik daarvan kan zeker tot schade bij de werknemer(s) leiden. Ook als het maar een handjevol mensen was – BSN en medische gegevens tellen als zeer gevoelig ook bij kleine hoeveelheden.
Dat wil niet zeggen dat de kous daarmee af is. De werknemer kan desondanks immers schade lijden door het lek, en volgens de AVG is de werkgever daar gewoon voor aansprakelijk stellen.
Het lastige hierbij is natuurlijk aan te tonen wat je schade is, zeker als er nog geen kwaadwillend gebruik van je gegevens is gemaakt. En bij diefstal van een laptop is de kans reëel dat dat ook niet gaat gebeuren; waarschijnlijk herinstalleert de dief Windows en verkoopt hij het ding tweedehands. Je kunt dan natuurlijk gaan monitoren op misbruik maar je zult waarschijnlijk niets tegenkomen.
Het gaat me wat ver om te zeggen dat een werkgever maar gewoon een bedrag moet geven bij wijze van forfaitaire schadevergoeding. Maar zonder concreet aangetoonde schade kan de werknemer verder niet zo veel. Bij financiële gegevens zou je nog kunnen eisen dat de werkgever een monitoringdienst betaalt om op het ahem “dark web” te kijken of je creditcard daar opduikt, maar voor bsn’s of medische dossiers is er niet echt zo’n markt.
Arnoud
Is er een equivalent van een Artikel 12-procedure voor de AP? Als dit mij zou overkomen zou het mij namelijk niet eens zozeer om een schadevergoeding gaan, maar dat de werkgever er niet met een ‘oeps, sorry, gebeurt niet nog een keer’ (maar waarbij ondertussen de actie een ‘foei’ richting laptopeigenaar is in plaats van het fixen van processen) vanaf komt.
Bij lekken van de CC gegevens zou ik zeggen dat de werkgever opdraait voor het vervangen van de creditcard. Die blokkeer je natuurlijk onmiddelijk, je gaat niet wachten tot er misbruik van wordt gemaakt.
Dat staat ook zo in de voorwaarden van de CC overigens, dus als je daar op wacht zal bijvoorbeeld VISA ook de schade niet dekken.
Ik vraag me af in hoeverre de zaak: ECLI:NL:RVS:2020:898 hier een rol in zou kunnen spelen. Hier is in hoger beroep wel een schadevergoeding toegekend ondanks dat de schade niet duidelijk aantoonbaar was maar omdat het hier om bijzondere persoonsgegevens ging. Dat is hier ook gedeeltelijk van toepassing (medische gegevens).
Daar heb je gelijk in, als het echt een medisch dossier is (de vraagsteller was een beetje generiek) dan zou je met die jurisprudentie een schatting van 500 euro kunnen doen. Ik twijfel wel, welke werkgever heeft écht medische dossiers van personeel? Gaat het dan om verslagen van bedrijfsartsen of om e-mails met “ik ben ziek want ben door mijn rug gegaan”?
Dat verbaast me inderdaad, als het gaat om meer dan ‘heeft zich ziek gemeld’ etc. Een werkgever hoort helemaal geen medisch gegevens van een werknemer te hebben, laat staan op de eigen laptop. Ik moest meteen denken aan https://blog.iusmentis.com/2020/10/07/hm-krijgt-boete-van-35-miljoen-euro-voor-schenden-privacy-personeel/ … (Al betreft dit vast een stuk kleinere organisatie als ik het zo inschat).
Wanneer een medewerker na medische klachten aan het re-integreren is dan heeft de werkgever informatie nodig over de (rest-) capaciteiten van de medewerker. Niet de volledige geschiedenis aan rugklachten maar wel “medewerker kan niet bukken en tillen.” Vergelijkbare informatie mag je verwachten een werkgever waar het gaat om psychische klachten van een werknemer die invloed hebben op de arbeidsgeschiktheid.
Wanneer je dergelijke persoonlijke gegevens op een laptop bewaart hoor je die behoorlijk te beveiligen, bijvoorbeeld met versleuteling. Mijn gok is dat er ook andere onversleutelde bedrijfsgeheimen met de laptop zijn “zoekgeraakt”.
Arnoud,
Als er ergens een slechte beveiliging is, of een datalek, zelfs maar potentieel en niet bewezen, ben jij altijd de eerste die oproept tot stevige boetes onder de AVG.
Nu is er een bewezen slechte beveiliging, een bewezen datalek van meer dan alleen NAW, een bewijs dat die gegevens in handen van een misdadiger zijn gekomen, en nu zeg je ‘Het gaat me wat ver om te zeggen dat een werkgever maar gewoon een bedrag moet geven bij wijze van forfaitaire schadevergoeding’.
Ik weet wel dat een boete iets anders is dan een schadevergoeding, maar gezien jouw eerdere instelling waarbij niet-voldoen aan de AVG serieuze financiele gevolgen moet hebben ter afschrikking, vind ik dat je hier onbegrijpelijk mild bent.
(dit is geen reactie op cg) Voortschrijdend inzicht, vergelijk dit blogartikel uit 2017:
met Een forfaitaire schadevergoeding lijkt mij gepast omdat het bestaan en de hoogte van de schade zo lastig aan te tonen zijn. Hoe bestaat het dat de AVG geen forfaitaire schadevergoeding in het leven roept, terwijl zulke vergoedingen wel zijn toegestaan voor het auteursrecht (art. 27 lid 2 Aw), en zelfs worden toegekend in gevallen waarin de daadwerkelijke schade eenvoudig begroot kan worden?Ik bedenk mij opeens een situatie waarin software ontwikkelaars kunnen komen: Je werkt dan b.v. aan software die gevoelige data moet verwerken en om het een en ander te testen gebruik je gewoon je eigen data. Je eigen BSN nummer, je eigen bankrekening, alles gewoon je eigen data, omdat je werkt aan software die dit moet verwerken en veilig moet houden…
Tot zo ver gaat het goed en in de software is de data prima versleuteld. Alleen, met die software kun je deze ook ontsleutelen. Wat nou als een collega een build van de software met jouw test-data erin gebruikt voor een Demo aan klanten? “Kijk, dit is een overzicht van gebruikers. Hier is gebruiker Arnoud. Arnoud is 63 jaar oud, heeft 5 kinderen en zijn bankrekening is NL99INGB01234567…” Tja, da’s de testdata die er dus in zit…
Datalek dus? Maar wie is er dan verantwoordelijk voor? 🙂
Daarom moet je ook zoveel mogelijk met synthetische testdata werken. Meerdere van mijn vorige werkgevers hebben mij expliciet verboden om met productiegegevens of echte persoonsgegevens te testen; of er waren stringente eisen aan het testen met productiedata, ter bescherming van de persoonsgegevens.
Jouw werkgever heeft een fout gemaakt wanneer jij niet geïnstrueerd bent hoe met persoonsgegevens om te gaan. Een gemiddeld werknemer hoort een fout zoals jij die noemt niet meer te maken, persoonsgegevens zijn al 20 jaar wettelijk beschermd. Wanneer de werknemer een vaste lezer van Iusmentis is, begin ik over moedwillige fout te spreken. 😉
Ja, dat klopt! 🙂 Ik gebruik zelf altijd fictieve data. Maar het hangt deels af van met wat voor soort data je moet werken. Als je b.v. werkt aan een boekhoud-app die inzage kan hebben in je bankrekening dan is het gebruik van je echte bankrekening wel zo handig. bij banken kun je immers geen fictieve rekeningen aanmaken en je moet toch testen of de koppeling werkt.
Maar kun je van een werkgever verwachten dat hij instructies moet geven dat je nooit persoonlijke data gebruikt om mee te testen? Of zou een (senior) ontwikkelaar dat (zoals ik) al uit zichzelf moeten beseffen?
Ik gebruik overigens al meer dan 15 jar een setje vaste namen met bijbehorende gegevens met daarbij sociale media accounts (LinkedIn, Facebook, Twitter, enzovoorts.) om ze zo realistisch mogelijk te maken. Maar ze blijven fictief. Die namen staan ook erg mooi in demonstraties en mogen wat mij betreft uitlekken. Maar een fictieve bankrekening afsluiten onder een fictieve naam is niet mogelijk. En een fictief BSN nummer bedenken dat door niemand wordt gebruikt? Da’s al helemaal lastig… Zelfs een echt adres met postcode en huisnummer is lastig omdat er altijd wel iemand woont. Dus als ik b.v. Mejuffrouw J. Janssen op Mosplein 1, 1031 AA in Amsterdam opneem met geboortedatum 29 februari 1996 in een bestand opneem dan is dat fictief, maar is het ook een data lek als deze fictieve data wordt uitgelekt?
sterker nog, sites als Drimble staan vol met adresgegevens en de woning die er zich bevindt en eventueel welke bedrijven er op dat adres zijn. Geen persoonsgegevens maar wel woongegevens, inclusief oppervlak en bouwjaar van het pand. Er schijnt nu een eetcafe te zitten op het adres wat ik net noemde. 🙂
Als je bij de “uitgever” van de nummers gaat vragen dan kun je daar vaak lijsten van test-nummers krijgen, test-BSN’s bijvoorbeeld via https://www.rvig.nl/documenten/richtlijnen/2018/09/20/test-burgerservicenummers-bsn-en-a-nummers-inclusief-omnummertabel Voor IBAN’s vond ik https://nl.iban.com/testibans
Een kaal adres is volgens mij geen persoonsgegeven, maar wanneer je gegevens aan een adres gaat koppelen kunnen dat wel persoonsgegevens worden (of zijn). Fictieve gegevens vallen eerder onder de auteurswet dan onder de GDPR.
(Ik heb ooit eens software voor een bank ontwikkeld en we hadden zelfs speciale test-pinpassen.)
Hmm test pinassen, heb ik zelf nog gemaakt, Maar alleen in de periode dat er nog met het grijze/bruine stipje o pde achtekant gewert werd. Kon elke willekeurige pas omzetten naar bv mijn eigen rekening, of waar ik de gegevens van kon uitlezen. Ooit nog opleiding daarvoor gehad van Wang Global in leiden, in de periode dat getronics gay-tronics werd :-). De nieuwe auto’s stonden daar voor de deur…. Als je weet hoe het werkt is het een peulenschil, ik snap niet dat er niet veel en veel meer misbruik van gemaakt werd. Zo makkelijk.
En mijn ervaring is ook, dat banken erg, heel erg makkelijk omgaan met beveliging. De enige die dat enigsinds serieus nam was de ABNAmro. (Heb voor al de grote banken gewerkt) Alleen maar wat verplicht is en zelfs dat nog matig. want winst-maximalisatie. En voor hen geld heel erg dat het ‘andermans’. geld is…In de ruimste zin van het woord.
Ik wel… 🙂 De meeste mensen zijn namelijk van nature goudeerlijk. Dat schijnt aangeboren te zijn. We hebben van nature de neiging om eerlijk te zijn en de waarheid te vertellen en we moeten eigenlijk liegen en misdaden eerst aanleren. En da’s best opvallend.
Dit betekent dat in veel gevallen, mensen je erop wijzen dat je iets hebt laten vallen. Sowieso zijn veel mensen van nature ook vrij slecht in criminaliteit, wat weer verklaart waarom de politie in de meeste gevallen zaken vrij snel kan oplossen. We zijn gewoon niet van nature aangelegd om oneerlijk te zijn…
Ik ook maar, dat is niet de mores van het dagelijkse leven.
Rutger Bregman met zijn boek ‘De meeste mensen deugen’ legt het erg goed uit. Zo goed zelfs dat ik mensen in de boekwinkel tientallen van zijn boeken tegelijk heb zien kopen, om weg te geven als een soort van bijbel. Zover wil ik niet gaan maar komt wel in de buurt.
Ik denk zelfs dat als het inderdaad door de rest van nederland gelezen word , het boek een ‘gevaar’ voor de overheid word, want het is nog staads angst en verdeel en heers, ook door deze overheid. Gebracht net als ome dolf ooit ‘het is goed voor de mensen en we doen het voor het volk’.
Voor integratie van een boekhoudpakket, etc., is er nu PSD2, dat elke bank moet aanbieden (en is screenscrapen verboden). Elke bank zal dus documentatie moeten hebben hoe via PSD2 aan te sluiten, compleet met een sandbox om dingen te testen, en die hebben dus ook fictieve klanten.
Ja, maar het probleem is dat banken erg terughoudend zijn met het delen van die sandbox en test-accounts. En terecht, overigens.
Maar waar het vooral om gaat is als een project er een nieuwe ontwikkelaar bij krijgt die niet goed op de hoogte is van de regel dat je niet je persoonlijke data mag gebruiken. Bij sommigen kun je dat twintig keer uitleggen en dan nog snappen ze het niet. Vaak genoeg gezien dat ze “even wilden kijken of het echt werkt”…
Tja, en dan geeft er iemand een demo en daar staat dan Jeroen in, met volledige NAW, geboortedatum, BSN en andere gegevens omdat Jeroen “even wilde testen”… Dat gebeurt veel te vaak…
Bij sommige banken kan het geheel on-line: https://developer.triodos.com/docs (API documentatie plus sandbox en interface om test data toe te voegen.)
BTW hoe zit het met bv deze adressen, kan je zelfs een excel sheet vol krijgen met duizenden NAW gegevns inclusief enige extras
één van de: https://www.fakeaddressgenerator.com
En ik heb hier nog fake geld liggen waar ik in mijn werkzemeleven geldautomaten mee testte. Is nog uit het gulden tijdperk maar moest wel voldoen aan de echtte specificaties. Het interesserde ze toen niet of ik dat in mijn bezit bleef houden. Steek er de kachel maar mee aan was hun (DEC voor de kenners, later HP ,vervolgens Compaq) reactie.