Je hebt nog 256 dagen om de AVG te implementeren #256totAVG

Vandaag zijn er nog precies 256 dagen te gaan tot de nieuwe Europese privacywet in werking treedt. Op 25 mei 2018 zal namelijk de Algemene Verordening Gegevensbescherming (AVG, ook wel General Data Protection Regulation oftewel GDPR) van kracht worden. En dan wordt de wereld weer een stukje interessanter, want het is me een partij regelgeving waar je aan moet voldoen. Ik blijf erbij dat de AVG een van de belangrijkste nieuwe wetten voor de ICT-dienstverlening gaat worden, en dat de discussies en aanvaringen hierover groter gaan worden dan de auteursrechtenoorlog van de afgelopen 15 jaar.

Voor een groot deel is de AVG aanscherpen van de regels uit de huidige wetgeving. Dat echt alles verboden zou worden, is dan ook een tikje overtrokken. De angel daar zit hem er vooral in dat je uitgewerkt moet hebben waarom je doet wat je doet. Onderbouw maar eens waarom je een belang hebt bij het vergaren van iemands gegevens, en laat maar zien hoe je die toestemming hebt gevraagd die specifiek deze handeling toestaat. Je moet dit per verwerking(!) in een intern register bijhouden zodat na te zoeken is waarom je dingen doet.

Sommige dingen zijn wel nieuw. Privacy by design staat nu als harde ontwerpeis in de wet, en moet dus meegenomen zijn in elk traject om tot nieuwe informatiesystemen te komen. Bij elk scherm aangeven waar de privacy een rol speelt en wat daarover is besloten. Keuzes motiveren waarom het niet een onsje minder kon met die persoonsgegevens die je hier ziet. En aan de achterkant waarom de security op orde is.

Ah ja, security. Steeds belangrijker maar weinig méér daarover in de wet. Zorg er voor dat je het op orde hebt en dat je dat kunt aantonen. Inclusief je proces om datalekken op te sporen en te melden bij de toezichthouder (en meestal ook betrokkenen). En oh ja, ook dat moet in een intern register worden gedocumenteerd.

Veel registratie dus. Verwerkingen, datalekken, security en je designkeuzes ten aanzien van privacy. Wie gaat dat beheren? Een privacy officer oftewel functionaris gegevensbescherming is niet verplicht onder de AVG (tenzij je overheid bent, met bijzondere persoonsgegevens werkt of structureel aan tracking of besnuffelen doet) maar kan wel een goed idee zijn. In ieder geval totdat je organisatie gewend is aan de nieuwe wet.

En dat is uiteindelijk waar de pijn zit met de AVG. Dit is niet een nieuwe wet die een kwestie is van wat extra vinkjes, je privacyverklaring nieuwe terminologie geven en een Excelsheet met daarin de nieuwsbrief en de klantenadministratie genoemd bij wijze van register. Het vereist een nieuwe manier van denken, van omgaan met persoonsgegevens. Waarom hebben we die, kan het niet wat minder en hoe borgen we dat alles goed blijft verlopen? Wie denkt dat hij er zonder kleerscheuren vanaf komt met alleen die Excel erbij en wat klusjes voor Juridische Zaken, gaat het voelen.

Vandaar dat ik steeds zeg dat dit de belangrijkste wet gaat worden voor de komende 15 jaar. We hebben sinds ongeveer 2000 geworsteld in de ICT-rechtspraktijk met de botsing tussen auteursrecht en ondernemen, van notice/takedown tot aansprakelijkheid van tussenpersonen daarvoor. Ook het merkenrecht (denk domeinnaam) was natuurlijk een belangrijke bron van conflicten. Die strijd is wel zo’n beetje voorbij, maar was zo tekenend dat je veel kantoren zag die zich IE/ICT kantoren zijn gaan noemen. Vandaag de dag zou ik eerder Privacy/ICT kantoren verwachten.

Als laatste: nee, er komt geen overgangsrecht vanaf 25 mei. We zitten namelijk al in het overgangsrecht, dat twee jaar duurt. Daarvan zijn dus nog 255 dagen over. Dus wie nog niet begonnen is: heel veel sterkte met het halen van de deadline.

Arnoud

32 reacties

  1. Ik kan de AVG alleen maar toejuichen. Onder ondernemers zal de nieuwe wetgeving niet zo populair zijn, maar voor de rest van de mensheid is het een goede ontwikkeling.

    Beveiliging blijkt een moeilijke klus voor de wetgever. We weten allemaal dat gegevensbeveiliging zelfs voor uitvoerende overheden geen prioriteit is, ondernemingen nog daargelaten. De strategie van de wetgever lijkt hier te zijn: laten we ondernemers in een bad van bureaucratie gooien voor elke gegeven dat ze gebruiken, dan gaan ze vanzelf wel minder gegevens verwerken.

    Maar de twijfels blijven bestaan: zonder een stok achter de deur wordt de AVG -net als de Wbp- een dode letter. De Autoriteit persoonsgegevens heeft meer bevoegdheden, maar gaan ze ook dusdanig meer boetes uitdelen, dat er een omslag komt in hoe men met gegevens omgaat?

  2. Hoe moet je reageren op nieuwe technologische ontwikkelingen?

    Bijvoorbeeld, bij elektronische betalingen heb je een betere “privacy by design” als mensen hun eigen saldo + betalingen bijhouden in plaats van dat het centraal werd bijgehouden. Tot nu toe was het zo dat centraal bijhouden noodzakelijk was om fraude te voorkomen (het “double spending problem”, bijv. iemand geeft zijn geld uit, en verwijdert de uitgave daarna uit zijn eigen administratie zodat ‘ie zijn geld weer terug heeft). Met nieuwe Bitcoin-achtige(*) technieken is centrale registratie in de toekomst niet meer nodig.

    Vroeger had je als dienstverlener dus een excuus “ik moet de gegevens wel verwerken, want anders gaan mensen massaal frauderen”; met de nieuwe techniek bestaat dat excuus niet meer. Betekent dit dat dienstverleners verplicht zijn om hun systemen te upgraden naar nieuwe technieken met betere privacy, zodra die beschikbaar komen?

    (*) Bitcoin-achtig: Bitcoin zelf houdt nog steeds alle transacties bij in een centrale block chain, met als enige verschil dat die met iedereen wordt gedeeld; in wezen dus juist minder privacy; alleen het feit dat je pseudoniem kunt handelen geeft wat privacy. Er zijn wel nieuwere technieken in de maak die veel betere privacy bieden.

    1. Je zult als bedrijf niet voor hoeven te lopen op wetenschappelijk onderzoek, maar als je achterloopt op de “established best practices” dan heb je wel iets uit te leggen. Ik vind Bitcoin een slecht voorbeeld, maar je kunt je afvragen hoe een electronisch patientendossier er uit komt te zien als er “privacy by design” op toegepast is. Ik zou heel graag als patient kunnen bepalen welk deel van mijn dossier beschikbaar is voor het EHBO team en een ander deel van mijn dossier alleen na mijn expliciete toestemming beschikbaar stellen aan een behandelaar.

      Laten we het ook nog eens hebben over “slimme meters”…

  3. Ik ben vanuit mijn Maatschappelijk werk organisatie druk doende om de AVG te implementeren. Met name het meekrijgen van de organisatie en het bestuur is een uitdaging. Binnen de organisatie en verschillende samenwerkingsverbanden wordt veel gebruik gemaakt van vrijwilligers. Deze vrijwilligers zijn her en der actief binnen de verschillende projecten, maar zijn bijna niet inzichtelijk/beheersbaar door het aantal en de verschillende plekken waar ze actief zijn. Ten aanzien van de AVG vind ik dit een hele ‘lastige’ groep om beheersbaar te krijgen. Alle medewerkers hebben toegang tot een beschermde en afgesloten ICT omgeving. Onze vrijwilligers hebben geen toegang tot deze omgeving en hebben dus ook niet direct zicht op de geregistreerde klant gegevens. Eigenlijk worden ze op ICT gebied niet gefaciliteerd! Gezien het aantal vrijwilligers en beheersbaarheid is het voor nu ook geen optie om ze toegang te geven tot een afgeschermde omgeving. Dit betekent dat de vrijwilliger met zijn/haar eigen mailaccount of WhatsApp contact heeft met de klant. Mijn vraag is of en hoe dit ‘afgedekt’ moet worden. Via deze communicatie kanalen kunnen/worden dus gegevens uitgewisseld tussen vrijwilliger en klant (bijvoorbeeld belastingpapieren, brieven etc.). Lopen we hier als organisatie een risico of is dit een wederzijdse afspraak tussen vrijwilliger en klant!

    1. Wat je beschrijft klinkt als “gebrek aan privacy door gebrekkig ontwerp”. Gmail is niet privacy-vriendelijk want Google scant de inhoud van alle mails. Je zou op zijn minst voor alle vrijwilligers een goede mailbox moeten regelen. Voor klantvriendelijkheid zou het goed zijn om vrijwilligers selectief toegang te kunnen geven tot klantgegevens, maar dat kan ook door een medewerker files te laten kopiëren naar een folder op een vrijwilligers-server.

      1. De vraag is daarbij of persoonsgegevens uberhaupt verstuurd ‘moeten’ worden per mail. Of we nu Gmail hebben of een andere mailoplossing. Toegang geven tot klantgegevens is mogelijk, maar moet dan ook gecommuniceerd, lees gegevensuitwisseling, plaatsvinden met de klant? Het overzetten van files naar een folder is wat mij betreft een groter risico dan alle mail verkeer tussen vrijwilliger en klant;)

        1. Een van de verplichtingen in de AVG is het verwijderen van de persoonsgegevens wanneer ze niet meer nodig zijn. Dat is met email lastiger te bereiken (en te controleren) dan op een fileshare. Het is natuurlijk ook nodig om de vrijwilligers in te lichten over de privacyregels en hoe (en waarom) die ingevoerd zijn.

  4. Als je anoniem wilt betalen kun je het beste contant (en dan het liefste met munten) betalen.

    Het is overigens een leuke regel. Als wij bij alle klanten dezelfde informatie zouden verzamelen als die we voor sommige diensten nodig zijn dan zouden we niet blij worden. Veel informatie vragen we dan ook niet of maken het niet verplicht. Voor sommige domeinextensies heb je een paspoortnummer of bsn nodig of btw nummer nodig…

    Basis contact gegevens lijken mij vaak verdedigbaar om wel te vragen. Ook onder de nieuwe wet hoop ik dat dat zo blijft. Onder basis contact gegevens versta ik naam/post adres/e-mail adres/telefoonnummer. Deze gegevens heb je nodig om met een klant contact op te kunnen nemen om een factuur te sturen of als de klant niet tijdig betaald. Of denkt iemand dat dit niet verdedigbaar is?

    1. Voor domeinnaamregistratie?

      Betaling zou je zo kunnen regelen dat als er niet op tijd betaald wordt, de domeinnaam wordt vrijgegeven. Je hoeft helemaal niets op te slaan, je hoeft alleen een interface te bieden voor gebruikers om hun periodieke betalingen te doen; bijvoorbeeld een website waarop je je domeinnaam kunt invullen, en dan per iDeal, PayPal, Bitcoin of whatever de betaling kunt doen. Voor automatische incasso moet je wel gegevens opslaan, maar dat zou een optionele dienst kunnen zijn, waar de gebruiker al dan niet mee akkoord gaat.

      Contact-adres zou je optioneel kunnen opslaan voor het geval er problemen zijn, met betalingen of van wat voor aard dan ook. Dit is in het belang van de klant, maar omdat het strikt genomen niet noodzakelijk is voor het uitvoeren van de domein-dienst zou je dit ook optioneel kunnen maken.

      Wat wel echt noodzakelijk is, is het opslaan van account-informatie waarmee de klant zich kan authenticeren om instellingen te wijzigen, bijv. de doorverwijzing van het domein, betalings- en/of contact-instellingen. Ik zou zeggen dat dit een structuur is van accountnaam, salted+hashed wachtwoord (of public key voor de die-hards), lijst van domeinnamen (met hun bijbehorende DNS instellingen), en optionele instellingen voor contact + betalingen. Voor zover daar persoonsgegevens in zitten is het allemaal optioneel, en het is duidelijk voor de gebruiker of ze er wel/niet in zitten.

      Enige probleem is wellicht als er klachten komen over diensten die op een anoniem geregistreerd domein worden aangeboden, bijv. DMCA takedown requests of terrorisme-gerelateerde ongein. Je moet als domeinboer wel zelf uit de problemen zien te blijven; ik weet niet wat daar voor nodig is. In geval van juridische dwang zou je als uiterste sanctie altijd nog een domein offline kunnen halen.

      1. Voor domeinnamen moeten we gegevens van de domeinnaamhouder (=klant) doorgeven richting de registry (eventueel via een registrar en anders rechtstreeks). Daar vragen ze standaard om naw gegevens en een e-mail adres en telefoonnummer is in de praktijk ook standaard. In bepaalde gevallen willen ze ook een fiscaal nummer of iets dergelijks hebben. Die gegevens moet je dan wel hebben om de dienst te kunnen leveren. Een anonieme optie aanbieden of vereisen is lang niet altijd toegestaan.

          1. Ik verwacht niet dat ze dat gaan doen, ten minste niet in alle gevallen. Deze verwachting is mede gebaseerd op het feit dat als ze meer gegevens vragen het vaak om niet Europese ccTLD’s gaat. Hoe kun je die dan toch leveren aan Europeanen?

            1. Nou ja, als jij zo’n exotische TLD wil hebben dan kan ik wel billijken dat je je dan ook aan hun regels onderwerpt. Net zoals je in een ver buitenland met rare lokale regels zit die we hier in Europa misschien heel raar vinden. Ik denk wel dat Europese registrars van zulke registries knel komen te zitten als we de AVG strikt toe gaan passen, want zij moeten zich wel aan de AVG houden bij het verzamelen van die gegevens. Dus als .verweggistan ineens eist dat bijvoorbeeld seksuele voorkeur van de houder meegestuurd wordt (want aldaar is homoseksualiteit strafbaar) dan denk ik niet dat Europese registrars .verweggistan kunnen aanbieden.

    1. En hoe krijg je dat nummer in handen als je de klant niet kunt bereiken/deze niet op andere opties reageert?

      Zolang je verwacht nog een factuur te sturen moet je het dus hebben. Bij naast andere situaties waarbij een reactie vereist is en je die op andere wijze niet kunt krijgen. Ook voor normale support heb je het in de praktijk soms nodig leert ervaring.

    1. Vanuit de dataverwerker bezien, ja, mogelijk. Vanuit de betrokkene bezien, volstrekt niet.

      Als je echt vindt – en dat vinden we, privacy is een grondrecht etc. – dat een betrokkene autonoom moet kunnen bepalen wie wat waarvoor over hem mag weten, dan moet je het wel min of meer zo regelen.

      Wie dat ontkent, ontkent ofwel het grondrecht privacy of kan een alternatief schetsen.

      1. Sanne, een heel klein, helemaal niet vergezocht voorbeeldje:

        Stel jij wilt mijn diensten als octrooigemachtigde afnemen. Jij schrijft mij een email, waarin je je uitvinding uitlegt, netjes je contactgegevens geeft, en vraagt om een afspraak, en dan schrijf je ‘…maar niet maandagmiddag want dan moet ik met mijn oude moeder mee naar de nierdialyse’.

        Wat moet ik nu doen? Ik moet enerzijds de email wel opslaan, want die bevat jouw gegevens als (potentiele klant), en inhoudelijke feiten die van belang zijn voor de goede uitvoering van een mogelijke toekomstige opdracht. Die heb ik misschien over tien jaar nog nodig als jij mij een professionele fout aanwrijft. Ik MOET die wel bewaren.

        Anderszijds mag ik die info over je moeder helemaal niet hebben. Ik moet dus die email deleten. En ik moet ook nog eens je moeder contacteren dat er per ongeluk medische info over haar bij mij terecht is gekomen. Ik moet dus tijd besteden om haar op te sporen. En ik moet het datalek ook nog eens gaan melden.

        Dat wordt dus een hele mooie manier om je concurrentie te f**ken. Je voordoen als potentiele klant, en dan stiekem wat privacygevoelige info in het bericht zetten. En dan twee weken later die concurrent vragen of hij wel juist gehandeld heeft. En of hij dat aub eventjes netjes schriftelijk kan bewijzen.

        Als je dat drie keer per dag doet van verschillende emailadressen komt die arme concurrent niet meer aan werken toe! Ik zie de clickfarms in China al in hun handen wrijven.

        1. Zoals ik schreef: vanuit de verwerker bezien is het soms lastig. Mijn punt was juist: je moet wel als je wilt kijken vanuit de betrokkene. Hoe wil je het privacyrecht van die moeder op alternatieve wijze precies beschermen? Het moet wel ongeveer zo, anders is dat privacygrondrecht een dode letter.

        2. Is dit wel een datalek? Ik mag als ontvanger er wel op vertrouwen dat sprake is van toestemming van de betrokkene, gezien de context. Dan is er geen sprake van onrechtmatige verwerking volgens mij. En als uit onze zorgplicht volgt dat die mail in een dossier moet worden bewaard, dan is ook verwijderen of corrigeren geen mogelijkheid denk ik. (Natuurlijk hebben wij adequate beveiliging op die dossiers en zit zo’n mail neit tien jaar in een Outlook-mapje.)

          1. Het grootste probleem voor mij zit hem erin dat je eigenlijk ieder bestand, iedere email, welbewust moet doorzoeken op het voorkomen van privacygevoelige gegevens, om er een correcte AVG-behandelings-status aan toe te wijzen.

            En dan moet je dat doorzoeken van die bestanden ook nog eens periodiek herhalen, zeg iedere 6 maanden, want afhankelijk van wat er zich verder nog voordoet, kan die status veranderen. Zo kan het best verdedigbaar zijn dat je de gegevens van een potentiele klant bewaart, en als daar na 6 maanden toch niets uit blijkt te komen, dat je die dan toch delete. Maar dat zou je dan weer moeten melden aande verzender (toch?), dat je die orienterende email van 6 maand geleden, verwijderd hebt (of valt dat ook onder de (aangenomen, impliciete) verwerkingstoestemming?)

            En dan moet je al die handelingen en overwegingen ook nog eens documenteren, want als er iemand komt vragen: ‘wat heb jij met mijn email van 6 maand geleden, waar mijn telefoonnummer instond, gedaan?’, dan moet je daar een antwoord op kunnen geven.

            Misschien zie ik het te somber in.

          2. ‘(Natuurlijk hebben wij adequate beveiliging op die dossiers en zit zo’n mail neit tien jaar in een Outlook-mapje.)’

            Wat is er intrinsiek onveiliger aan een outlook mapje (die bij een betrouwbare provider op een server staat, en waar je alleen aankunt als je een password hebt) dan aan een CRM systeem of fileserver (die ook ergens bij een betrouwbare provider gehost staat, en waar je ook alleen aankunt als je een password hebt).

            Ik meen het, wat is er, wat AVG betreft, mis met een outlookmapje?

  5. Ik lees hierboven (en daar schrik ik van):

    “Sommige dingen zijn wel nieuw. Privacy by design staat nu als harde ontwerpeis in de wet, en moet dus meegenomen zijn in elk traject om tot nieuwe informatiesystemen te komen. Bij elk scherm aangeven waar de privacy een rol speelt en wat daarover is besloten. Keuzes motiveren waarom het niet een onsje minder kon met die persoonsgegevens die je hier ziet. En aan de achterkant waarom de security op orde is.”

    Ik lees het namelijk zo dat je apart moet vastleggen welke privacy-afwegingen je maakt bij het ontwerp van een systeem. Dat haal ik niet uit art. 25 en ook niet uit de overweging die erbij hoort (78).

    En als het wel moet is dat een hele berg werk.

    Heb ik iets over het hoofd gezien?

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.