25 Mei 2018 moeten alle Nederlandse organisaties voldoen aan de General Data Protection Regulation (GDPR). Omdat deze Europese privacywetgeving uit een hoop tekst bestaat, vat ik het hier op een simpele manier samen.
Wat wordt er van elke Europese organisatie verwacht?
- Ieder persoon over wie je data op wilt slaan, moet expliciet toestemming hiervoor geven;
- Je geeft aan welke data je over die persoon opslaat en om welke reden;
- Daarnaast communiceer je met ieder persoon over wie je data opslaat, met welke andere organisaties je deze data deelt;
- Het is de verantwoordelijkheid van de organisatie om de persoonsgegevens te beschermen tegen lekken en misbruik;
- Als je deze data deelt met andere organisaties moet je een bewerkersovereenkomst sluiten met deze organisaties;
- Je blijft altijd verantwoordelijk over de persoonsgegeven die je opslaat en verwerkt. Je bent verplicht te controleren of de organisaties met wie je bewerkersovereenkomsten sluit, dat deze persoonsgegevens zorgvuldig beschermen tegen onbedoelde toegang;
- Ieder persoon waarover je data opslaat, heeft het recht deze data in te zien, ofwel; recht op inzage;
- Als je als organisatie gegevens over personen deelt met anderen, bijvoorbeeld op een forum of zoekmachine, dan heeft deze persoon in bepaalde gevallen het recht om vergeten te worden.
That’s it! Als je hieraan voldoet, kun je niet gestraft worden voor het lekken van data. Overigens ben je wel verplicht als er een data-lek optreedt om dit te melden aan de autoriteit persoonsgegevens (AP)
Als je deze bondige manier van communiceren goed vindt, geef dat dan aan. Ik zal de komende maanden in heldere hapklare brokken aangeven wat je als organisatie kunt doen om GDPR-compliant te zijn. Gewoon concreet. Natuurlijk zijn er veel details, maar alles draait om de basis die ik zonet beschreven heb.
Heb je vragen voor een follow-up? Plaats deze als commentaar hieronder.
Duidelijk. Ik kijk uit naar de volgende aflevering
De realiteit versimpeld.
Henri in zijn element.
Toegeven, ik houd er ook wel van. Anders is het tenslotte een hoop tekst.
Maar hoe weet je of iets correct is ? Een universele vraag : https://www.youtube.com/watch?v=V2h8fKTb_tU
Leuk startpunt! 1 aanvulling, je mag gegevens alleen gebruiken waar je ze voor gekregen hebt. Dit betekent dus ook dat je klantdata niet in een test of analyse omgeving mag gebruiken! Doe je dat wel en er ontstaat een datalek, dan heb je iets uit te leggen richting de toezichthouder.
Dag Eric,
Thanks voor je aanvulling. Overigens zeg ik het wat minder expliciet in punt 2:
“2. Je geeft aan welke data je over die persoon opslaat en om welke reden”
Als daar bij staat voor analyse, bijvoorbeeld om betere suggesties in de nieuwsbrief te geven voor je volgende aankoop, dan is daar verder niets mis mee. Zelfde geldt – in mijn ogen – ook voor testen. Althans, ik heb niet kunnen vinden dat dit expliciet uitgesloten wordt. Er zit natuurlijk heel veel “ruimte” in de verordening en uiteraard geldt als de test-omgeving slechter bewaakt wordt of andere partijen daar ook toegang toe hebben, je moet nog steeds voldoen aan de regels.
Juist door met elkaar hierover te communiceren komen we wellicht tot inzichten hoe we op een effectieve wijze GDPR-compliant worden. En als jij dit anders ziet, kunnen we het wellicht vastpinnen met de juiste artikelen.
Hier is de passage/het relevante artikel uit de Nederlandse versie van de verordening (en om een beeld te schetsen van de details zoals de GDPR is opgebouwd):
Afdeling 2: Persoonsgegevensbeveiliging
Artikel 32:
Beveiliging van de verwerking
1. Rekening houdend met de stand van de techniek, de uitvoeringskosten, alsook met de aard, de omvang, de context
en de verwerkingsdoeleinden en de qua waarschijnlijkheid en ernst uiteenlopende risico’s voor de rechten en vrijheden
van personen, treffen de verwerkingsverantwoordelijke en de verwerker passende technische en organisatorische
maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen, die, waar passend, onder meer het
volgende omvatten:
a) de pseudonimisering en versleuteling van persoonsgegevens; 4.5.2016 NL Publicatieblad van de Europese Unie L 119/51
b) het vermogen om op permanente basis de vertrouwelijkheid, integriteit, beschikbaarheid en veerkracht van de verwerkingssystemen en diensten te garanderen;
c) het vermogen om bij een fysiek of technisch incident de beschikbaarheid van en de toegang tot de persoonsgegevens tijdig te herstellen;
d) een procedure voor het op gezette tijdstippen testen, beoordelen en evalueren van de doeltreffendheid van de technische en organisatorische maatregelen ter beveiliging van de verwerking.
2. Bij de beoordeling van het passende beveiligingsniveau wordt met name rekening gehouden met de verwerkingsrisico’s, vooral als gevolg van de vernietiging, het verlies, de wijziging of de ongeoorloofde verstrekking van of ongeoorloofde toegang tot doorgezonden, opgeslagen of anderszins verwerkte gegevens, hetzij per ongeluk hetzij onrechtmatig.
3. Het aansluiten bij een goedgekeurde gedragscode als bedoeld in artikel 40 of een goedgekeurd certificeringsmechanisme als bedoeld in artikel 42 kan worden gebruikt als element om aan te tonen dat dat de in lid 1 van dit artikel bedoelde vereisten worden nageleefd.
4. De verwerkingsverantwoordelijke en de verwerker treffen maatregelen om ervoor te zorgen dat iedere natuurlijke persoon die handelt onder het gezag van de verwerkingsverantwoordelijke of van de verwerker en toegang heeft tot persoonsgegevens, deze slechts in opdracht van de verwerkingsverantwoordelijke verwerkt, tenzij hij daartoe Unierechtelijk of lidstaatrechtelijk is gehouden.
Leuke discussie!
In het artikel dat jij aanhaalt, wordt onder lid 1a bijvoorbeeld aangegeven dat je gegevens waar mogelijk moet pseudonimiseren. Dit sluit ook goed aan bij het subsidiariteitsprincipe dat ten grondslag ligt aan de GDPR. Kort gezegd komt dit er op neer dat je altijd de qua privacy minst belastende optie moet kiezen. Dus als je kunt testen of analyses kunt doen met gespeudonimiseerde persoonsgegevens in plaats van echte persoonsgegevens dan moet je dit doen. Daarnaast dien je vanuit de GDPR privacy by design vorm te geven waarin o.a. gesteld wordt dat je alleen die gegevens verwerkt die strikt noodzakelijk zijn voor jouw doel.
De Autoriteit Persoonsgegevens is hier als toezichthouder (nu nog van de Wbp) overigens nog meer uitgesproken in, op hun site staat bij veel gestelde vragen: “Mag ik testen met persoonsgegevens”, het antwoord is “Nee, dat mag niet.”
https://autoriteitpersoonsgegevens.nl/nl/onderwerpen/beveiliging/beveiliging-van-persoonsgegevens
Eric,
Het zijn inderdaad goede gewoontes die de kansen op datalekken verkleinen. Ook mag AP afwijken van de Europese verordening om het makkelijk te houden 🙂
Het valt onder goed ondernemerschap om de kansen of lekken te voorkomen en dit moet inderdaad onderdeel worden van je DNA.
Persoonlijk ben ik wel iets milder over hoe en wanneer je welke maatregelen toepast, liever leg ik de nadruk op bewustwording en groeien naar privacy by default en design.
Waar ik de nadruk op wil leggen is dat het niet enorm complex hoeft te zijn en dat je stap voor stap naar “het juiste doen” moet groeien. Het doel is betere beveiliging en bewustwording van beschermen van persoonlijke data en meer controle daarop als we bijvoorbeeld met Amerikaanse providers werken.
Ik wil digitale cursussen ontwikkelen om de diverse doelgroepen binnen organisaties te helpen GDPR-compliant te worden op een manier dat het juist iets extra’s oplevert en niet alleen gezien worden als een moetje. Omgaan met analyse en testen lijkt me daar een interessant onderdeel in wat dan vooral voor een beperkte doelgroep belangrijk is. (Data protection officer / BI-techneut die beiden iets anders voorgeschoteld krijgen.)
Ik zie op je profiel dat je ervaren bent met dit proces 🙂 Neem aan dat je dit met een vorm van hashing doet 😉
Henri,
Ik ben het helemaal met jou eens dat het een groeipad is. De praktijk is bijna nooit zwart-wit en het start sowieso met bewustwording. Alle initiatieven die daaraan bijdragen (en die organisaties laten inzien dat compliancy geen kostenpost is maar juist geld kan opleveren), juich ik toe.
Door via digitale cursussen bewustwording te creëren, help je organisaties absoluut verder in dit proces.
Wat wij vaak zien is dat organisaties compliant worden als moeilijk, lastig en ingewikkeld zien terwijl ik denk dat het juist iets is waar je stapsgewijs naar toe moet groeien. Door er mee te beginnen creëer je dan een soort olievlek waarin ze zien wat het oplevert.
Het klopt dat wij hier weleens wat mee gedaan hebben 😉 En hashing is een van de vormen, maar we gebruiken daar ook andere oplossingen voor.
Hoi,
Ik heb even een vraagje, de toezichthouder is verantwoordelijk voor dat de GDPR wordt nageleefd maar wie controleert hierop dat de GDPR wordt gehanteerd binnen een organisatie?
Voor de brandveiligheid van gebouwen heb je de NEN8012; normontwerp voor brandclassificatie elektrische kabels als onderdeel van de europese CPR (Construction Products Regulation).
Er is geen instantie die gebouwen gaan controleren op deze norm, dat is volgens mij iets tussen aannemer en eigenaar.
Als er echter incidenten plaats vinden er er blijkt verkeerde kabels gebruikt te zijn, dan kan de aannemer of opdrachtgever aansprakelijk gesteld worden.
zo is het ook met GDPR. Als er dingen mis gaan begint er pas iets te werken, maar AP gaat niet pro-actief kijken of bedrijven wel volgens de GDPR werken. Of dat is mij in ieder geval niet bekend.