Waar moet ik op letten als ik een privacy policy lees, wat is echt belangrijk?
Heb jij een interessante vraag op het snijvlak van privacy, cybersecurity en recht? Stuur je vraag naar juridischevraag@security.nl. Elke week geeft ict-jurist Arnoud Engelfriet in deze rubriek antwoord.
Juridische vraag: Of ik nu software installeer, een account aanmaak of een dienst afneem, overal moet ik akkoord gaan met een privacy policy. Vaak pagina's lang en niet altijd even makkelijk leesbaar. Waar moet ik nu op letten als ik een privacy policy lees, wat is echt belangrijk?
Antwoord: Ah, de privacy policy, privacyverklaring, privacy statement of GDPR notice. Weinig dingen zijn zó vol met oubollige geruststellende taal waar werkelijk niemand op zit te wachten. Maar het moet: artikel 13 en 14 AVG eisen toelichting in duidelijke taal bij ieder gebruik van persoonsgegevens door bedrijven of instanties.
De structuur van de meeste van deze teksten is dan ook dezelfde. Men benoemt wat de AVG voorschrijft. Welke categorieën gegevens verzamelt men, voor welke doeleinden en met welke AVG-grondslag is dat gerechtvaardigd. Je hebt rechten, zoals inzage en correctie. Gegevens worden goed beveiligd, en bij klachten kun je de functionaris gegevensbescherming benaderen. Oh ja, en de verklaring kan van tijd tot tijd wijzigen.
Mocht dit vrij algemeen klinken: dat klopt. Ik durf wel te zeggen dat het gros van deze teksten geschreven is zonder uitgebreid overleg met de technische en marketingmensen die de software of dienst aan de man brengen. En het helpt natuurlijk al helemaal niet dat ChatGPT en consorten in 3 seconden een "volledig AVG proof privacycverklaring" kan ophoesten, waardoor je als ondernemer niet eens meer naar de privacymensen hóeft te gaan.
Inderdaad, ik ben buitengewoon cynisch over het instrument. De vele vele onderzoeken (hier eentje uit 2019) bevestigen dat ook: het lezen kost enorm veel tijd en echt wijzer wordt je er niet van.
Het probleem is voor mij niet zozeer "waar moet je op letten" als wel "staat er iets in waar je wat mee kunt". Wat vaak fijn is om te weten, is of je persoonsgegevens naar de VS gaan. Maar juist dat staat er zelden tot nooit hard in. (In de praktijk mag je gewoon aannemen dat dit gebeurt, gezien 99% van de diensten uiteindelijk tot Amerikaanse IaaS te herleiden is.) Ook hoe een en ander beveiligd is, kom je niet echt te weten. Met een beetje geluk wordt verwezen naar een beveiligingsbeleid of een opmerking over ISO 27001.
Het enige dat in de praktijk zinnig is, is de contactgegevens van degene bij wie je moet zijn bij klachten of je rechten inzake de omgang met persoonsgegevens.
Om het dan niet ál te cynisch te maken: Tuurlijk zijn er genoeg bedrijven en privacy officers die serieus hun best doen het goed uit te leggen. Maar bijsluiters zijn naar hun aard moeilijk specifiek te krijgen, zeker als je organisatie wat groter is en je toch meerdere producten en varianten moet dekken.
Wat wérkelijk helpt, is bij de plekken in je software of dienst waar je persoonsgegevens verkrijgt gerichte uitleg plaatsen over het hoe en waarom. Dus niet "Wij en onze 9157 partners respecteren uw privacy, lees de privacyverklaring voor details", maar "Uw geboortedatum vinden wij handig om u op uw verjaardag een cadeautje te kunnen mailen".
Oh ja en terzijde: wil iedereen stoppen met akkoord vragen op privacypolicies onder welke naam dan ook? De AVG is vrij duidelijk dat het gaat om een mededeling, een uitleg. Privacyverklaringen zijn bijsluiters, meer niet. Het is onzinnig en overbodig om te vragen of men het daarmee eens is. Ook als je meent persoonsgegevens te gebruiken onder de grondslag toestemming - toestemming vraag je apart en expliciet, niet in een lap tekst achter een hyperlink.
Arnoud Engelfriet is ict-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als chief knowledge officer bij juridisch adviesbureau ICTRecht en blogt dagelijks over internetrecht. Hij schreef onder meer de boeken ICT&Recht en AI&Algorithms, en verzorgt de opleiding tot Certified Cybersecurity Compliance Officer.
Inderdaad vraag ik soms een organisatie wat zij over mij bewaren, hoe ze aan de gegevens zijn gekomen en met wie het wordt gedeeld.
Waarom vraag ik dit? Nou. Verschillende redenen.
Als ik spam krijg uit naam van een organisatie, dan vraag ik die gegevens. Dan wordt voor mij en voor die organisatie volstrekt duidelijk dat de naam van die organisatie wordt misbruikt . Dat kan die organisatie dan niet meer ontkennen. Vaak geef ik als reply nog wat adviezen (die eigenlijk nooit worden opgevolgd hoor) zoals : gebruik een van een gekwalificeerd seal onder elke email die je als rechtmatige organisatie verstuur. Daarmee wordt je automatisch betrouwbaarder (herkenning afzender, wettelijke inbedding, etc). Daarmee wordt (op termijn) herkenbaar als een misbruiker de naam van die organisatie misbruikt.
Ook als een organisatie op een gestelde functionele vraag niet antwoord. Dan gebruik ik dit om een antwoord af te dwingen. Niet helemaal volgens de bedoeling van de AVG, maar het werkt wel.
en soms andere redenen.
Het is onrealistisch om alles door te lezen elk moment van een service maar je kan wel heel snel scannen op grootste fouten zoals generieke teksten die niks met de dienst te maken hebben of slechte kennis over wat noodzakelijke verwerking is of ontbreken van juiste plichten en rechten van dataeigenaren na de eerste 20 overeenkomsten voor je neus gehad te hebben kan je het gros van fouten heel gauw pin pointen.
Kan je nu al eentje zo zeggen privacy policies die uitgaan van software families waarbij ze niet per service een losse privacy policy leveren maar alle door linken naar een algemene van het bedrijf. Je herkent die onzin als er staat dat de privacy policy van toepassing is op de website en overige diensten terwijl je dus te maken hebt met een softwarepakket. Of verkeerde bedrijfsnaam in plaats van waar jij je contract mee opstelt staat er het moederbedrijf genoemd. Heel vaak indicatie dat ze letterlijk een kopie paste hebben gekregen na een overname. Big red flag.
Professioneel ander verhaal natuurlik dan wil je er alle tijd voor reserveren. Net als revisies op overeenkomsten wil je vaak door vergelijking software halen. Maar meeste zullen natuurlijk niet voor privé een half uur lang alles doorlezen voor ze doorklikken op een dienst.
Echter als je meer een poweruser bent en online privacy, veiligheid iets hoger in vaandel hebt kun je altijd een snelle site audit overwegen. Ik gebruik zelf de European Data Protection Board (EDPB) Website Auditing Tool
https://code.europa.eu/edpb/website-auditing-tool/-/releases
Software leest de opgegeven pagina uit maakt een overzicht van cookies, sources, webbugs en toont de belangrijkste informatie zoals beperkt tot lokaal of extern gebruik, levensduur van de cookies en waar het voor dient mits bekend.
Vervolgens kan je in de zelfde tool een checklist afwerken van GDPR compliance en daar wordt dan een rapportage uitdraai van gemaakt welke punten ze wel en niet aan voldoen.
Je hebt ook meteen officieel te gebruiken evidence collection data voor een DPA mocht het zover komen en .har bestand voor developers van een bedrijf om exact alle requests terug te lezen die gemaakt waren ten tijden van de audit. (let op die .har bevat dus wel persoonsgegevens van je)
Ik gebruik de tool voornamelijk voor het controleren op hoe goed een bedrijf hun diensten zelf kent en serieus neemt. Staat er in de cookie policy bijvoorbeeld dat een bepaald cookie funtcioneel is maar audit toont dat dit een marketing gericht cookie is dan weet je al dat ze slordig zijn met hun auditing. Zelfde voor levensduur van cookies. Of welke cookies webbugs zijn er voor dat je een cookie banner accepteert vergeleken met erna. Heel veel sites gaan de mist in door al marketing cookies en connecties te starten voor je de banner uberhaubt hebt aangeklikt. Vaak schakelen ze de cookie en connecties daar erna wel uit als je geen toestemming geeft maar dat is uiteraard een wassenneus dan. Daarbij wel gezegd dat is vaak ook onkunde van waar de code is geplaatst in plaats van opzet.
Als dat soort zaken welke volledig of groot en deels geautomatiseerd kunnen worden gecontroleerd niet opvallen voor een bedrijf dan kan je er gif op innemen dat er meer niet in de haak is met de privacy of gebruiksbeleid. Dan kun je of of uitwijken naar iets anders of het dialoog aangaan met een aangestelde bedrijfs DPO. Uit ervaring kan ik je zeggen dat je een stuk verder komt met site, service klachten als je een kant en klare rapportage hebt want afterall het is maar een paar klikken extra om die ook richting een DPA door te sturen in plaats van een DPO.
Het enige nadeel het werkt enkel voor sites..
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?