Mag je systemen testen met productiedata met persoonsgegevens?

test-checkbox-lijst-vinkjeEen lezer vroeg me:

Bij mijn laatste klant kreeg ik te horen dat ik bij de update van hun software wel mag testen, maar alleen met nepgegevens. Het argument was dat hun klanten geen toestemming hadden gegeven voor gebruik van hun data voor testdoeleinden. Deed ik dat toch, dan zouden ze de boetes wegens datalekken op mij verhalen. Klopt dat?

Dat verhaal over toestemming en boetes wijst erop dat de klant denkt aan een overtreding van de Wet bescherming persoonsgegevens (Wbp). Natuurlijk staat daar nergens letterlijk in dat het verboden is om te testen met productiegegevens. Die wet zegt alleen dat je de gegevens mag gebruiken voor het doel waarvoor je ze hebt verkregen, en voor doelen die in duidelijk direct verband daarmee staan (art. 8 en 9 Wbp).

Het testen van de omgeving waarbinnen je persoonsgegevens wilt gaan gebruiken, lijkt mij zonder meer voldoende verband te hebben met het daadwerkelijk (productie) gebruik van die omgeving. Als er dus toestemming is voor het productiegebruik, dan ook voor validatie en acceptatie van de software die dat gaat doen.

Tegelijkertijd kun je je afvragen of het echt wel nódig is om te testen met productiegegevens. Als je gaat testen, werk je haast per definitie met een systeem waarvan je nog niet weet of alles goed zit. Je neemt dan dus het risico dat er ergens een lek zit, of dat er verkeerde dingen gebeuren met die gegevens. (Ik krijg elke maand volgens mij wel een abusievelijke testmailing van de een of andere, om eens wat te noemen.) Vanuit dat perspectief zou je het eigenlijk niet moeten doen.

Ik zou dus zeggen dat je waar je kunt nepdata moet gebruiken. Alleen bij die tests waar de echte data gebruikt móet worden, is dat toegestaan onder de Wbp. Ik denk dan aan zaken als “is de productiedata correct geïmporteerd” of “klopt de rapportage nu wel met wat we verwachten”. In die situaties is geen aparte toestemming van de klanten nodig.

Arnoud

8 reacties

  1. Persoonlijk doet het mij genoegen dat een organisatie zo secuur met klantengegevens omgaan. Zelf heb ik een decennium terug met een voorloper van het Landelijk EPD (electronisch patientendossier) te maken gehad, en ontdekte dat men naar mijn mening niet secuur genoeg omsprong met de gegevens en de toegang daarop.

    Echter als programmeur begrijp ik goed waarom je graag echte data gebruikt. Die is vaak veel beter dan gegenereerde data. Bijvoorbeeld echte namen van mensen zijn zo buitenissig, dat je die niet verzonnen krijgt. Denk dan aan Chinese namen, extreem lange of juist korte namen, dubbele (of geen) achternamen, meerdere tussenvoegsels enzovoort.

    1. Als echte data beter is dan je testdata betekent dat alleen maar dat je niet genoeg tijd aan de datageneratie besteed hebt. Als het over tijd gaat, hebben we het over kosten, en belanden we meteen bij de echte reden waarom men met productiedata test: geld.

  2. Een probleem met testen met productie-data is dat de ontwikkelaar dan ook een kopie nodig heeft van die productie-data! Immers, als het fout gaat wil je niet dat de originele data verloren gaat. En als de developer tot een ander bedrijf behoort dan het bedrijf dat de data verwerkt dan kunnen er gevaren optreden van werknemers die door deze prive-data gaan snuffelen! Plus, hoe krijg je de data veilig van de productie-site naar de ontwikkel/test site?

    Ik heb in het verleden veel gewerkt met financiele data, waaronder het werken aan een soort administratie-systeem van eigendommen van mensen met minimaal 50 miljoen euro op hun ‘bankrekening’. Dergelijke informatie is natuurlijk enorm gevoelig en daar wil je nooit risico’s mee nemen. Ik ben dan ook in principe tegen het gebruik van echte klantgegevens tijdens testen of zelfs tijdens software ontwikkeling. Daar is ook geen noodzaak toe, mits de testers maar gewoon realistische scenarios aanhouden.

    Ik ga zelfs zo ver dat ik voor test-doeleinden enkele nep-accounts heb aangemaakt die in principe vrij realistisch overkomen maar verder volledig fictief zijn. (En ja, dat is inclusief sociale-media accounts en mailboxen!) Het voordeel hiervan is dat ik zo in de gaten kan houden wat er allemaal met deze data gebeurt, waar het terecht komt, dat het tijdens demo’s ook gewoon bruikbaar en realistisch overkomt zonder dat ik hiermee enige privacy schend. Want fictieve figuren hebben geen privacy, toch? 🙂

    Ja, het bijhouden van dergelijke testdata is wel extra werk en vereist ook de nodige onderhoud. Maar als je veilig om wilt gaan met persoonsdata dan zul je dergelijke acties gewoon moeten doen. Een beetje bedrijf zal dan ook gewoon de moeite moeten nemen om gewoon een lijst van test-accounts aan te maken en daarbij per account/fictief persoon een complete achtergrond bedenken. Hoe oud is de persoon? Welk geslacht? Lengte, breedte, gewicht, huwelijkse staat, beroep, woonplaats, en ga zo maar door. En iedere account moet ook een normaal ogende naam hebben want een naam als “Test Test1” wil je niet in je data hebben. Gegevens goed bijhouden en dan kun je intern ook gewoon praten over al deze fictieve accounts zonder privacy-schendingen.

  3. Testen met persoonsgegeven lijkt mij juist niet in overeenstemming met het doel waarvoor je deze hebt gekregen. Bij dat laatste gaat het om gegevens die hebt gekregen omdat iemand bijvoorbeeld iets bij je heeft gekocht of een abonnement bij heeft afgesloten. Bij testen gaat het om het controleren of de software wel werkt zoals deze gespecificeerd is. Tussen deze twee terrein bestaat geen sterke verwantschap. Voor de levering van dat pakketje hoeven mijn persoonsgegeven niet gebruikt te worden in de test van de toekomstige software.

    Dat er een verwantschap bestaat tussen de productieomgeving en de testomgeving is evident, omdat de software van testomgeving verplaatst zal worden naar de productieomgeving. Maar het doel van testen is niet verwant met het uitvoeren van een overeenkomst, omdat het testen van software daar niets mee te maken heeft.

  4. Vandaar dat scramblers productiedata vrij snel kunnen omzetten in testdata toch? Als op 10.000 klanten in de productie-tabel voornaam, tussenvoegsel, achternaam, postcode, klantnummers, etc worden gehusseld is het in principe ook niet meer te herleiden tot een persoon. Krijg je testklanten met namen als Abdul Jansen uit Maastricht met postcode 5100 AA en Kees Timur uit Den Helder met postcode 6203 HG. Waarvan de losse velden afkomstig zijn uit 4 of meer andere klanten.

  5. De Ap stelt zich op het standpunt dat testen met productiegegevens niet is toegestaan behalve als het openbaar verkrijgbare informatie betreft. https://autoriteitpersoonsgegevens.nl/nl/over-privacy/persoonsgegevens/beveiliging-van-persoonsgegevens?qa=testen&scrollto=1 Nee, dat mag niet. Een organisatie die uw persoonsgegevens heeft, mag deze gegevens niet gebruiken voor een ander doel. Het testen van informatiesystemen mag alleen met fictieve (verzonnen) gegevens of met persoonsgegevens die weinig risico met zich meebrengen. Dat zijn bijvoorbeeld openbare gegevens, zoals van publieke websites.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.