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

13 reacties

  1. het uitvoeren van tests en het herstellen van fouten in het abonneebestand concreet verband houden met de uitvoering van abonnementsovereenkomsten van particuliere klanten

    Hetstellen van fouten in het aboneebestand klinkt mij als data invoer foutjes herstellen, of misschien een bug oplossen in de applicatie m.b.t. de correctheid van het aboneebestand. Niet om te testen of nieuwe features in de applicatie wel fatsoenlijk werken en dat soort zaken. Voor het eerste lijkt mij een grondslag te zijn, maar voor het tweede niet?

    1. Terecht punt. Ik lees het breder, nodig is dat er een verband is met de dienstverlening oftewel met de applicatie die je inzet voor die dienst. Dus testen van nieuwe features daarin mag wel (dat gaat immers uitbreiding van de dienst worden) maar een AI trainen voor een heel andere toepassing mag niet, die valt buiten de dienstverlening met deze klant.

  2. Heb het arrest vluchtig bekeken, maar is er nog iets gezegd over een kwantitatieve limiet? Is het voor testdoeleinden echt nodig om álle (honderden/duizenden/miljoenen) klanten in de testset op te nemen?

    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…

    Zou het bij zo’n test-frequentie niet veel veiliger (en dus logischer) zijn de testdata steeds vooraf opnieuw te plaatsen (en na de test weg te gooien), in plaats van deze laten staan?

    1. Het Hof was niet gevraagd hoe het zit met kwantitatieve limieten dus daar hebben ze helaas niets over gezegd. Dit zou dan moeten volgen uit het aspect beperking, niet meer dan nodig. Dus wat is realistisch gezien echt nodig voor een test. Kun je met 10k in plaats van 100k records ook testen, dan is 10k dus de grens.

    2. Zou het bij zo’n test-frequentie niet veel veiliger (en dus logischer) zijn de testdata steeds vooraf opnieuw te plaatsen (en na de test weg te gooien), in plaats van deze laten staan?

      Inderdaad. Als bepaalde persoonsgegevens niet meer nodig zijn in de productiedata en daar verwijderd worden, dan zou het raar zijn als ze nog wel in testdata mogen achterblijven. Of is er een grondslag voor het bedrijf om deze oude data te blijven gebruiken om te testen? Er kunnen bijvoorbeeld weinig voorkomende namen tussen zitten die potentieel waardevol zijn voor de tests.

      1. De software die de test ondergaat is per definitie onbetrouwbaar. Dat betekent dat de te testen software gedurende een test de dataset op oncontroleerbare wijze veranderd kan hebben, waardoor de testdata niet meer geldig zijn als test-set. Je moet dus altijd vooraf de testdata opnieuw plaatsen.

        Ook betekent het, dat de testomgeving zoveel mogelijk geïsoleerd moet zijn, zodat er nooit door nog niet ontdekte fouten data naar buiten gaan of data in andere systemen ten onrechte veranderd worden.

      2. Dat zou inderdaad de rechtvaardiging zijn. Als je systeem weinig voorkomende namen zoals Thomassen à Thuessink van der Hoop van Slochteren moet aankunnen maar die persoon is onlangs vertrokken, dan lijkt het mij gerechtvaardigd dat je die naam in je testset aanhoudt als goed voorbeeld van een problematische naam. (Deze naam is niet verzonnen overigens.)

        1. Dit ben ik niet met je eens.

          De wettelijke onderbouwing voor het gebruik van persoonsgegevens als testdata (ZONDER expliciete goedkeuring door de personen in kwestie) is, als ik je blog goed begrijp, dat tests noodzakelijk zijn voor het kunnen leveren van de dienst (o.i.d) waar de persoon in kwestie WEL voor getekend heeft. Als de persoon vertrokken is vervalt dus, MET de grondslag voor het gegevensgebruik voor de oorspronkelijke dienst, OOK de grondslag voor het gebruik bij testen.

  3. Er zijn zat situaties waarbij testen met een kopie van een productiedatabase kritisch is voor het functioneren van de applicatie. Met name als er sprake is van een zeer diverse populatie die niet volledig getest kan worden in een beperkte testomgeving. Als je zeker moet weten dat de duizenden of zelfs tienduizenden verschillende combinaties van gegevens door een wijziging niet een onverwacht resultaat op leveren,

  4. Het zou me niets verbazen als die testen wekelijks, dagelijks of nog vaker herhaald worden. Bij een product waaraan continue wordt ontwikkeld worden zeer frequent allerlei testen automatich herhaald. Ook van de delen waaraan niets veranderd is.

  5. Ik heb zelf een standaard testset van persoonsgegevens die compleet fictief zijn. Deze gebruik ik al bijna 15 jaar en nooit problemen mee gehad, behalve dan dat ze steeds realistischer overkomen omdat ik er ondertussen ook diverse sociale-media accounts aan heb gekoppeld. (Die verder niets doen.) Het mooie hiervan is dat ik datalekken kan opmerken als een van deze persoonsnamen opeens ergens opduikt waar ik het niet verwacht. Regelmatig even via Google zoeken helpt daarbij om deze te vinden en de namen zijn vrij uniek dus een “false positive” komt niet voor. Het bijhouden van dit soort fictieve data is veel handiger, maar is wel weer een kleine investering omdat je deze wel bij moet blijven houden. En ondertussen zijn al deze fictieve personen alweer 15 jaar ouder en moet ik regelmatig weer nieuwe gegevens bedenken en toevoegen. Ik snap eigenlijk niet waarom bedrijven niet gewoon databases met fictieve data gebruiken voor test-doeleinden. Maar dat hangt veelal ook af van het soort data wat bijgehouden wordt. Maar als je een team testers hebt dan kunnen die vast genoeg fictieve data bij elkaar harken…

    1. Ik ben het 100% met je eens dat een aparte testdatabase met fictieve gegevens uit privacyoverwegingen veel veiliger is dan testen met (een deel va) de productiedata. Wanneer je met het testen op systeem acceptatie niveau aangekomen bent (de laatste stap voor productie) zijn er redenen om met productiedata te testen, je wil namelijk niet dat de gewijzigde applicatie het in productie spontaan laat afweten.

      Als je deze “finale” testomgeving goed inricht, met toegang voor slechts een kleine groep testers is het privacyrisico gering. En ja, je wilt je database met fictieve gegevens (voor de ontwikkelaars) uitbreiden, gebaseerd op probleemgevallen die in de systeemtest opduiken.

      1. Belangrijk is ook met deze fictieve data is dat je een datalek in het wild kunt opsporen, indien de namen uniek genoeg zijn. Iedere week even op Google zoeken naar de diverse namen in de database en dan zien wat er naar voren komt. Ook leuk is als er sociale-media accounts aan deze test-namen hangen omdat je dan soms recruiters krijgt met een aanbod voor de niet-bestaande LinkedIn gebruiker, terwijl de account toch duidelijk aangeeft dat deze niet benadert wil worden. 🙂 Ik heb veel interessante data kunnen verzamelen met deze nep-accounts en dan vooral over bedrijven die “stiekem” persoonsgegevens verzamelen en het Internet doorzoeken. Het bijhouden van fictieve namen is wel redelijk veel werk, maar dat heb ik er wel voor over. Maar, wat ook een optie is, de productie-database kun je door een anonimiserings-filter halen die alle persoonsgegevens vervangt met dummy data. Dat moet je dan wel weer bouwen, maar dan heb je een veilig systeem om te gebruiken voor test-doeleinden… Vraag is alleen hoeveel data je dan moet aanpassen…

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.