De data protection impact assessment (dpia) is een GDPR-thema dat steeds meer aandacht krijgt en waar bedrijven mee worstelen om dat goed ingeregeld te krijgen. Met 25 mei aanstaande begint de druk flink op de ketel te komen. In de praktijk blijkt dat organisaties, vanwege de tijdsdruk, gaan schrappen in hun projecten en dan snel dpia’s of een aantal daarvan laten vallen. Aangezien dat één van de kernelementen is van de GDPR is het de vraag of dit slim is
Doen we het wel of doen we het niet? Dat is de vraag. De data protection impact assessment (dpia), of ‘gegevensbeschermingseffectbeoordeling’ in het Nederlands, zorgt voor verhitte discussies bij organisaties. Met de deadline van 25 mei 2018 in zicht proberen veel organisaties nog de nodige meters te maken. Als dan gedurende de projecten, met het doel de organisatie gereed te maken voor de GDPR (of AVG in Nederland), het register van verwerkingen in beeld komt, ontstaat de discussie.
Was voorheen de slotsom ‘doe mij maar een dpia’, nu zien we de keuze ‘doe maar niet, tenzij verplicht’. Met name als steeds duidelijker wordt dat een goed uitgevoerde dpia geen uurtje werk is, maar snel meerdere dagen onderzoek vergt. Ondanks dat de organisatie met het schrappen van de assessments doorlooptijd wint, blijven andere risico’s bestaan en lijkt de waarde van een dpia onderschat.
Dpia kernelement
De dpia is een kernelement binnen de GDPR (artikel 35) en de essentiële bouwsteen voor het realiseren van Privacy by design en Privacy by default (het eerder verschenen artikel geschreven door Christiaan Hille). De dpia heeft immers als doel, voorafgaand aan het starten van de verwerking van persoonsgegevens of het doorvoeren van wijzigingen daarop, na te denken over de risico’s, de GDPR-principes en regels en de maatregelen die je kunt treffen om risico’s te mitigeren of te voldoen aan de regels. Daarbij kijkt de organisatie naar alle zeven principes die de GDPR heeft opgenomen in artikel 5: ‘Beginselen inzake verwerking van persoonsgegevens’ inclusief de verantwoordelijkheidsplicht (Accountability) uit lid 2.
De GDPR benadrukt het belang van de uitvoering van een dpia en stelt deze verplicht voor verwerkingen waar een hoog risico speelt voor de betrokkenen in de verwerking van de persoonsgegevens. Voor het vaststellen van de hoogte van het risico, heeft de Artikel 29 Werkgroep (waar de nationale toezichthouders overleg hebben) een handleiding geschreven met handvatten. Juristen zien de uitspraken en publicaties van deze werkgroep als zwaarwegend bij het uitleggen van de regelgeving. De werkgroep geeft aan dat soms, als gevolg van ‘wijziging in de risico’s’, ook voor reeds bestaande verwerkingen een dpia nodig is. Dat zijn vaak de eerste verwerkingen die uit het projectplan worden gehaald.
Overigens bestaat er voor de Rijksoverheid al de verplichting voor het uitvoeren van dpia’s. Deze verplichting heeft het ministerie van Binnenlandse zaken al in 2013 geïntroduceerd en bij de introductie van het nieuwe ‘Toetsmodel privacy impact assessment (pia) Rijksdienst’ vorig jaar september bevestigd. Deze verplichting staat ook in het ‘integraal afwegingskader beleid en regelgeving” (iak) als (verplicht) hulpmiddel bij het beoordelen van nieuwe technologie, informatiesystemen, programma’s, beleid en wetsvoorstellen op het voldoen aan vereisten uit de ook de GDPR.
Daarnaast bestaat de mogelijkheid voor de nationale toezichthouder om een lijst bij te houden die verwerkingen een dpia vergen en voor welke verwerkingen deze niet verplicht is. Onze Autoriteit Persoonsgegevens heeft vooralsnog niet zo’n lijst gepubliceerd.
Samenvattend loopt een organisatie nadrukkelijk risico’s bij het besluit tot aan 25 mei 2018 geen dpia’s uit te voeren omdat diverse regelgeving de uitvoering al vereist. Onverlet geldt dat de dpia voor een organisatie een belangrijk totaalbeeld geeft over de inhoud van de verwerking, de impact op betrokkenen en vooral de kwaliteit van de maatregelen rond de verwerkingen. Bij het ontbreken van dit inzicht komen risico’s niet in beeld.
Rol risicoprofiel
Mocht toch het besluit vallen dpia’s niet uit te voeren, dan is het in ieder geval een goed advies om dat op een afgewogen wijze te doen, waarbij nadrukkelijk het risicoprofiel een rol speelt. Immers, vanuit de regelgeving blijft het aanknopingspunt voor het verplichte karakter van een dpia een ‘hoog’ risico voor betrokkenen. Belangrijk is daarbij bewust te zijn dat risico’s rond een verwerking kunnen wijzigen en daarmee ook weer een reden kunnen zijn voor een dpia. Dit is ook voor de Artikel 29 Werkgroep de aanleiding geweest om in de handreiking aan te geven dat zij minimaal één keer in de drie jaar een her-assessment verwacht op bestaande verwerkingen.
Naast het gegeven dat data protection een plaats moet krijgen in het risicomanagement-proces van de organisatie, zijn meer operationele handvatten nodig in het change management proces als onderdeel van een isms (Information security management system). Op basis van de risico/impact-inschattingen in het change management proces kan het besluit vallen om een dpia uit te voeren en daarmee risico, impact en mitigerende maatregelen concreet te maken. Door dit te integreren in het isms kunnen maatregelen efficiënt worden ingezet en gemonitord. De uitdaging daarbij is voldoende deskundigheid voorhanden te hebben om de juiste afwegingen te maken. Dit betekent het opzetten van een goed proces, met de juiste handvatten waarin voldoende deskundige en alerte medewerkers in staat zijn de (initieel ingeschatte) impact te bepalen. En daar speelt de security markt steeds nadrukkelijker op in.
Wat ik mis in het artikel, is dat de wet op 25 mei 2018 al 2 jaar bestaat, maar een tijdspanne van 24 maanden had, om bindend ingevoerd te worden.
Zijn de instanties nu te laat begonnen, was er in het verleden te veel onduidelijkheid, of is 2 jaar te kort om aan privacy en beveiliging te denken?
Voortreffelijk overzichtsartikel, met alle ins en outs die horen bij business risk management. Want laten we wel wezen, privacy is vooral een business risk.
En een even terechte opmerking van Bakker.
Een PIA hoort gewoon thuis bij requirements gathering en bij een pre-project audit. Het laatste is overigens al vele jaren verplicht bij risicovolle overheids-digiprojecten.
De PIA lijkt echter hetzelfde stiefkindje te worden dat requirements gathering al jaren is. Gebrekkig requirements gathering leidt tot testproblemen, implementatie-problemen, acceptatieproblemen, ontevreden gebruikers, overmatig changemanagement, exorbitante beheerkosten en meer van dat onaangename.
Terwijl het allemaal een kwestie is van ‘Het is niet ingewikkeld, het wordt ingewikkeld gemáákt’. Hetgeen vooral een management-issue is. Er wordt winst geboekt op ontwikkel- en projecttijd, ten koste van beheer.
Als je geen tijd/geld hebt om het goed te doen wanneer heb je dan tijd/geld om het óver te doen? Nou, héél véél tijd/geld dus.
Goede requirements gathering spáárt juist tijd en geld.
Een PIA is zó gebeurd en bespaart veel ellende.
Maar de achterliggende conclusie ontbreekt in het artikel.
Nl. dat het management ‘kennelijk’ besloten heeft dat de ‘mitigating action’ voor het risico van de GDPR en van PIA’s kennelijk is : acceptance.
Waarschijnlijk in de niet geheel onterechte verwachting dat het in de praktijk allemaal wel niet zo’n vaart zal lopen met de handhaving door de AP. Aan welke verwachting de AP overigens overigens wel héél veel voeding heeft gegeven, en nog steeds geeft.
En als men een last onder dwangsom krijgt kan men altijd alsnog verbeteringen (dus : changes) aanbrengen. Vroeg genoeg, toch?
Echter, wellicht herinnert men zich de ABNAMRO nog? Waar een manager in zijn/haar oneindige wijsheid besloot om het testen maar achterwege te laten, om zo tijd te winnen. Waarna alle AAB-geldautomaten er een volle week uit lagen.
‘Not my problem’ toch? (Engels is voertaal bij AAB).
Hetzelfde zien we nu bij de GDPR gebeuren. De GDPR is al nagenoeg twee jaar van kracht. De afgelopen twee jaar waren bedoeld als implementatieperiode en om evt. onduidelijkheden op te lossen. Over twee maanden zal er gehandhaafd gaan worden.
Maar wiens probleem is dat? En ís het eigenlijk wel een probleem?
Een bekende management-taktiek is ‘Beter excuus vragen dan toestemming’.
Iets waarop bedrijfsleven en overheden overduidelijk hebben voorgesorteerd.
Zo blijft er werk, en dus brood op de plank.
‘Het is niet ingewikkeld, het wordt ingewikkeld gemáákt’.
Graag reageer ik op de reactie van Ron Bakker.
Hoewel deze wetgeving inderdaad ondertussen ‘alweer’ twee jaar oud is, zouden we ook terug moeten kijken naar de Data Protection Directive (95/46/EC), de richtlijn uit 1995 waarvan de Wet Bescherming Persoonsgegevens de Nederlandse implementatie is (Juli 2000). Bijna achttien jaar lang hebben we al wetgevingen over het beschermen van persoonsgegevens waarin we bijvoorbeeld in artikel 6 de grondslagen van verwerking, waaronder de “toestemming” (consent) kunnen terugvinden. Toen al (zie ook de Art. 29 WP opinion on Consent uit 2011, nog steeds zeven jaar geleden) was deze toestemming “Freely given, specific, and informed” en toch wordt gedacht dat “blanket consent” (‘De datasubject heeft ja gezegd, dus we mogen doen wat we willen.’ [Ik chargeer even]) voldoende is. Ook noemt de WBP al in artikel 13 dat gegevens moeten worden beschermd naar de stand van de techniek. Toch zie ik in mijn dagelijks werk als security analyst met regelmaat techniek die al heel wat jaren als onveilig te boek staat.
Veel van de zaken over gegevensverwerking die in de GDPR staan, zijn al sinds de DPD (de WBP, zo u wil) van toepassing. Maar pas met de meldplicht datalekken is hier enig financieel gevolg aan verbonden. Met de GDPR worden die gevolgen nog veel groter zoals u allen weet. Dus nu moet een achterstand ingehaald worden, naast dat er nieuwe dingen bij komen. En nog gaat menig bedrijf nu op het allerlaatste moment pas proberen om alles op orde te krijgen. De GDPR ligt er al twee jaar, maar was daarvoor al meerdere jaren in ontwerp.
Twee jaar is inderdaad (te?) kort. Maar ruim twintig jaar ‘privacy debt’ bijwerken is ook niet niks.
Thanks. Ter aanvulling. Terechte constatering dat bedrijven en instellingen twee jaar de tijd hebben gehad. In mijn opinie toereikend om de elementaire zaken te regelen. Diverse organisaties hebben projecten opgestart maar ondervonden wel wat belemmeringen. Enerzijds omdat deze vooral vanuit een juridische insteek met GDPR bezig waren waardoor in situaties de meer bedrijfsmatige benadering ondersneeuwde. Dit werd nog versterkt doordat de interpretatie en de afweging kosten versus impact voor betrokkenen nog weinig concreet was. Ondanks dat de Article 29 WP gedurende die twee jaar wat handvatten gaf bleef dat in de uitvoering een uitdaging. Een van de redenen waarom in januari er, vanuit de werkgeversorganisaties, een verzoek kwam de controle op de toepassing van de GDPR na 25 mei wat minder stringent ter hand te nemen. Met als doel bedrijven en instellingen nog wat meer tijd te gunnen. Wat, naar ik aanneem, niet zal worden gevolgd. Vooral als ik weer eens ben verrast met een verzoek tot ondersteuning met de mededeling: ‘We zijn net gestart en willen voor 25 mei klaar zijn’. En dan hebben we het over maart 2018!
Laat onverlet dat de beschikbare twee jaar niet effectief twee jaar zijn geweest door het pas later beschikbaar komen van wat meer bedrijfsmatige handvatten. Naar mijn mening zou dit, met wat meer committment en betrokkenheid van management, dit minder een tekortkoming zijn geweest.
Uit ervaring constateerde ik dat de DPIA’s in de realisatie van GDPR snel sneuvelden en niet altijd met de juiste argumenten (boeterisico). Waarbij over het hoofd werd gezien dat DPIA’s nu juist het beste handvat zijn voor het implementeren van de juiste maatregelen maar ook voor het aantoonbaar afwegen welke maatregelen wel/niet werden genomen cq beperkingen in de verwerkingen kunnen worden aangebracht. De praktijk wijst uit dat dit waardevolle inzichten geeft en organisaties beter bewust maakt van de impact en mogelijkheden vanuit de GDPR.
De mores is: ga met DPIA’s aan de slag! of hanteer in ieder geval GDPR assessments / nulmetingen om nog enigszins de laatste handelingen naar 25 mei toe te prioriteren.
Beste Christiaan, helemaal mee eens. Wat het verhogen van boetes al niet kan doen. En die waren er overigens al een paar maandjes voor 25 mei 2016. En dan zie je ineens aandacht vanuit het management. Met zelfs nog ervaring uit de tijd van de Wet op de Persoonsregistraties van voor 2000 kan ik alleen maar zeggen dat het tijd werd. Al schiet het nu soms wat ver door in de uitvoering.
Prima aanvulling door Christiaan van hetgeen ik omwille van lengte van mijn reactie achterwege liet.
Zoals ik hier en elders al betoogde : voor diegenen die relevante wet- en regelgeving over de afgelopen drie decennia integer implementeerden is de GDPR nauwelijks extra werk.
Maar die ‘relevante wet- en regelgeving’ dateert niet pas uit 2000 (WBP) zoals Hillen stelt, maar o.a. reeds uit 1989 met de Wet persoonsregistratie (WPR) en uit 1993 met de Wet computercriminaliteit.
Toen en zoals nu kwam deze wetgeving niet uit de lucht vallen. Er ging zeer veel voorbereiding, afstemming en onderhandeling aan vooraf.
Toen zoals nu zaten conferenties, seminars en workshops vol met ‘management’. Met borrel, en ‘handig naslagwerk om het thuis allemaal nog eens goed na te lezen’. Dat laatste zijn de meesten na de borrel doorgaans vergeten.
Waarmee we bijna automatisch op het punt van Governance&Compliance; en ‘personal accountability’ komen.
Net zoals de afgelopen decennia is men op bestuursniveau ook nu angstvallig stil. Men laat VNO/NCW, VNG, MKB.nl etc. het woord doen. Parlementariërs en een niet-bevoegd minister
Overheden en bedrijfsleven zullen evt. boetes gewoon en laste laten komen van de algemene middelen. Immers : ‘acceptance als risk response’.
Ook de AP mijdt het issue hoofdelijke bestuursaansprakelijkheid voor boetes. Dat gaat elders in Europa – o.a. ICO (GB) en EUCJ – wel anders.
Mijn verwachting is dat de AP qua handhaving veel water bij de wijn gaat doen, al is het maar vanwege capaciteitsgebrek en de beperkte breedte van deskundigheid.
Organisaties die nu nog in de bewustwordingsfase zitten – en die zíjn er genoeg – doen er het beste aan een crisisaanpak te hanteren en daar een budget aan toe te kennen ter hoogte van het te verwachten boetebedrag. Iets dat men een jaar geleden al had moeten doen. En daarvoor niet een DPIA, maar een ‘Enterprise GDPR Readiness Assessment’ (géén tooltje) uit te voeren.
Dat laatste wordt echter niets als men nog steeds geen DPO heeft aangesteld. iets dat men minstens een jaar geleden al had moeten doen. Een DPO is voor veel organisaties verplicht – err on the side of caution! – en in bijna alle andere gevallen veruit de goedkoopste oplossing.
Beste Christiaan, helemaal mee eens. Wat het verhogen van boetes al niet kan doen. En die waren er overigens al een paar maandjes voor 25 mei 2016. En dan zie je ineens aandacht vanuit het management. Met zelfs nog ervaring uit de tijd van de Wet op de Persoonsregistraties van voor 2000 kan ik alleen maar zeggen dat het tijd werd. Al schiet het nu soms wat ver door in de uitvoering.