Vier toepassingen waarin anonimiseren een rol kan spelen

Bij het beschermen van privacygevoelige gegevens doormiddel van anonimiseren denken we vaak aan situaties waarin deze gegevens uiteindelijk gebruikt worden voor onderzoeks- of analysedoeleinden. Toch zijn er nog meer toepassingen waarin anonimiseren een belangrijke rol kan spelen. Wij hebben de vier toepassingen die wij het meest tegenkomen voor je op een rijtje gezet!

Testen van software

Bij organisaties die een grote afhankelijkheid van hun softwareoplossingen hebben zien we vaak terug dat deze ook veel tijd besteden aan het testen van de betreffende software. Dit testen is vaak gericht op het functionele gebruik van de software en heeft natuurlijk als doel dat je als organisatie goed voorbereid bent voor de ingebruikname van de software (of een nieuwe versie).

Het testen vindt in veel gevallen plaats op een aparte test omgeving. Deze bestaat vaak uit een kopie van de productie omgeving zodat er zo “productie-like” mogelijk getest kan worden. Dat productie-like testen is van essentieel belang. Je wil bijvoorbeeld niet dat er iets fout gaat met de ingebruikname van een nieuw stukje software omdat er een verschil zat tussen de productie en test omgeving waardoor je de fout over het hoofd hebt gezien in het testproces.

In een dergelijke situatie wil je als organisatie natuurlijk ook dat de data zo productie-like mogelijk is en tegelijkertijd privacygevoelige gegevens beschermd zijn. Omdat het testen van software in de meeste gevallen niet onder het doelgebonden gebruik van persoonsgegevens valt, is het van belang de persoonsgegevens te beveiligen door ze te anonimiseren. Bij het toepassen van anonimiseren houdt je rekening met de testbaarheid van de persoonsgegevens op een zodanige wijze dat ze geen negatieve invloed hebben op testresultaten.

Een voorbeeld: het BSN-nummer is een nationaal identificatienummer, waarmee makkelijk een koppeling gemaakt kan worden tussen informatie uit verschillende bestanden. Onzorgvuldig gebruik van het BSN brengt daarom privacyrisico’s met zich mee. Bijvoorbeeld misbruik van persoonsgegevens en identiteitsfraude. Stel dat je een BSN-nummer anonimiseert door het compleet te verwijderen, maar de software voert geautomatiseerd een BSN validatie uit bij het inzien van klantgegevens. In dat geval zal de software mogelijk een foutmelding geven omdat het BSN-nummer verwijderd is. Die foutmelding zou weer kunnen leiden tot een onterecht testresultaat.

In dit voorbeeld wil je misschien juist het bestaande BSN-nummer vervangen voor een test BSN-nummer. In dit geval zal de validatie correct functioneren waardoor de test slaagt.

Opleiden en trainen van medewerkers

In het geval van specialistische applicaties zien we vaak dat organisaties nieuwe medewerkers eerst willen opleiden in het gebruik van de betreffende applicatie voordat medewerkers op productiegegevens mogen werken. Aangezien het verkeerd gebruik van dergelijke applicaties grote gevolgen kan hebben is dat ook zeker geen slecht idee, maar hoe zorg je dan dat die nieuwe medewerkers op een realistische manier opgeleid kunnen worden?

Net als in de test toepassing wordt er vaak een aparte omgeving opgericht die specifiek in het teken staat van opleiden en oefenen. Zo hebben de acties die de medewerkers in opleiding in een dergelijke omgeving doen geen impact op productie en kan er dus zonder risico geoefend worden. Maar ook hier komt de doelbinding weer om de hoek kijken, want het opleiden van medewerkers in het gebruik van een applicatie is vaak niet de reden waarom je persoonsgegevens in eerste instantie hebt verzameld. Daarnaast mogen medewerkers vaak niet alle data inzien wat mogelijk zorgt voor beperkingen in de trainingsmogelijkheden.

Een mogelijke manier om de privacygevoelige gegevens in de opleiding omgeving te beschermen is door deze te vervangen door specifieke opleidingsgegevens. Zo kun je vooraf gedefinieerde data inzetten die je zelf in de omgeving plaatst en waarop de trainingen en oefeningen gebaseerd zijn. Terwijl dit natuurlijk een goede aanpak is om ervoor te zorgen dat trainingen zo gestandaardiseerd mogelijk zijn kost het vaak buitengewoon veel tijd om goed in te richten en te beheren. Zo moet je bijvoorbeeld rekening houden dat je oefen data genereert voor alle functionaliteiten die gedurende de training voorbij komen en wil je vaak niet dat dezelfde gegevens door meerdere personen tegelijkertijd gebruikt wordt om problemen tijdens de training te voorkomen. Een ander belangrijk aandachtspunt is natuurlijk dat je heel zeker moet zijn dat alle privacygevoelige gegevens binnen een opleiding omgeving verwijderd zijn. Met name als er veel geoefend kan worden zouden nieuwe medewerkers per ongeluk op persoonsgegevens kunnen stuiten op het moment dat ze zelf ervaring met de software aan het opdoen zijn.

Ook voor deze toepassing is anonimiseren goed in te zetten door de bestaande persoonsgegevens in de opleiding omgeving te anonimiseren. Zo kunnen nieuwe medewerkers in alle vrijheid de applicatie verkennen en oefenen zonder dat er een risico bestaat dat er persoonsgegevens achter blijven. Daarnaast is het anonimiseren in de regel minder tijdsintensief dan voor iedere training een specifieke dataset genereren die gebruikt kan worden voor de training zelf.

Softwareontwikkeling

Een verdere uitbreiding op het testen van software is natuurlijk softwareontwikkeling. Tijdens de ontwikkeling van software spelen in veel gevallen dezelfde zaken een rol als bij het testen van software. De softwareontwikkelaar zal namelijk nieuw ontwikkelde functionaliteiten gedurende het ontwikkelproces willen testen en valideren zodat deze functioneren zoals gewenst.

Wat we vaak specifiek terugzien bij softwareontwikkeling is het gebruik van eigen gegenereerde gegevens die voor een specifiek doel opgesteld zijn. Zo heeft bijvoorbeeld een ontwikkelaar, die verantwoordelijk is voor het aanmaken van een klant, gegevens nodig om te kunnen testen hoe de ingevulde waardes gevalideerd kunnen worden voordat deze in de applicatie verwerkt worden. In veel van deze gevallen genereert een ontwikkelaar een eigen dataset met fictieve gegevens die gebruikt worden voor dergelijke doeleinden.

Maar ook softwareontwikkelaars willen het liefst zo productie-like ontwikkelen om te voorkomen dat er fouten optreden op het moment dat de software bij een klant gebruikt wordt. In veel situaties schieten zelf gegeneerde gegevens dan tekort omdat deze misschien niet de unieke eigenschappen hebben die zich wel voor kunnen doen bij het daadwerkelijk gebruik van de software. Zo zal een ontwikkelaar vaak gegevens gebruiken waarvan hij of zij zeker weet dat deze (juist niet) verwerkt kunnen worden. In de “echte wereld” zien we echter vaak dat gebruikers buitengewoon creatief kunnen zijn in het verwerken van gegevens, vaak op een manier welke door de ontwikkelaar niet initieel voorzien is.

Door geanonimiseerde gegevens te gebruiken kun je juist die unieke eigenschappen in stand houden (zo lang deze niet tot een directe identificatie leiden uiteraard) zodat deze bruikbaar zijn gedurende de ontwikkeling en je als ontwikkelaar al in een vroeg stadium deze kan verwerken.

Onderzoek en analyse

Organisaties verzamelen steeds meer gegevens en gebruiken deze ook steeds vaker voor onderzoek- en analysedoeleinden. Denk bijvoorbeeld aan het verzamelen en combineren van gegevens in een data warehouse.

In veel gevallen spelen persoonsgegevens een steeds grotere rol in de analyse van de gegevens. Zo willen organisaties bijvoorbeeld persoonsgegevens gebruiken om de kwaliteit van haar dienstverlening of producten te verhogen of om juist inzichten te krijgen die alleen zichtbaar worden op het moment dat er meerdere databronnen met elkaar gecombineerd worden.

Omdat deze analyses steeds belangrijker worden voor organisaties en de afhankelijkheid hiervan toeneemt groeit ook de vraag om de persoonsgegevens te beschermen die voor dergelijke doeleinden gebruikt worden. Anonimiseren is hier ook uiteraard een uitstekende oplossing maar de impact hiervan kan een grote rol spelen in de analyse- en onderzoeksmogelijkheden. Zo wil je in veel gevallen juist bepaalde relaties in stand houden. Bijvoorbeeld: stel dat je onderzoek doet naar het aantal inwoners in een postcode gebied. Als je deze data zou anonimiseren zou het zo kunnen zijn dat dit impact heeft op het aantal personen die een specifieke postcode heeft. Hierdoor zou je dus vanuit onderzoek oogpunt verkeerde conclusies kunnen trekken. Het is dus in deze toepassing van groot belang om goed helder te hebben wat je wil onderzoeken en analyseren en daar de anonimisering op af te stemmen. Zo zijn er anonimiseermethoden die het aantal personen in een postcode gebied gelijk kunnen houden terwijl de persoonsgegevens waar deze op gebaseerd zijn volledig anoniem zijn.

Een extra uitdaging die we steeds vaker terug zien op het gebied van onderzoek is het delen van gegevens tussen verschillende organisaties. Vanuit een onderzoek oogpunt zorgt dit ervoor dat je een veel completer beeld kan creeëren waarop je je onderzoek kan uitvoeren. Maar het is dan wel van belang dat de geanonimiseerde gegevens die vanuit verschillende aanleverende partijen aangeboden worden te koppelen zijn en eenduidig geanonimiseerd worden. Ook dit is mogelijk doormiddel van het pseudonimiseren van koppelvelden, maar dit vereist weer extra aandacht om ervoor te zorgen dat dit op een veilige manier ingericht wordt zodat de pseudoniemen zelf niet gebruikt kunnen worden voor een identificatie van een persoon.