privacy-blogreeks-1-1200

 

In dit vierde deel behandel ik weer meer formele insteek, wat er moet worden bepaald voordat er sprake mag zijn van verzamelen en verwerken van persoonsgegevens. Ik ga verder met doelbinding, grondslagen voor verwerking en de begrippen proportionaliteit en subsidiariteit.

In deze blogreeks over privacy ga ik in op de verschillende onderdelen van een goed privacy management framework. Uitgebreide juridische verhandelingen laat ik zoveel mogelijk achterwege. Graag geef ik je een aantal praktische handvatten om te komen tot een verantwoorde omgang met persoonsgegevens.

Het eerste deel ging over persoonsgegevens, wat is nu eigenlijk een persoonsgegeven en waarom zijn er specifieke regels bedacht voor die gegevens. In het tweede deel van de blogreeks werd de term verwerken uitgediept. Het vorige deel was een beschouwing over wanneer persoonsgegevens eigenlijk verwerkt mogen worden.

Wettelijke kaders voor de verwerking van persoonsgegevens.

Deze keer behandel ik alleen de Algemene Verordening Gegevensbescherming en geef ik alleen de links met de relevante artikelen in de Wet Bescherming Persoonsgegevens. Doordat onze wet al gebaseerd was op de voorloper van de AVG (de EU richtlijn 95/46), en de AVG op een aantal punten strenger of duidelijker is geworden, is het handiger om alle verwerkingen gelijk aan de hand van de AVG in te richten.

De AVG gebruikt heel hoofdstuk twee voor Beginselen (artikelen 5 t/m 9) over de kaders waaraan voldaan moet worden voordat een verwerking van persoonsgegevens rechtmatig is (in gewoon Nederlands, mag). De artikelen komen allemaal nog aan bod in de blogreeks, maar in deel één van deze blog beperk ik mij tot artikel 5. Deel twee wijd ik volledig aan artikel 6 en 7, dat geeft al meer dan genoeg stof tot tikken/lezen.

Als eerste natuurlijk artikel 5 “(rechtmatigheid, behoorlijkheid, transparantie, doelbinding, minimale gegevensverwerking, juistheid, opslagbeperking, integriteit en vertrouwelijkheid, verantwoordingsplicht)”

Een verwerking moet ten aanzien van de betrokkene rechtmatig, behoorlijk en transparant zijn. Uit dit artikel blijkt al dat er vooral naar het belang van de betrokkenen (zie blog één) gekeken moet worden, en niet alleen naar het belang van de organisatie die wil gaan verwerken. Uit dit artikel komt ook dat het voor de betrokkenen duidelijk moet zijn wie de persoonsgegevens gaat verzamelen en voor welk doel. Een privacy statement over het verzamelen mag niet dubbelzinnig of onduidelijk zijn. Ook moet een betrokkenen worden gewezen op zijn rechten (Artikel 12 t/m 22 van de AVG).

Belangrijke begrippen hier zijn subsidiariteit en proportionaliteit. Kunnen de doelen waarvoor we de gegevens willen gaan verwerken ook op een andere wijze worden behaald, met minder persoonsgegevens, of met persoonsgegevens die minder inbreuk maken op de privacy van de betrokken? Een voorbeeld uit de praktijk, binnen een proces in een organisatie bestaat een identificatieplicht. Een medewerker moet in het proces vaststellen dat diegene die voor hem staat ook echt de persoon is die hij aangeeft te zijn. Vaak zie je in dit proces, dat er gelijk een kopie van het paspoort gemaakt wordt aangezien er dan kan worden aangetoond dat er om een ID gevraagd is. Nog even los van de vraag of dit überhaupt mag, is dit ook totaal niet proportioneel. Hetzelfde doel, bewijzen dat de ID check heeft plaatsgevonden, kan ook op een andere wijze. We kunnen in het proces ook opnemen dat door de medewerker een vinkje wordt gezet, ID gezien en eventueel nog het ID nummer laten opnemen. We bereiken hetzelfde doel met veel minder persoonsgegevens.

Artikel 5 gaat verder met het verder afkaderen van hoe een verwerking van persoonsgegevens moeten worden ingericht. Onderdeel B stelt, dat er voor het verzamelen van persoonsgegevens een welbepaald, uitdrukkelijk omschreven en gerechtvaardigd doel moet zijn. Het gerechtvaardigde doel wordt verder uitgewerkt in artikel 6, waarin de rechtmatigheid (de grondslagen voor verwerking) worden benoemd. Onderdeel B, geeft ook aan dat verzamelde gegevens niet ook nog voor andere doeleinden worden verwerkt. Een voorbeeld van dit laatste zou zijn als het ziekenhuis verzamelde gegevens ook zou gebruiken voor een reclame van auto’s. Hier in staat nog een uitzondering voor archivering, wetenschappelijk of historisch onderzoek of statistische doeleinden. Die laat ik voor het gemak nu even buiten beschouwing.

Verder met onderdeel C; een verwerking moet toereikend zijn, ter zake dienend en beperkt worden tot het minimale wat nodig is. Als je gegevens verzamelt met het doel een nieuwsbrief te versturen, heb je geen andere informatie dan e-mailadres (en misschien naam) nodig. Dit betekent dus ook dat je bij de beoordeling of een verwerking rechtmatig is, niet alleen naar de hele verzameling moet kijken (mag ik voor dit doeleinde persoonsgegevens verwerken) maar ook naar elk afzonderlijk gegeven wat je wilt verzamelen. Je moet als verantwoordelijke er voor zorgen dat gegevens juist zijn en daar waar nodig ook geactualiseerd. Er wordt ook een plicht opgelegd om onjuiste gegevens “onverwijld” te wissen of te rectificeren. Een leuk artikel, ook om te gebruiken om het belang van bewaartermijnen bij de business duidelijk te maken. Wat ik vaak zie is dat, omdat het handig is, gegevens oneindig worden bewaard. Niet alleen is dit in tegenstrijd met een flink aantal artikelen uit de AVG, we komen het in het volgende artikel ook nog eens tegen. Maar als het dan toch tot een discussie komt kan het juistheidsbeginsel ook nog worden gebruikt. Reken maar eens uit hoeveel moeite (geld) het gaat kosten om te zorgen dat een persoonsgegevens verzameling juist blijft.

Bewaartermijnen

Het was al aangekondigd, de volgende blog gaat over bewaartermijnen. Of in de termen van de AVG, opslagbeperking. Een persoonsgegeven mag alleen worden bewaard als identificeerbaar gegeven, voor zolang als het nodig is voor de doeleinden waarvoor het verzameld is. Het is dus wel mogelijk om, als de gegevens geanonimiseerd kunnen worden en daarmee dus niet meer als direct of indirect identificatie van een persoon mogelijk maken, de gegevens langer te bewaren. Ook hier trouwens weer de uitzonderingen voor; archivering, algemeen belang, wetenschappelijk of historisch onderzoek of statistische doeleinden.

Het opstellen van bewaartermijnen is in mijn ervaring een van de grotere uitdagingen de komende tijd. Het betekent namelijk ook nogal wat in de daadwerkelijke verwerking. Een voorbeeld uit de praktijk; er wordt met behulp van elektronische formulieren gegevens ontvangen. Voor het proces waar deze gegevens in gebruikt worden is het nodig dat de melders kunnen worden benaderd. Dus naast naam en melding worden ook contact gegevens gevraagd (telefoon, adres). De melding wordt verwerkt, er wordt contact opgenomen met de melder en de melding wordt gearchiveerd ten bate van statistiek en het interne leerproces. Artikel 5 sub e, geeft dus aan dat als de melding is verwerkt, de gegevens van de melder niet meer relevant zijn (het doel van die gegevens is geëindigd). Maar als dit in een record in een database wordt vastgelegd, hoe kunnen we dan naam en contactgegevens verwijderen? Als dit niet van te voren is geregeld dan komt er dus na verloop van tijd een grote database met gegevens die niet meer onder een rechtmatige verwerking vallen.

Een oplossing is, als het kan, hier bij inrichting rekening mee te houden, en een verschil te maken tussen de opslag van gegevens die identificerend zijn (denk aan naam, adres, etc) en andere gegevens. Als er bijvoorbeeld twee databases zijn, waarbij in één database de relatie wordt gelegd tussen de identificerende gegevens en bijvoorbeeld een cryptografische hash, en een ander systeem wat de Hash koppelt aan de rest van de gegevens. Bij het verlopen van de bewaartermijn hoeft er alleen in de eerste database het hele record te worden weg weggegooid (Hierdoor zijn de gegevens in de tweede database niet meer te herleiden naar een persoon).

Beveiliging

Het laatste onderdeel, van dit artikel (we hebben het nog steeds over artikel 5 sub f) is het in security-land beroemde artikel 13 uit de WBP. Het stelt dat er voor een verwerking passende technische en organisatorische maatregelen moeten worden genomen, zodanig dat de beveiliging van de persoonsgegevens geborgd is en dat de gegevens zijn beschermd tegen ongeoorloofde of onrechtmatige verwerking, tegen onopzettelijk verlies, vernietiging of beschadiging. Samen moet dit zorgen voor de integriteit en vertrouwelijkheid van de gegevens, waarbij maatregelen tegen onopzettelijk verlies door de meeste informatiebeveiligers vaker uitgelegd wordt als beschikbaarheidsmaatregelen.

In artikel 24 wordt dit als eerste nader ingevuld als verantwoordelijkheid van de verwerkingsverantwoordelijke (een natuurlijke persoon of rechtspersoon, een overheidsinstantie, een dienst of een ander orgaan die/dat, alleen of samen met anderen, het doel van en de middelen voor de verwerking van persoonsgegevens vaststelt). De verwerkingsverantwoordelijke is in de WBP benoemt als de verantwoordelijke. In de WBP kennen we ook nog de bewerker, die heet in de AVG verwerker. Dit om het makkelijk te houden.

In artikel 32 van de AVG worden de beveiligingsmaatregelen iets verder uitgewerkt. Ze moeten namelijk rekening houdend met de stand van de techniek, de uitvoeringskosten, de aard, de omvang, de context van de verwerking en de qua waarschijnlijkheid en ernst van uiteenlopende risico’s voor de rechten en vrijheden van personen passend zijn. (excuses voor de lange zin). Dit betekent dus dat er een risico en maatregelen-analyse moet worden gemaakt, bijvoorbeeld met een gegevensbeschermingseffectrapportage (PIA). De wetgever verwacht (daar waar passend) in ieder geval de volgende maatregelen;

  • a)de pseudonimisering en versleuteling van persoonsgegevens;
  • 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.

En in het tweede lid;

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.

Uit artikel 24 blijkt ook nog dat de maatregelen moeten worden geëvalueerd en indien nodig geactualiseerd.

Inrichten beveiligingsmaatregelen

Het geheel lijkt erg op de PDCA-cyclus zoals we die ook kennen uit de ISO27001. Gaat die ook niet over beschikbaarheid, integriteit en vertrouwelijkheid? Maar in het tweede lid komt ook sterk naar boven dat het meer is dan alleen maatregelen in de IT-systemen. Het tweede lid beschrijft eigenlijk waar op dit moment de meeste datalekken uit voort komen, het ongeoorloofd toegang geven tot gegevens. Voorbeelden: het per ongeluk doorsturen van een Excel-bestand met gegevens van cliënten van een zorginstelling, het per ongeluk verliezen van een draagbare harde schijf met de gegevens van patiënten, het onbewust online zetten van gegevens van burgers die aangeslagen hebben gekregen voor de OZB, enzovoort. Elk van deze datalekkages is dus een directe inbreuk op dit artikel uit de AVG.

Volgens artikel 32 sub 3 is het om de beveiligingsmaatregelen in te richten, ook mogelijk aansluiting zoeken bij een gedragscode. Alleen zijn deze gedragscodes, verder ook uitgewerkt in artikel 40 en 42, nog niet beschreven. Het laatste deel van artikel 32 is:

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.

In wat meer IT-taal, we moeten een goed IAM proces inrichten, want we moeten zeker weten dat alleen personen die bij ons of voor ons werken toegang hebben tot de gegevens. Iedereen die bij de gegevens kan moet hier ook een opdracht voor hebben. Binnen IAM moet het direct binnen de rol passen.

Overigens de Autoriteit Persoonsgegevens heeft wel wat nadere sturing gegeven door richtsnoeren te publiceren. Maar ook hier is het hoofdmoto doe een risicoanalyse, gebruik algemeen geaccepteerde beveiligingsstandaarden en richt een PDCA-cyclus in.

In een later blog kom ik nog terug op het in dit kader ook belangrijke principe van privacy by design, of zoals het in de Nederlandse AVG heet: Gegevensbescherming door ontwerp en door standaardinstellingen (Artikel 25).

We waren gestart bij artikel 5 en daar heb ik nog één stukje niet van behandeld; het laatste lid geeft nog een klein stukje tekst, waar wel ontzettend veel werk in zit als we voor 25 mei 2018 willen voldoen aan de AVG. De tekst luidt:

2. De verwerkingsverantwoordelijke is verantwoordelijk voor de naleving van lid 1 en kan deze aantonen (“verantwoordingsplicht”).

Wat hier wordt gezegd is dat we aantoonbaar voldoen aan alle eisen uit artikel 5. Voor alle auditors is dit een feestje. Want de verwerkingsverantwoordelijke moet dus zelf zorgen voor een aantoonbare controle. Dit betekent in de praktijk dus vooral veel documentatie bij houden van alle stappen vanaf de bepaling van de rechtmatigheid, de specifieke doelbinding, de risico analyse (PIA), de maatregelen (procedures, beleid, controls), overeenkomsten met derde partijen, etc. Deze documenten moeten regelmatig worden beoordeeld en waar nodig bijgewerkt. De maatregelen moeten ook vorm van interne controle ondergaan over hun bestaan en werking. Er moet aangetoond kunnen worden dat er wordt bijgestuurd. Al deze punten lijken wel erg op een ISMS zoals dat in ISO27001 staat.

De volgende keer

In mijn volgende blog ga ik weer dieper in op de wet en regelgeving en wat er moet worden bepaald voordat er sprake mag zijn van verzamelen en verwerken van persoonsgegevens. Ik ga verder met grondslagen voor verwerking (artikel 6 uit de AVG).

Jacques Eding is een expert op het gebied van privacy management en informatiebeveiliging. Hij heeft in de afgelopen 25 jaar in verschillende rollen diepgaande kennis opgebouwd op het gebied van informatie risicomanagement, informatiebeveiliging en privacybescherming. Hij heeft binnen verschillende organisaties rollen bekleed zoals auditor, manager, adviseur, CISO, FG/DPO, en coach. Hij staat ingeschreven als EDP Auditor in het beroepsregister van Norea (RE) en is daarnaast gecertificeerd op het gebied van Privacy (CIPP/E), privacy management (CIPM), Security (CISSP), securitymanagement (CISM) en IT audit (CISA). Hij haalt naast het consultancywerk veel energie uit zijn rol als trainer bij cibit academy voor opleidingen op het gebied Security en Risicomanagement. En is geaccrediteerd door (ISC)2 als Trainer voor onder ander de CISSP- en SSCP-certificeringen.

Heeft u een vraag?

Neem contact op