Is testen met persoonsgegevens verboden of niet? Laat je de nuances weg, dan luidt het antwoord dat dat niet verboden is. Zoveel zegt de Autoriteit Persoonsgegevens. Zij stelt dat testen met persoonsgegevens niet aan te raden is, maar dus niet verboden. Onder welke voorwaarden mag het dan? Daarvoor moet een aparte grondslag zijn, en dat verbaast me.
Waarom zou er een aparte grondslag nodig zijn voor het testen? Wellicht als je iets geheel anders wilt gaan doen met de gegevens, ja. Maar in de meeste gevallen wil je eenvoudigweg testen of de primaire verwerking correct verloopt en dat daarbij geen fouten gemaakt worden die de belangen van de betrokkene schaden. Het testen is moeilijk te zien als de gegevens worden gebruikt voor een ander doel. De behoefte om te testen is juist onlosmakelijk verbonden aan het primaire doel. Dat zit hem in het woord ’testen’, je test ‘iets’, en dat ‘iets’ is de oorspronkelijke verwerking.
Overweging 49 uit de AVG komt ons hier tegemoet. Daar wordt gesteld dat testen van de veiligheid van de verwerking een gerechtvaardigd belang kan zijn van de verwerkingsverantwoordelijke. De overweging spreekt hier vooral van het testen van de beveiliging van de persoonsgegevens voor inbreuken van buitenaf. Grappig is dat voor het testen van de beveiliging eigenlijk nooit productiegegevens nodig zijn omdat je simpelweg Micky Mouse kan opvoeren als dossier en dan los kunt gaan met het testen van de beveiliging. De wens om te testen met echte gegevens is gelegen in de borging van een correcte verwerking. Worden uitkeringen bijvoorbeeld correct berekend? Vaak heb je veel productie-like-gegevens nodig om de variatie in gevallen die in de echte wereld voorkomt zo goed mogelijk te treffen.
Gegeven paard
Maar goed, overweging 49 geeft ons de hoop dat niet alleen security-tests maar ook tests op correcte integere verwerking een gerechtvaardigd belang van de verwerkingsverantwoordelijke kan zijn. Nu wil ik een gegeven paard niet in de bek kijken, maar het testen dient eigenlijk niet het gerechtvaardigd belang van de verwerkingsverantwoordelijke maar dient nog steeds uitsluitend het doel van de primaire verwerking. Die ben je namelijk aan het testen. Het testen van een verwerking zou onder dezelfde grondslag moeten vallen.
Het begrip testen in deze discussie verdient een verduidelijking. Over welke testen hebben we het? Stel, ik behandel aanvragen van klanten met ingewikkeld cijfermateriaal. Ik krijg van een leverancier een handig tooltje waarmee ik de ingewikkelde berekeningen kan uitvoeren. Ik pak een aantal van mijn dossiers en probeer de tool eens uit. Ik controleer of de tool tot dezelfde uitkomst komt als de handmatige aanpak. Ik ben dan aan het testen met echte persoonsgegevens en ook nog eens in productie. Iedereen zal echter begrijpen dat hier geen probleem mee is.
Sfeer
De crux in deze discussie is dus niet het testen. Het gaat er om waar er getest wordt en door wie. We verlaten de sfeer van de grondslag en komen we in de sfeer van de dataminimalisatie en afscherming. Ontstaan er grotere risico’s omdat nu ook ongeautoriseerden – ontwikkelaars bijvoorbeeld – toegang krijgen tot de gegevens? Dat zijn terechte zorgen. Vaak zullen functionele acceptatietesten uitgevoerd worden door acceptatietesters die zelf ook gevalsbehandeling doen; die al toegang hebben tot de gegevens in productie. Als de acceptatieomgeving hetzelfde beveiligingsregime heeft als de productie is heel goed te verdedigen dat testen in acceptatie is toegestaan.
In het onwaarschijnlijke geval dat deze vraag voor een rechter komt, is makkelijk te onderbouwen dat het testen volledig valt onder het primaire doel van de verwerking. Dat er een gerechtvaardigd belang is van de verwerkingsverantwoordelijke maar ook van de betrokkene van wie gegevens verwerkt worden. Onderbouw daarbij tevens dat het te bewerkelijk en duur om testdata te creëren. Ik zie uit naar de rechtszaak waarin dit bevestigd of ontkracht zal worden. Het zal wel even duren.
(Auteur Jan Jongenelen is adviseur informatiebeveiliging bij UWV.)
