Meldplicht Datalekken en Privacy Impact Assessments als compliance instrumenten?

Op 1 januari 2016 is de algemene meldplicht datalekken ingegaan. Deze verplichting houdt in dat organisaties (zowel bedrijven als overheden) onverwijld een melding moeten doen bij de Autoriteit Persoonsgegevens [1]  In dit artikel wordt eerst ingegaan op het 'stappenplan'  om te komen tot de keuze of er wel/niet moet worden gemeld waarbij de nadruk ligt op de onderdelen ‘beveiligingsincident’ en ‘datalek’ en wat de rol van IT-professional hierbij zou kunnen zijn. Daarna wordt ingegaan op de vraag of organisaties datalekken zouden kunnen voorkomen door het uitvoeren van een Privacy Impact Assessment (PIA).

mr. drs. Jeroen van Puijenbroek RE

De plicht om datalekken te melden is niet nieuw. Met de implementatie van de gewijzigde e-Privacyrichtlijn [2] in de Telecommunicatiewet (Tw) geldt sinds 2012 al een meldplicht voor datalekken van aanbieders van ‘openbare elektronische communicatiediensten’. Onder deze aanbieders vallen internetserviceproviders zoals XS4ALL en Ziggo en telecomproviders zoals KPN, Vodafone en T-Mobile. Vanaf 1 januari 2016 is de meldplicht niet meer beperkt tot deze serviceproviders en telco’s   maar geldt een algemene meldplicht voor alle bedrijven en overheden om een ernstig datalek onverwijld (lees: binnen 72 uur na ontdekking) te melden. Hoewel vaak wordt gesproken van de Wet Meldplicht Datalekken (Wmd) is het eigenlijk een wijziging van de Wet bescherming persoonsgegeven (Wbp); de meldplicht is verwoord in het nieuwe artikel 34a Wbp. Nederland loopt met de wijziging in de Wbp vooruit op de komende Europese Algemene Verordening Gegevensbescherming (Avg) waarin ongeveer dezelfde bepalingen zijn opgenomen. De Avg zal op 25 mei 2018 in werking treden en op dat moment de Wbp vervangen.

Wat is een beveiligingsincident en een datalek?
In de Wbp is in artikel 13 opgenomen dat de organisatie die persoonsgegevens verwerkt (in Wbp-termen: de ‘verantwoordelijke’) passende technische en organisatorische maatregelen moeten nemen om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking. Wat een passend beveiligingsniveau is, is afhankelijk van de risico's die de verwerking en de aard van te beschermen gegevens met zich meebrengen en de stand der techniek. Om invulling te geven aan wat een passend beveiligingsniveau is, heeft de AP “Richtsnoeren Informatiebeveiling” opgesteld. [3] Kortweg komt er op neer dat de getroffen beveiligingsmaatregelen overeen moeten komen met de, op dit moment voor dit soort gegevens, algemeen geaccepteerde beveiligingsstandaarden binnen de praktijk van de informatiebeveiliging. Mocht er onverhoopt toch een inbreuk plaats vinden op deze beveiligingsmaatregelen dan is er sprake van een beveiligingsincident. Als bij dit incident persoonsgegevens verloren zijn gegaan, of dat onrechtmatige verwerking redelijkerwijs niet is uit te sluiten dan is er sprake van een datalek. Bijvoorbeeld het kwijtraken van een USB-stick, de diefstal van een laptop of een inbraak door een hacker. In figuur 1 is dit grafisch weergegeven.

 

WMD

 

Figuur 1 Afwegingen Melden datalek [Bron: AP: Beleidsregels voor toepassing van artikel 34a van de Wbp

Uit figuur 1 blijkt ook dat niet elk datalek hoeft te worden gemeld aan de AP en dat niet alle aan de AP gemelde datalekken hoeven te worden gemeld aan de betrokkene. Gaat het om persoonsgegevens van gevoelige aard, of is er om een andere reden sprake van (een aanzienlijke kans op) ernstige nadelige gevolgen voor de bescherming van de verwerkte persoonsgegevens dan moet worden gemeld bij de AP en als bovendien het datalek waarschijnlijk ongunstige gevolgen heeft voor de persoonlijke levenssfeer van de betrokkene dan moet ook hem worden gemeld. In het artikel van Peter Kits en Marloes Dankert (elders in dit nummer van De Informatie) [4] wordt nader ingegaan hoe deze criteria ten aanzien van het wel/niet verplicht melden moeten worden geïnterpreteerd.

Doel meldplicht
Als je met organisaties praat over de beweegreden van het melden van datalekken, wordt vaak als argument genoemd om de datalek onverwijld te melden bij de AP en zo nodig ook aan de persoon over wie persoonsgegevens zijn gelekt omdat de toezichthouder een boete kan opleggen die kan oplopen tot €810.000 of 10% van de jaaromzet. Dit boetebedrag valt overigens in het niet als de rechter overgaat tot het toekennen van een schadevergoeding en/of vergoeding van redelijke  kosten in geval een datalek tot identeitsfraude zou kunnen leiden. Dit kan oplopen in de miljoenen. Het argument van de boete wordt ook gehanteerd voor de verplichting van het aanleggen van een register van alle datalekken door een organisatie.

Het in de Wbp opnemen van een boetebevoegdheid door de AP voor het niet, niet tijdig of niet volledig melden van een datalek is echter geen doel van op zich maar een middel om het doel te bereiken. De zogenaamde stok achter de deur. Het doel van de meldplicht is mijns inziens de schade van betrokkenen als gevolg van een datalek zo minimaal mogelijk te houden en om tot een betere bescherming van persoonsgegevens te komen. Dit zou beteken dat de beveiligingsmaatregelen waarnaar wordt verwezen in artikel 13 Wbp niet alleen zouden moeten bestaan uit preventieve maatregelen die voorkomen dat een dreiging leidt tot een beveiligingsincident maar ook uit detectieve, correctieve, repressieve en herstelmaatregelen.  Als gevolg van bijvoorbeeld detectiesoftware kan een organisatie signaleren dat een hack (incident) plaatsvindt/heeft plaatsgevonden, kunnen de tekortkomingen in de beveiliging tijdig worden gerepareerd en de negatieve gevolgen van het beveiligingsincident worden beperkt en verholpen.  Onderdeel van de correctieve maatregelen zouden in dit geval ook het “veiligstellen van de systemen” moeten zijn voor forensisch onderzoek voordat de tekortkomingen worden gerepareerd. Voor het ontwerpen van een evenwichtig samenstel aan maatregelen zie ik een rol weggelegd voor de IT-professional. Voor de werkzaamheden van de IT-professional is de geest van wet misschien wel belangrijker dan de letter.

Gegeven het doel van de meldplicht en de verschillende typen maatregelen, zou je het tijdig melden van de datalek aan de betrokkene als een repressieve en/of herstelmaatregel kunnen zien om de negatieve gevolgen voor de betrokkene te beperken in plaats van sec. een verplichting vanuit de wet. Vaak zullen personen over wie gegevens zijn gelekt naar aanleiding van het lek direct actie moeten ondernemen, bijvoorbeeld als het gaat om loginnaam en wachtwoord die veranderd moeten worden of een rekening die geblokkeerd moet worden.

Het bijhouden van een register van datalekken door de organisatie kun je zien als een detectieve en/of correctieve maatregel. Als gevolg van het clusteren van de verschillende datalekken kan de organisatie haar processen/systemen verbeteren en kunnen toekomstige incidenten worden voorkomen. Veel van de bij de AP gemelde datalekken betreffen slordigheden. Voor kleine datalekken (met weinig impact) zou de vergelijking hier kunnen worden getrokken met klachtenafhandeling, waarbij een klacht een gratis advies van de klant is.

 

Privacy Impact Assessments

Doel van de PIA
De PIA is “een methodologie voor het vaststellen van de privacy-impact van een project, beleid, programma, dienst, product of ander initiatief (hierna wordt alleen nog project opgenomen) en, in overleg met belanghebbenden, het nemen van eventueel noodzakelijke mitigerende acties om een negatieve impact te voorkomen dan wel te verkleinen. [5] Met een PIA kan een organisatie privacy risico’s van een project in een vroeg stadium op een gestructureerde en heldere manier in beeld brengen. Voor meer informatie over PIA’s verwijs ik naar het artikel “Privacy Impact Assesment en Privacy by Design – Wat de IT-professional moet weten“ van Van Puijenbroek in een eerdere publicatie in De Informatie. [6] Het uitvoeren van een PIA zal onder de Avg (vanaf mei 2018) verplicht worden voor verwerkingen van persoonsgegevens die “waarschijnlijk een hoog risico inhouden voor de rechten en vrijheden van een natuurlijke persoon”.

Kunnen datalekken worden voorkomen door PIA’s?
Aan de hand van een PIA-vragenlijst wordt vastgesteld wat voor het betreffende project de privacy risico’s van de gegevensverwerking zijn voor de betrokkenen en voor de organisatie. In de praktijk wordt bij het vaststellen van de privacy risico’s voornamelijk geredeneerd vanuit de positie van de organisatie zelf die de persoonsgegevens verwerkt en niet of in mindere mate wat de privacy risico’s zijn voor de klant, patiënt, burger, etc. (de betrokkene). Als uit de PIA bijvoorbeeld blijkt dat gegevens langer worden bewaard dan noodzakelijk voor het doel waarvoor we de organisatie ze heeft verzameld wordt als privacy risico vaak benoemd het niet compliant zijn en de kans lopen om een boete opgelegd te krijgen door de toezichthouder en dat dit leidt dit tot negatieve publiciteit. Bij het vaststellen van de privacy risico’s wordt de betrokkene (de klant, de medewerker, de patiënt) nog te weinig als uitgangspunt genomen. Een voorbeeld ter illustratie. Stel een sollicitant doet een psychologisch onderzoek voor een bepaalde functie. Hij geeft toestemming voor het verstrekken van het rapport aan de werkgever het psychologisch onderzoek belandtvervolgens in het personeelsdossier bij de direct leidinggevende.  De gegevens uit het psychologisch onderzoek dienen na een jaar te worden verwijderd maar dit vindt in de praktijk vaak niet plaats. Na drie jaar vertrekt de direct leidinggevende en gaan alle personeelsdossiers over naar de nieuwe leidinggevende. Deze leest de gegevens uit het psychologische onderzoek en heeft op grond hiervan een vooringenomen mening tegenover deze medewerker. De medewerker begint hierdoor met een  1-0achterstand bij zijn nieuwe leidinggevende.
In de PIA moeten niet alleen de privacy risico’s mee worden genomen van het oneigenlijke gebruik binnen de organisatie zelf die de gegevens verwerkt (een ‘bad case’ scenario) maar ook die ontstaan als gevolg van een datalek (een ‘worst case’ scenario). Als de gegevens van het psychologisch onderzoek van de medewerker op straat komen te liggen, kan dit zijn positie ernstig schaden. De gegevens kunnen uit hun context worden gehaald, eventuele compenserende beoordelingen of gevolgde trainingen die intern wel bekend zijn extern niet bekend, et cetera.
Dit betekent dan ook dat expliciet de vraag moet worden gesteld “Wat is het risico voor de betrokkene als de verwerkte persoonsgegevens worden gelekt?” In principe zou je voor elk dataveld/categorie aan datavelden de ‘bad case’ en ‘worst case’ scenario’s moeten bedenken en mitigerende maatregelen moeten bedenken. Als het risico in geval van een datalek enorm groot is gelet de aard van het gegevens dan zou je als organisatie moeten afvragen of je die gegevens wel zou moeten willen verwerken, of dat je niet met minder persoonsgegevens kunt (dataminimalisatie), of dat je identificerende gegevens gaat vervangen door een versleuteld gegeven (pseudonimiseren), et cetera.

Conclusie
Om te voorkomen dat de meldplicht datalekken een formaliteit wordt in plaats van een middel voor organisaties om de persoonsgegevens beter te beschermen en de schade van eventuele datalekken voor de betrokkene te minimaliseren dienen organisaties het doel van de meldplicht steeds voor ogen te houden. Hierdoor kan een lerende privacy & security organisatie ontstaan en laat de verantwoordelijke (organisatie) zien dat zij de (privacy)belangen van haar klanten, patiënten, burgers, etc. serieus neemt. De IT-professional heeft hier een belangrijke rol in. Hiermee wil ik niet zeggen dat je niet aan de eisen uit artikel 34a Wbp hoeft te voldoen maar wel dat de meldplicht meer is dan alleen het melden om compliant te zijn.
Op de vraag of je met een PIA een datalek kunt voorkomen kan geen volmondig “Ja” worden gegeven. De kans op een datalek kan wel (beter) worden voorkomen door bij het vaststellen van de privacy risico’s de risico’s van betrokkene als insteek te nemen en niet de risico’s van de organisatie (boetes/negatieve publiciteit). Daarnaast dient bij het bepalen van de risico’s een niveau dieper te worden gegaan. Het team dat PIA uitvoert moet niet alleen nadenken over privacy risico’s voor de betrokkene die worden veroorzaakt door de organisatie (‘bad case’) maar ook expliciet over de privacy risico’s voor de betrokkene die worden veroorzaakt door een datalek (‘worst case’). Ook hier geldt dat het uitvoern van een  PIA niet als instrument moet worden gezien om de organisatie compliant te laten zijn voor de organisatie. Het is bedoeld om de privacy impact voor de betrokkene te bepalen en deze weg te nemen of te verminderen door mitigerende maatrgelen te treffen.

 

Auteur: mr. drs. Jeroen van Puijenbroek RE werkt als zelfstandig privacy adviseur voor PrivacySolutions4U. Van Puijenbroek geeft juridisch, IT en compliance advies gericht op de naleving van (privacy)wetgeving alsmede verricht hij interim werkzaamheden en audits op voornoemd gebied. Daarnaast geeft hij trainingen en is hij verbonden aan de Radboud Universiteit Nijmegen waar hij als extern promovendus onderzoek doet naar Privacy by Design. (J.vanPuijenbroek@PrivacySolutions4U.com)

 

 

 

[i]      Autoriteit Persoonsgegevens, “De meldplicht datalekken in de Wet bescherming persoonsgegevens (WbP): Beleidsregels voor toepassing van artikel 34a van de Wbp”, 8 december 2015.

 

 

[ii]     Richtlijn 2009/136/EG van het Europees Parlement en de Raad van 25 november 2009.

 

 

[iii]    https://autoriteitpersoonsgegevens.nl/sites/default/files/downloads/rs/r...

 

 

[iv]    Kits, P. en M Dankert, AG-Connect, nummer 2, augustus 2016

 

 

[v]     Wright, D., “The State of the art in privacy impact assessment”, Computer Law & Security review, 2012, 28: 54-61.

 

 

[vi]    Puijenbroek, J. van, “Privacy Impact Assesment en Privacy by Design – Wat de IT-professional moet weten”, De Informatie, nummer 6, augustus 2015.

 

 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag