Meldplicht datalek en het Business Intelligence werkveld
Geschreven door Ronald Kubbe op 08-01-2016

Sinds 1 januari 2016 is de wetswijziging op de wet bescherming persoonsgegevens ingegaan, genaamd de meldplicht datalekken. 

Wat is een datalek eigenlijk?
Bij een datalek gaat het om toegang tot of vernietiging, wijziging of vrijkomen van persoonsgegevens bij een organisatie zonder dat dit de bedoeling is van deze organisatie. Onder een datalek valt dus niet alleen het vrijkomen (lekken) van gegevens, maar ook onrechtmatige verwerking van gegevens.

Het project
De afgelopen periode zijn wij tijdens één van onze projecten veel met deze wetswijziging in aanraking gekomen. In het programmaplan zijn randvoorwaarden en richtlijnen opgesteld voor het inrichten van de toegang tot de bestuurlijke informatievoorziening en wat er wel en niet 'getoond' wordt. In de loop van het project is meerdere malen het grijze gebied betreden omtrent privacy gevoelige informatie. Als voorbeeld BRP gegevens; de ontsloten applicatie geeft een totaal inzicht van de BRP gegevens van de klant en in dit voorbeeld ook van zijn of haar uitkeringsgegevens. 

Eén van de informatiebehoeftes was het inzichtelijk krijgen van de doorlooptijd van de uitkeringsaanvragen (tactisch niveau) en welke aanvragen te laat opgepakt dreigen te worden (operationeel niveau). 
Op het tactisch niveau krijgt de eindgebruiker alleen een geaggregeerde grafiek te zien met gemiddelde en optellingen. 
Op het operationele niveau kan de eindgebruiker als het ware inzoomen en tot op regelniveau inzien welke aanvraag uit de pas dreigt te lopen. Om direct bij te kunnen sturen was er vanuit operationeel niveau ook de wens om op regelniveau de behandelend medewerker en de betreffende klant zichtbaar te hebben. 

Het CBP heeft hier theoretische kaders voor, maar een direct antwoord of dit 'mag' wordt niet gegeven. De eindgebruikers kunnen immers al bij de persoonsgegevens, het wordt nu echter via een ander medium getoond.

In het eerder genoemde programmaplan is ook opgenomen dat er een brede toegang moet zijn tot de bestuurlijke informatie, waarin er groot belang wordt gehecht aan transparante informatie uitwisseling tussen de teams. Tevens is er in het programmaplan als randvoorwaarde opgenomen dat de omgeving eenvoudig te beheren zou moeten zijn. Dit betekent onder andere het inrichten van simpele/globale gebruikersgroepen, conform de brede toegang.

Consequenties
Uitgaande van de wetswijziging kan er niet voldaan worden aan de gestelde randvoorwaarden van het project. Er zullen dus wijzigingen moeten plaatsvinden op de reeds opgeleverde (deel) resultaten. Bovendien vraagt de wetswijziging om bijstelling van de. Wat betreft beveiliging is het in ieder geval van belang dat er een goed actieplan op de plank ligt als er onverhoopt toch een datalek optreedt. Beveiliging is immers nooit 100% waterdicht. 

Op het gebied van de toegang tot de bestuurlijke informatie moet er een complexere rollen structuur opgezet worden. 
Wie behoort tot welke gebruikersgroep en heeft rechten op welke vorm van informatie. Tevens moet er een log bijgehouden worden wie, wanneer, welk rapport inziet. Op deze manier maakt het log aan de ene kant controles, al dan niet op basis van steekproeven, mogelijk. Aan de andere kant dient het als naslagwerk in het geval van een lek. 
De toegang tot de informatie gaat samen met het detailniveau van de data. Het is dus belangrijk dat er ook bepaald wordt tot hoeveel informatie een gebruikersgroep toegang heeft. 

Coulance
Begin december zijn de definitieve richtlijnen gepubliceerd door het CBP. Direct heerste de vraag 'is drie weken niet te kort voor de adoptie van het nieuwe beleid?', gezien de wetswijziging 1 januari 2016 in is gegaan.
De IT-brancheorganisatie rekent daarom op coulance van het CBP in de handhaving van de wet.

Lessons learned en hoe nu verder
Er kan geconcludeerd worden dat er wijzigingen moeten plaatsvinden in het reeds opgeleverde en de randvoorwaarden moeten worden aangepast. De impact van de hierboven genoemde wijzigingen zal merkbaar zijn voor de eindgebruikers, maar deze staat in schril contrast met de mogelijke boetes door een data lek. Het is namelijk niet de vraag óf er een datalek gaat plaatsvinden, maar wanneer het gaat gebeuren.

Op basis van dit project kunnen de volgende adviezen gegeven worden:

• Maak een keuze welke data nodig is op detailniveau en bepaal of deze data te pseudonimiseren is en doe dit dan zo dicht mogelijk bij de bron (in het ETL proces bijvoorbeeld).
• Maak een keuze wie tot welke informatie toegang moet krijgen en zorg ervoor dat dit gelogd wordt.
• Verminder het kunnen downloaden van detaillijsten tot een minimum. Als deze “werklijsten” toch nodig zijn, dan is mijn advies om eerst in gesprek te gaan met de leverancier van de bronapplicatie en deze functionaliteit daar te verkrijgen en toe te bedelen aan een gerichte groep beheerders.

Zorg dat er in ieder geval wordt vastgelegd wie een lek meldt, wie er bij een lek geïnformeerd moet worden, welke acties ondernomen moeten worden om een lek te dichten en wie deze verantwoordelijkheden draagt.

In dit stuk is buiten beschouwing gelaten dat gebruikers screenshots kunnen maken of een rapport kunnen uitprinten. Naar mijn mening valt dat onder dezelfde gebruiksregels als de gebruikersapplicaties, gezien daar ook screenshots van gemaakt kunnen worden en in sommige gevallen werklijsten uitgeprint kunnen worden, waarop ook privacy gevoelige informatie staat. Hier moeten gebruiksregels en maatregelen voor opgesteld worden, als deze nog niet via het arbeidscontract of een integriteitsverklaring zijn bepaald.