privacy-blogreeks-1-1200

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.

Zoals in het vorige blog al aangegeven, deze keer over één onderwerp. Maar wel een onderwerp wat vanuit de praktijk nogal beladen is. Ik ga het hebben over bewaartermijnen, het sluitstuk van verwerkingen. We verzamelen, verwerken en vernietigen persoonsgegevens, en dat alles via een gedegen proces. In eerdere blogs heb ik het verzamelen en verwerken van persoonsgegevens al voor een deel behandeld. Dus nu de laatste stap in de levenscyclus van een gegeven. Wanneer nemen we afscheid van de verzamelde persoonsgegevens, en hoe doen we dat.

Bewaartermijn

Om maar gelijk met de deur in huis te vallen, de Algemene Verordening Gegevensbescherming (AVG) geeft geen concrete bewaartermijn voor persoonsgegevens.  De AVG noemt in artikel 5.1(e) wel opslagbeperking. Hierin wordt aangegeven dat 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 de directe of indirecte identificatie van een persoon mogelijk maken, gegevens langer te bewaren. En er zijn een paar uitzonderingen voor archivering, algemeen belang, wetenschappelijk of historisch onderzoek of statistische doeleinden.

Over dit geheel moet vanaf volgend jaar mei wel verantwoording worden afgelegd als de toezichthouder daarom vraagt (het accountability principe).

Andere wetgeving

Er zijn een aantal andere wetten die in specifieke gevallen bewaartermijnen voorschrijven. Denk hierbij bijvoorbeeld aan de Belastingwet (bewaartermijn van 7 jaar), het kopietje ID bewijs wat onze werkgever van ons heeft, (5 jaar, art 66. lid 4. Uitvoeringsregeling LB), tijdsregistratiegegevens (52 weken na de registratie, Arbeidstijdenbesluit), gegevens betreffende etniciteit en herkomst medewerker (minimaal 5 jaar na einde dienstverband, wet Stimulering arbeidsdeelname minderheden, Wet SAMEN), Arbo-gegevens betreffende kankerverwekkende stoffen en processen (minimaal 40 jaar na blootstelling, Arbeidsomstandigheden besluit), en natuurlijk de Archiefwet. En dit zijn alleen nog maar de voorbeelden. In een aantal gevallen is er ook de plicht deze gegevens, al dan niet in combinatie met een identificerend gegeven, voor de gestelde tijd te bewaren.

Het is dus van belang dat voor elke persoonsgegevensverwerking, en eigenlijk elk brokje aan persoonsgegeven daarin, wordt vastgelegd hoelang dit zal worden bewaard, en vanuit welke doelbinding. Deze doelbinding kan rechtstreeks uit het proces komen. Bijvoorbeeld, we verzamelen NAW-gegevens van deelnemers aan een congres en geven voor deze verzameling ook het beperkte doel, het organiseren van het congres, aan. Dan is het doel voor deze verzameling voorbij als het congres is geweest. Dit als voorbeeld, meestal zal er bij een (gratis) congres ook nog een akkoord gevraagd worden op het verzamelen en verwerken van de gegevens voor toekomstige congressen of andere commerciële activiteiten.

Het komt erop neer dat we niet alleen voor het verzamelen maar ook voor het hebben en houden en vernietigen van gegevens doelbinding moeten vaststellen, proportionaliteit en subsidiariteit in ogenschouw moeten houden. We komen er in de AVG niet meer mee weg als er geen “lifecycle management” bestaat voor persoonsgegevens.

In het kader van bewaartermijnen is het dan wel aardig om te vermelden dat een verwerker het mogelijk moet maken dat toestemming wordt ingetrokken. Dit betekent dan dat alle verwerkte gegevens van de betrokkene moeten worden verwijderd en / of vernietigd (artikel 17 AVG, recht op vergetelheid). Er moet dan dus, als er geen wettelijke eis is dat de gegevens niet verwijderd mogen worden, bijna een plicht om een flexibel datawarehouse in te richten en bij te houden.

Er is ook nog de plicht bij de verwerker om, zolang de gegevens bewaard worden, te zorgen dat deze gegevens juist en volledig zijn. Strikt genomen, als we een NAW-database aanleggen met de contactgegevens van onze klanten, moeten wij er zelf voor zorgen dat in deze database de juiste gegevens staan.

Een vastgestelde bewaartermijn moet in het kader van transparantie gemeld worden aan de betrokkenen. In artikelen 12 en 13 van de AVG wordt dit transparantie beginsel ook vastgesteld.

Hoe te komen tot een bewaartermijn

Een eenduidige bewaartermijn is helaas niet te geven, er moet binnen elk gegevensverwerkend proces gezocht worden naar de minimale set van gegevens die voor de kortst mogelijke tijd worden bewaard. In het kader van accountability is “het zou weleens handig kunnen zijn voor ons” overigens een hele slechte reden.

Een handreiking om te ontdekken wat een proportionele bewaartermijn zou zijn is teruggaan naar het doel waarvoor het proces in leven is geroepen. En aan de volgende vragen voor elk stukje gegeven proberen te beantwoorden:

  • Wanneer is het procesdoel behaald?
  • Kunnen, als het doel is behaald, de gegevens die hiervoor gebruikt zijn worden vernietigd zonder afbreuk te doen aan het proces?
  • Is het langer bewaren van de gegevens een grotere inbreuk op de persoonlijke levenssfeer van de betrokkenen?
  • Zijn de risico’s op ongewenste verspreiding ook bij langer bewaren klein? (de kans wordt tenslotte groter als er meer tijd is)
  • Is er een wettelijke plicht de gegevens te bewaren?
  • Kunnen de gegevens ook geanonimiseerd worden?
  • Kan ik een betrokkene tijdens de hele bewaartermijn toegang tot de gegevens geven?
  • Kan ik de gegevens gedurende de hele bewaartermijn actueel, juist en volledig houden?

Deze vragen (en andere) komen in enige vorm ook aan bod in een gegevensbeschermingseffectbeoordeling.

Een voorbeeld

Als een bewaartermijn opgesteld is, moet er vervolgens worden geborgd dat gegevens ook inderdaad vernietigd / onbruikbaar gemaakt / geanonimiseerd worden. In onze huidige omgevingen en digitale processen is dat tot nu toe, om het eufemistisch te zeggen, een uitdaging. Onze systemen en processen zijn ingericht op bewaren, niet op verwijderen. Een reële uitdaging is bijvoorbeeld het al in een eerder blog aangehaalde voorbeeld van een proces met een digitaal formulier als input. Laten we een gemeentelijke organisatie nemen en een proces voor de publieke ruimte. Een burger kan nu in dit proces via digitale weg een melding doen. Dit geheel in lijn met de overheidswens om eind 2017 alle dienstverlening naar de burger digitaal te maken. In de praktijk betekent dit dat er via een formulier op de website een PDF-document wordt gemaakt. Op de website wordt aan de burger toestemming gevraagd om zijn gegevens te verwerken en de website verstuurt de melding via een mailbericht de ambtelijke organisatie in. In het formulier staan naast de melding, laten we zeggen een scheefliggende stoeptegel, ook de NAW-gegevens van de burger. De burger wil tenslotte graag op de hoogte gehouden worden van de voortgang in het proces. En vanuit de gemeente is dat ook wel zo klantvriendelijk. Dit formulier komt bij een groepje ambtenaren in de mailbox die de melding in het zaaksysteem zetten. Om in de gemeentelijke systemen bij te houden wie allemaal meldingen doet, wordt in het zaaksysteem de melding gekoppeld aan het BSN-nummer van de melder. En de originele melding (het PDF-document) wordt in het zaaksysteem opgeslagen.

De medewerker Openbare ruimte krijgt een volledige uitdraai uit het zaaksysteem met alle gegevens, en zal, na recht leggen van de stoeptegel, dit ook (laten) verwerken in het zaaksysteem.

Hoewel dit voor veel lezers als een redelijk normaal proces klinkt, zitten er toch een flink aantal zaken in die niet geheel (of geheel niet) in lijn zijn met de AVG. Maar laten we ons nu eens concentreren op alle locaties waar in dit proces persoonsgegevens worden opgeslagen.

Het begint al bij de webserver, hier wordt in een logbestand bijgehouden welk IP-nummer op welke tijd welk formulier heeft ingevuld, waarschijnlijk is de webserver verbonden met een business server die van het formulier een PDF maakt, en deze doorstuurt. Het is dus niet ondenkbaar dat in de cache van deze server een kopie van het PDF-document met de gegevens staat. Dan komt het terecht op een interne mailserver. Hopelijk blijft het document dan in een functionele mailbox, maar waarschijnlijker en meestal dichterbij de waarheid is dat het document op een netwerkschijf wordt gekopieerd, en in veel gevallen ook nog naar een persoonlijk stukje opslag van een medewerker. We gaan er voor het gemak wel van uit dat de organisatie volledig digitaal werkt, anders wordt de opsomming nog langer. Maar bij lezen van het document wordt een kopie gemaakt op een lokale schijf. De gegevens worden in een zaaksysteem gezet. Van de gegevens in dit zaaksysteem wordt, geheel volgens de regels, regelmatig reserve kopieën gemaakt. En uiteindelijk worden de gegevens als werkbonnen afgedrukt en naar de afdeling Publieke ruimte gestuurd. De werkvoorbereider maakt voor zijn gemak hier een kopietje van en geeft 1 kopietje mee aan de medewerker die de tegel gaat recht leggen.

En nu met de strikte privacy bril. Na afmelding van de verstoring bij de burger is er geen reden meer om het IP-nummer of de in het meldingsformulier opgenomen NAW-gegeven of het BSN-nummer te bewaren, de verstoring zelf (de tegel) is wel interessant voor statistisch of andere onderzoeken en rapportages. Als de melding binnen 48 uur volledig is verwerkt, zouden dus (volgens de strikte privacy bril) op alle plaatsen die hierboven zijn beschreven de persoonsgegevens moeten worden verwijderd, terwijl de andere gegevens wel bewaard mogen worden. Dit is een leuke uitdaging, er is nu in veel systemen / processen geen ingebakken trigger om delen van de data te vernietigen.  En in sommige gevallen kan het ook niet.

Ik hoorde laatst een leuke uitdaging voor een Functionaris gegevensbescherming. Om mee te gaan in de vaart de volkeren heeft een organisatie besloten volledig digitaal te gaan werken. Dit betekent dat alle nu op papier bestaande dossiers zouden worden ingescand en als groot PDF-document verder leven in de digitale wereld. Er was niet nagedacht hoe in dat grote PDF-document kon worden gezocht op specifieke velden / kenmerken, en al helemaal niet hoe deze dan kunnen worden verwijderd.

De silver bullet?

Ik heb overigens geen “silver bullet” anders dan vanaf de start van een proces van verwerking moet er rekening worden gehouden met de hele levenscyclus van de gegevens in dat proces. Als dit nog niet is gebeurd moet er vanuit een risicobeoordeling (het risico voor de betrokkenen) worden beoordeeld welk proces de meeste inbreuk kan hebben / heeft op de persoonlijke levenssfeer van de betrokkenen en staat er niets anders te doen dan het proces opnieuw in te richten.

Voor die nieuwe inrichting kunnen we dan een beroep doen op privacy by design en de zogenaamde Privacy Enhancing Technologies.

En als we dat toch doen, de AVG heeft nog zo’n leuk artikel wat gaat over “dataportabiliteit” (artikel 20 AVG). Een betrokkene heeft het recht alle door de verwerker verwerkte gegevens van hem op een machine leesbaar leesbaar, gangbare, gestructureerde vorm te krijgen (als betrokkene zelf toestemming voor verwerking heeft gegeven, artikel 6 lid 1 punt a, of als de verwerking plaatsvindt vanuit een overeenkomst, artikel 6 lid 1 punt b). Ook dit moet geregeld zijn voor de gehele bewaartermijn van de gegevens.

Privacyteam

Het blijkt al uit dit redelijk simpele proces dat privacy management meer inhoudt dan het opstellen van een registratie. Privacy management heeft brede implicaties die ook niet vanuit één professie kunnen worden opgelost.  Om dit te coördineren is de in het vorige blog besproken functie van Data Protection Officer / Functionaris gegevensbescherming / Privacy Officer (DPO / FG / PO) een spin in een bedrijfsbreed web. Een ideaal privacy team bestaat niet alleen uit een opdrachtgever vanuit de top van de organisatie, maar ook uit stakeholders en kennisdragers uit elke afdeling van het bedrijf. De kern van een privacy team ligt bij vertegenwoordigers van de juridische afdeling, informatiebeveiliging, compliancy en risk, ICT, informatiemanagement en document management. En moet worden uitgebreid met kennisdragers van de onderhanden zijnde processen. Dit team, idealiter onder “aansturing” van de DPO / FG / PO, zal voor elk bestaand en nieuw proces bovenstaande exercitie moeten doorlopen. Bijvoorbeeld aan de hand van een gegevensbeschermingseffectbeoordeling.

De volgende keer

In het volgende blog ga ik in op de zo genoemde generieke IT controls, en hoe deze passen binnen het beschermen van de persoonsgegevens.

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