Je mag dus toch wél testen met productiepersoonsgegevens, mits je ze maar daarna weggooit

mohamedhassan / Pixabay

Goh, die zag ik dus niet helemaal aankomen: het Hof van Justitie oordeelt dat je wél je software mag testen met persoonsgegevens uit de productiedatabase. Mits je alles maar weggooit zodra je tests zijn afgerond. Dat bepaalde men onlangs (arrest C-77/21) in een zaak waarin een Hongaarse ISP (Digi) op de vingers werd getikt door de toezichthouder vanwege testdata laten slingeren, wat een datalek had gegeven.

Het is uiteraard een goed idee om software te testen alvorens je deze gebruikt, zeker wanneer die software persoonsgegevens gaat verwerken. Dergelijke software moet immers veilig zijn en voldoen aan de beginselen van privacy by design en privacy by default. Dat vereist een goede set aan testdata, maar die is vaak lastig te krijgen. Helemaal als je ook met de hele wereld rekening gaat houden (zie de bekende “Falsehoods about names“, welke verraste jullie het meeste?) omdat het enorm moeilijk is die variëteit zelf te verzinnen.

De Autoriteit Persoonsgegevens zegt echter dat het niet wenselijk is om dan gewoon een kopie van je productiedatabase te nemen en daarmee te gaan lopen testen:

Dat is niet aan te raden. Testen is een complex proces, waarvoor zorgvuldigheid en meerdere gescheiden omgevingen nodig zijn. Het testen met persoonsgegevens brengt namelijk risico’s met zich mee. … De mensen van wie u persoonsgegevens verwerkt, verwachten niet dat u hun gegevens ook voor testdoeleinden gaat gebruiken. Dat betekent onder meer dat u voor het testen een aparte grondslag moet hebben.
Dat eerste is zeg maar een “kijk nou uit” argument, wat juridisch te herleiden is tot de AVG-eis van adequate beveiliging (art. 32) en meer algemeen adequate processen om zorgvuldig met persoonsgegevens om te gaan (art. 24). Een risico is bijvoorbeeld dat je testsysteem dan mails gaat sturen naar de klanten in de database, wat die mensen opvatten als een echte mededeling. Of heel simpel dat er een Excel-bestand met de productiedatabase rondslingert op de desktop van de tester, die het vergeet te verwijderen. Of dat Excel-bestand komt ergens in een gedeelde map die dan onbeveiligd bij Amazon terecht komt. Niet handig, mag niet gebeuren, dus doe dat nou gewoon even niet. Fair enough.

Dat tweede is een juridisch argument. Dat mensen niet verwachten dat hun gegevens ook voor X worden gebruikt, is de vertaling van “doel X is niet verenigbaar met het oorspronkelijke doel” (art. 6 lid 4 AVG). En dat is een probleem, want dan is aparte toestemming (althans, een aparte grondslag) nodig en die is er eigenlijk niet.

Het Hof van Justitie zegt nu dat dat laatste iets te snel is:

[Het] beginsel van doelbinding [verzet] zich er niet tegen dat de verwerkingsverantwoordelijke in een voor het uitvoeren van tests en herstellen van fouten opgezette databank persoonsgegevens vastlegt en opslaat die eerder in een andere databank zijn verzameld en bewaard, wanneer die verdere verwerking verenigbaar is met de specifieke doeleinden waarvoor de persoonsgegevens aanvankelijk zijn verzameld, hetgeen moet worden bepaald aan de hand van de in artikel 6, lid 4, van die verordening genoemde criteria en van alle omstandigheden van het geval.
Dat komt neer op “het zou kunnen maar je moet goed nadenken”, waar we dus weinig aan hebben. Maar het Hof gaat verder:

Wat ten derde deze beoordeling betreft, moet worden opgemerkt dat het uitvoeren van tests en het herstellen van fouten in het abonneebestand concreet verband houden met de uitvoering van abonnementsovereenkomsten van particuliere klanten, aangezien dergelijke fouten negatieve gevolgen kunnen hebben ten aanzien van de contractueel overeengekomen dienst waarvoor de gegevens aanvankelijk zijn verzameld. Zoals de advocaat-generaal in punt 60 van zijn conclusie heeft opgemerkt, wijkt een dergelijke verwerking immers niet af van de legitieme verwachtingen van deze klanten wat het latere gebruik van hun persoonsgegevens betreft. Uit de verwijzingsbeslissing blijkt overigens niet dat deze gegevens of een deel daarvan gevoelig zouden zijn geweest of dat de aan de orde zijnde verdere verwerking ervan als zodanig schadelijke gevolgen voor de abonnees zou hebben gehad of niet gepaard ging met passende waarborgen. Het is hoe dan ook aan de verwijzende rechter om dit na te gaan.

Als het dus gaat om testen ten behoeve van verbeteren van de dienst waarvoor je de gegevens hebt verkregen, dan is het dus in principe wél gewoon verenigbaar om te testen met de productiegegevens. Mensen verwachten dat er af en toe geknutseld en verbouwd wordt aan hun dienst, en moeten snappen dat er dan soms getest wordt. Natuurlijk ontslaat dat je niet van je verantwoordelijkheid de test netjes en veilig uit te voeren, wat dus betekent dat er géén mailtjes mogen ontsnappen of dingen gebeuren die toch effect hebben op de productie-omgeving.

De reden voor de ingreep van de Hongaarse AP was een datalek, veroorzaakt omdat een test-database was blijven staan op een slecht beveiligde server waar een ethisch hacker deze aantrof. Dat mag natuurlijk niet gebeuren, en het Hof trekt daar een grens vanuit de opslagbeperking: zodra het testen klaar is, moet de testdata weg. (Natuurlijk, het kán dat je maandelijks test in plaats van eenmalig. Dan mag je dus de testdata blijven bewaren, mits je er natuurlijk voor zorgt dat deze niet voor andere doeleinden wordt gebruikt of op een openbare AWS blob komt.)

Arnoud

Wat moet ik doen als mijn klant me productiedata geeft om te testen?

Een lezer vroeg me:

Wij ontwikkelen enterprisesoftware voor klanten, en testen deze uiteraard ook. Meestal ontvangen we daarvoor de testdata van de klant en soms zit daar ineens productiedata tussen inclusief persoonsgegevens. Zijn wij daarvoor aansprakelijk onder de GDPR?

Het is uiteraard een goed idee om software te testen alvorens je deze gebruikt, zeker wanneer die software persoonsgegevens gaat verwerken. Dergelijke software moet immers veilig zijn en voldoen aan de beginselen van privacy by design en privacy by default.

Goede testdata is daarbij van belang, maar is vaak moeilijk te krijgen. Daarom zie je regelmatig dat er toch met productiedata wordt getest, dat is dan de enige bron van een grote hoeveelheid uiteenlopende data waarmee genoeg aspecten getest kunnen worden.

Handig, maar erg problematisch: je weet immers per definitie nog niet of de software veilig is en wel privacytechnisch dichtgetimmerd is. Daarmee neem je als bedrijf (de klant dus van de vraagsteller) een serieus risico op datalekken. Bovendien moet je met je wederpartij (zoals de vraagsteller dus) een verwerkersovereenkomst sluiten waarin je de omgang met deze data expliciet reguleert, en dat wordt vaak vergeten want “het is maar om te testen”.

Het ontwikkelbedrijf zou ik adviseren om expliciet in de overeenkomsten op te nemen dat er géén productiedata wordt geleverd en al helemaal niets waar persoonsgegevens in zit. Een anti-verwerkersovereenkomst, zeg maar. Stuurt de klant die dan toch, dan heb je in ieder geval een sterk argument dat dit niet de bedoeling was. Uiteraard moet je dat bij ontdekking wel melden en die data vervolgens meteen wissen.

Arnoud

Mag een werkgever wachtwoorden kraken?

password-salt.jpgEen lezer vroeg me:

Onze IT-afdeling heeft besloten dat security een extra aandachtspunt wordt en als onderdeel daarvan wil men middels rainbow tables en andere tools alle wachtwoorden uit het bedrijf eens gaan controleren. Ik heb daar moeite mee: ik gebruik sterke wachtwoorden maar bouw die wel op volgens een bepaald patroon, en als dat straks in interne documenten gaat rondzwerven dan schaadt dat juist de security. Mag de werkgever dit wel doen? Er zijn toch betere manieren om de beveiliging te versterken, zoals tweefactorauthenticatie.

Juridisch gezien denk ik dat hier weinig tegen te doen is. De werkgever bepaalt hoe het werk wordt uitgevoerd, dat is haast de definitie van werkgeverschap. Als hij vindt dat je wachtwoord zestien tekens lang moet zijn met maximaal acht letters, dan heb je maar zo’n wachtwoord te verzinnen. Wil hij geen tweefactorauthenticatie, dan zul je je daar als werknemer bij neer moeten leggen.

Het kraken van wachtwoorden om te kijken hoe sterk ze zijn, doet wat gek aan. Ik snap het wel: veel mensen hebben zwakke wachtwoorden, en met zo’n test kun je kijken hoe slecht je ervoor staat, om vervolgens draagvlak te creëren voor sterkere wachtwoorden of regels. Maar het kan vervelend zijn voor mensen die al een eigen, sterk wachtwoord hebben en zich nu verplicht zien een heel ander soort wachtwoord erop na te houden.

Ik weet alleen echt niet hoe je daar iets tegen kunt doen als werknemer. Dit is geen wijziging van je arbeidscontract of een schending van je grondrechten, en apert onredelijk kan ik deze actie ook niet noemen. Dat een andere oplossing sterker is (tweefactorauthenticatie) zie ik meteen, maar dat is echt de keuze van de werkgever. Ik zou dus niets anders weten dan het overleg aangaan en hopen dat de IT-afdeling inziet dat dat een betere besteding van het budget is.

Arnoud

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