The impact van GDPR op test data

Sinds de invoering van de Algemene verordening gegevensbescherming (AVG) – internationaal de GDPR (General Data Protection Regulation) – wordt er een hoop gesproken en gezegd over het gebruik van productiedata (met bestaande persoonsgegevens) tijdens het testen van software-applicaties, systemen en processen. We zijn in de afgelopen periode op zoek gegaan naar antwoorden op enkele door ons – maar ook door anderen – gestelde vragen. Die kennis brachten we terug naar de volgende vijf onderwerpen:

1. Kopieën van productie gebruiken voor testen en ontwikkelen van software

De AVG geeft alleen de kaders aan over dergelijke specifieke vraagstukken. De AVG kan dus niet worden beschouwd als een boek waar in staat wat wel of niet mag. Wat wel in de AVG staat is dat je zorgvuldig moet omgaan met persoonsgegevens en met welke beginselen je rekening dient te houden. Hieronder zou je data maskering en grondslagen zoals gerechtvaardigd belang en toestemming kunnen scharen. De algemene strekking is wel dat productiedata niet zondermeer gebruikt mag worden voor testomgevingen. Vaak is dat namelijk ook helemaal niet nodig. En als het niet nodig is dan kun je wel stellen dat de AVG aangeeft dat er voldoende passende maatregelen op het gebied van toegang en beveiliging getroffen dienen te worden.

In de basis zijn de meeste mensen het er wel over eens dat je geen kopieën van productiedata zou moeten gebruiken voor testdoeleinden. Wat nog bespreekbaar is, is dat wanneer de software bijna naar productie gebracht wordt, dat je in een dergelijke omgeving misschien wel met productiedata kunt of moet werken om aan de laatste kwaliteitseisen te kunnen voldoen. Het gaat er dus om dat je goed kunt verantwoorden in welke fase je tegemoet kunt komen aan de zorgvuldigheidsvereisten, zonder daarbij in de kramp te schieten of teveel gegevens te gebruiken. Goed afwegen en verantwoorden is dus belangrijker dan een statisch ‘mag wel’ of ‘mag niet’.

Grote en complexe omgevingen maken het lastiger om test data te anonimiseren of in een meer generieke zin te beveiligen. Uiteindelijk is het bij de AVG een kwestie van afwegen, wat inhoudt dat risico’s worden afgewogen tegen de impact die het op de betrokkene en de organisatie heeft als het fout gaat. Wanneer organisaties vinden dat hun IT-landschap dusdanig complex is dat ze geen data anonimisering kunnen toepassen, dan zullen ze deze complexiteit goed moeten kunnen aantonen en moeten kunnen laten zien dat er optimaal aan zorgvuldigheid is gedaan. Gezien de huidige technische ontwikkelingen zal er een zeer sterke motivatie beschreven moeten zijn. De realiteit is dat niks doen eigenlijk geen optie is.

2. Toestemming vragen aan klanten om hun persoonsgegevens te gebruiken voor ontwikkeldoeleinden

Hoewel toestemming een geldige grond is om persoonsgegevens te verwerken, kleven er wel praktische bezwaren aan het gebruik ervan. Toestemming lijkt relatief makkelijk, maar er komt het nodige bij kijken. Toestemming van de betrokkene dient namelijk specifiek te zijn. Kortom: degene die toestemming geeft moet goed kunnen inschatten waar hij of zij toestemming voor geeft. Denk bijvoorbeeld aan het soort test (performance, applicatie, functioneel, etc.) waarvoor de gegevens worden gebruikt en gedurende welke periode. Een ander praktisch bezwaar is dat het technologisch lastig is om de groep mensen die akkoord is te selecteren en alleen deze groep in een testomgeving / database te plaatsen.

Verder zou er een gezond belang moeten zijn om als organisatie een goede datahuishouding te hebben en daarbij hoort niet dat aan klanten toestemming gevraagd wordt om hun persoonsgegevens te gebruiken voor test- en ontwikkeldoeleinden.

3. Het gebruik van een waiver als tijdelijke uitzondering

Een waiver betekent dat voor een specifiek software-ontwikkelproject er tijdelijk gewerkt blijft worden met productiegegevens in plaats van geanonimiseerde data. Dit is wederom geen oplossing die specifiek in de AVG besproken wordt. De AVG is regelgeving die erop toeziet dat gegevens zorgvuldig verwerkt en beschermd worden. Een tijdelijke uitzondering wordt in deze regelgeving niet besproken dus een waiver (ook tijdelijk) zal geen grondslag vinden onder de AVG.

4. Een test data set anonimiseren

Zoals eerder gesteld vind je in de AVG niet het antwoord of en hoe je test data moet anonimiseren. Deze beveiligingsmaatregel zal door de organisatie zelf moeten worden vormgegeven. Er is wel een opinie van de European Data Protection Board, voorheen bekend onder de artikel 29 Werkgroep. Deze werkgroep heeft een opiniestuk geschreven waarin toelichting wordt gegeven op een aantal technieken, zoals anonimiseren, pseudonimiseren van gegevens en aan welke voorwaarden dit moet voldoen. Dit opiniestuk is geschreven in 2014, maar daar wordt nog steeds naar verwezen en er wordt ook nog steeds gebruik van gemaakt.

Voordat er een keuze gemaakt kan worden voor één of meerdere van de bovengenoemde technieken, zul je als organisatie eerst moeten bepalen wat het doel van het anonimiseren is. Is het doel om een test data set volledig anoniem te krijgen? Of is het doel om maatregelen te treffen om te kunnen voldoen aan het privacy-principe ‘data maskering’? Of om een evt. datalek te voorkomen waarbij niet-geanonimiseerde data eenvoudiger te herleiden is? Als het doel is om een dataset volledig anoniem te krijgen, dan is dat een stevige uitdaging. Dat komt onder meer door spontane herkenningsgevallen. Deze zijn eigenlijk niet te voorkomen, ondanks alle goede anonimiseringstechnieken die er gebruikt worden. Als voorbeeld valt dan te denken aan gegevens als het hoogste salaris. Dit voorbeeld is met data generatie eenvoudig op te lossen, maar vaak zijn er meerdere van dit soort gevallen.

Kortom: afhankelijk van het doel om te anonimiseringstechnieken te gebruiken, zijn o.a. spontane herkenningsgevallen in meer of minder mate belangrijk. In de WP29 wordt ook gesproken over spontane herkenningsgevallen waarbij ook de ‘context’ belangrijk is: in welke context kan de gebruiker of de ontvanger van de data deze data gebruiken (of misbruiken)? Als de ontvanger eenvoudig spontane herkenningsgevallen kan ontdekken en deze informatie kan gebruiken, dan zullen er keuzes gemaakt moeten worden om dit risico te beperken.

Uiteindelijk kunnen organisaties met de AVG een juiste belangenafwegingen maken. Met de AVG ter hand kunnen beslissingen genomen worden hoe test data representatief te houden en tegelijkertijd de zorgvuldigheidsnormen vast te houden en ongeoorloofd toegang tot data te voorkomen. Het doel hoeft dus niet volledig anoniem te zijn.

5. Verwerker vs. verantwoordelijke

Uitgangspunt van de AVG is: de verantwoordelijke is verantwoordelijk voor persoonsgegevens. Dus wanneer een verantwoordelijk aan een derde vraagt om persoonsgegevens in bijvoorbeeld hun datacenter op te slaan, dan is de verantwoordelijk daarvoor verantwoordelijk. Dan rust de verantwoordelijkheid dus niet zomaar bij de verwerker. Maar er is enige vorm van nuance, want de verwerker (het datacenter in dit voorbeeld) dient wel de werkzaamheden zorgvuldig uit te voeren. De beveiliging en de uitvoering van de dienst dient op een redelijke wijze uitgevoerd te worden, daarvoor is de verwerker zelf verantwoordelijk. De verwerker heeft wel een beveiligingsplicht. Dergelijke verplichtingen worden opgenomen in een verwerkersovereenkomst.

Conclusie

Naar aanleiding van bovenstaande kan de vraag beantwoord worden in hoeverre organisaties onder de AVG gehouden zijn om test data te anonimiseren. Hoewel in de AVG het pasklare antwoord niet te vinden, is het wel de norm dat test data anoniem moet zijn. Een organisatie moet daarbij steeds een afweging maken om te bepalen of dat in een fase van het proces zo moet zijn. Als organisaties maatregelen kunnen treffen op het gebied van data maskering, dan dienen deze maatregelen wel getroffen te worden. Als data maskering in een bepaalde laatste fase in het testproces niet meer mogelijk is, dan zal daar een goede overweging onder moeten liggen. Er zijn gelukkig voldoende voorbeelden voorhanden om ook na anonimisering geschikte test data te verkrijgen.

Geïnteresseerd? Neem dan gerust contact met ons op!

Dit artikel is tot stand gekomen met medewerking van senior IT/ Privacy Jurist Marie-José Bonthuis van Privacy1. Marie-José (CIPP/E, CIPM, CIPT, FIP) helpt met haar collega’s verschillende klanten op het gebied van hergebruik van gegevens voor (wetenschappelijk) onderzoek, privacy assessments etc. Haar specialiteiten: privacy in ketens, blockchain en data science, anonimisering, synthetische data.