Software testen met persoonsgegevens, mag dat nog

Hoewel de beleidsregels uitvoerig zijn omschreven, is het in de praktijk nog niet altijd even duidelijk hoe deze meldplicht werkt, wie verantwoordelijk is voor meldingen en aan welke voorwaarden moet worden voldaan. Een deel van de complexiteit zit hem simpelweg in de aard van het beestje dat ‘data’ heet; er zijn nu eenmaal nogal wat interne en externe partijen betrokken bij het verzamelen en verwerken van persoonsgegevens.

Dat geldt ook voor applicatieontwikkelaars; zij zijn niet de eigenaren van de data en in die hoedanigheid niet verantwoordelijk als er sprake is van een datalek. Dit betekent allerminst dat wij als ontwikkelaars deze wet- en regelgeving naast ons neer kunnen leggen. Als verwerker van persoonsgegevens mogen zowel onze klanten als hun klanten hoge eisen aan ons stellen als het gaat om het beschermen van de privacy.

Het risico op datalekken is er vanzelfsprekend op het moment dat een applicatie in productie is en persoonsgegevens worden verwerkt. Echter, ook in de ontwikkelfase van applicaties kan de meldplicht datalekken van toepassing zijn. Hoewel er in deze fase vaak gebruik zal worden gemaakt van dummy data of geanonimiseerde gegevens om een applicatie te testen, ontkom je er als ontwikkelaar niet altijd aan om te testen met een kopie van productiedata. Als het met deze data misgaat, hebben we eveneens een datalek te pakken.

In principe staat de Autoriteit Persoonsgegevens in de testfase alleen het gebruik toe van fictieve of geanonimiseerde gegevens of van persoonsgegevens die weinig risico met zich mee brengen. Het komt in de praktijk echter nogal eens voor dat een bug een datalek veroorzaakt dat alleen kan worden opgelost door gebruik te maken van (een kopie van) operationele persoonsgegevens. Denk aan een betalingsapp die weigert om overboekingen te doen op basis van een onjuist saldo of een verzekering die wordt geweigerd op basis van verkeerde gegevens. In dat geval kan het noodzakelijk zijn om te werken met een kopie van echte persoonsgegevens, terwijl dat officieel dus niet mag.

Hoewel de oorspronkelijke richtlijnen van de Autoriteit Persoonsgegevens hier geen rekening mee hielden, is er in de dialoog inmiddels ruimte gekomen voor een versoepeling. Onder strikte voorwaarden mogen ontwikkelaars inmiddels wel werken met persoonsgegevens die niet fictief of geanonimiseerd zijn, waaronder:

• Het doel van de test moet verenigbaar zijn met het oorspronkelijke doel waarvoor de gegevens zijn verzameld – dat is een van de essentiële privacy-beginselen. Nu wordt ‘het oplossen van een technische storing in het systeem’ over het algemeen gezien als verenigbaar door de Autoriteit Persoonsgegevens.
• De hoeveelheid persoonsgegevens die worden gebruikt om te testen moeten tot een onvermijdelijke proportie worden ingeperkt.
• Gezondheidsgegevens mogen niet worden gebruikt in een functionele testomgeving, alleen in een productieomgeving voor het oplossen van een datalek.
• Als er een beter alternatief is, dan mag er niet worden geanalyseerd of getest met persoonsgegevens (het subsidiariteitsbeginsel).
• Wellicht overbodig, maar voor het analyseren en testen met persoonsgegevens moeten passende technische en organisatorische maatregelen worden genomen.

Tenslotte geldt voor al deze punten dat er een zorgvuldige belangenafweging moet worden gemaakt: rechtvaardigt het doel (testen of analyseren) in dit geval gebruiken van privacy-gevoelige persoonsgegevens?

Het maken van deze afweging blijft mensenwerk, maar gelukkig is er inmiddels de ruimte om in bepaalde gevallen af te wijken van het verbod op testen met persoonsgegevens. Mooi, want het kan natuurlijk niet de bedoeling zijn dat de wet- en regelgeving op het gebied van privacy in de weg staan om mogelijke privacy-schendingen op te lossen.

Een inventarisatie door Nico Nijenhuis, functionaris Informatiebeveiliging & Privacy bij Info Support. Lees het artikel via AutomatiseringGids.nl of Informatie.nl.