Het lijkt voor elke informatiebeveiliger en privacyspecialist logisch: niet testen met productiedata en zeker niet als die data privacygevoelig zijn. Toch gebeurt het nog elke dag en bij organisaties waarvan je ervan uit wilt kunnen gaan dat zij beter weten.
Wat is het probleem?
Productiedata zijn gegevens die dagelijks in systemen gebruikt worden voor de dienstverlening van organisaties . Deze data zijn actueel en mogelijk direct naar personen te herleiden. Er wordt een kopie gemaakt van deze productiedata en daarmee wordt getest. Dit gebeurt over het algemeen in minder beveiligde testomgevingen en niet in de draaiende productieomgeving. Een flink risico, zeker wanneer het persoonsgegevens betreft.
Met bovenstaande gang van zaken verwerk je als organisatie persoonsgegevens niet op de goede manier en overtreed je de AVG. Testservers zijn een dankbare plek voor criminelen om persoonsdata te stelen en vaak gebeurt dat ook ongezien, omdat veel testservers test/test als inloggegevens hebben.
Juridische context
Vanuit de principes van de AVG mag een organisatie alleen persoonsgegevens verwerken op basis van een grondslag en voor een specifiek doel. Daarnaast staat in de richtlijnen van de Autoriteit Persoonsgegevens ook: “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.”
De juridisch veiligste optie is dus om met fictieve data te testen en niet met productiedata. Dat is trouwens ook moreel de veiligste optie. Er is echter één maar. In de AVG staat niets wat expliciet het gebruik van productiedata bij het testen van informatiesystemen verbiedt. Daarmee is het juridisch mogelijk om te voldoen aan de AVG én te testen met productiedata.
Toch testen met productiedata?
Doe het niet. Maar zoals gezegd, als je het écht, écht wilt doen, kan het binnen de AVG wel. Wees gewaarschuwd: je zult er juridisch een kerstboom voor moeten optuigen! Dat begint bij een Data Protection Impact Assessment (DPIA). Daarmee kun je de voorgenomen verwerking: testen met productiedata in systeem x doornemen en juridisch formaliseren. Alle principes van de AVG zoals grondslag, doelbinding en dataminimalisatie komen in die context terug en zul je moeten vastleggen.
- De grondslag waarmee je de gegevens normaal verwerkt, is niet gekoppeld aan het testen met deze data. Dus zul je een nieuwe grondslag moeten vaststellen. Vaak wordt hiervoor gegrepen naar gerechtvaardigd belang, maar dit zul je enorm goed moeten onderbouwen, omdat er veel argumenten zijn tegen testen met herleidbare persoonsgegevens. In negen van de tien gevallen is het namelijk wel mogelijk te testen met fictieve data en dan ontbreekt een gerechtvaardigd belang. Wanneer je de persoonsgegevens verwerkt met toestemming, zul je apart toestemming moeten vragen voor het testen met deze gegevens. Betrokkenen kunnen die toestemming dus ook weigeren of alle toestemming voor verwerking intrekken, want je maakt geen betrouwbare indruk met deze vraag.
- Doelbinding is een ander belangrijk principe uit de AVG. Je mag van de wet gegevens die je voor een doel hebt verzameld, niet zonder meer gebruiken voor een ander doel, zoals testen.
- Dataminimalisatie is van belang bij het beperken van risico's. Gebruik alleen echte gegevens wanneer het echt niet anders kan en minimaliseer deze gegevens ook qua hoeveelheid in de testset. Heb je werkelijk de hele database nodig om te testen of kan het met een kleinere set? En heb je in dat laatste geval dan echt de productiedata nodig of kun je dit ook pseudonimiseren?
- Om de risico's te mitigeren, is het aan te raden extra aandacht te besteden aan beveiligingsmaatregelen: het wachtwoord kan dus niet meer test/test zijn! Beperk ook de toegang tot de testserver(s) en maak een goed plan om de data na testen te vernietigen.
Heb ik je ervan weten te overtuigen dat het beter is niet (meer) met productiedata te testen en wil je hulp bij het optimaliseren van je privacycompliance? Neem dan gerust contact met mij op!