Test data anonimiseren: een andere kijk op het realisatietraject

Door de nieuwe GDPR-wetgeving die op 25 mei 2018 ingaat, denken veel organisaties na over wat er moet gebeuren met de data die zij in non-productie omgevingen gebruiken. Veelal is de conclusie dat deze data geanonimiseerd moet worden om compliant te zijn.

Met deze conclusie krijgt de organisatie er een totaal nieuwe uitdaging bij. Want welke data ga je anonimiseren, op welke manier, en met welke tool? Het is een traject waarbij een goede afstemming tussen anonimiteit en bruikbaarheid noodzakelijk is en waarin elke organisatie anders is. Verrassend genoeg, kiezen veel organisaties toch voor dezelfde aanpak.

De keuze valt vaak op de aanpak per database

Iedere organisatie is anders, maar in de uiteindelijke realisatie van de anonimisering zijn de meeste organisaties verrassend eenduidig. Zij kiezen er bijna allemaal voor om dit traject per database op te pakken. Het grootste nadeel van deze aanpak is dat bij de anonimisering van de eerste database keten-inconsistentie ontstaat die niet zomaar verholpen is. De overige databases zijn immers nog niet geanonimiseerd. Dat betekent dat de testen, zoals ketentesten, waarvoor dit een vereiste is niet meer uitgevoerd kunnen worden. En dat gegeven is weer motivatie om deze vooralsnog niet uit te voeren tot in ieder geval de overige benodigde databases ook geanonimiseerd kunnen worden. Met andere woorden: dit leidt tot een big-bang aanpak. En dat staat haaks op het Agile gedachtegoed dat veel organisaties tegenwoordig geadopteerd hebben. Bovendien wordt er met deze aanpak bewust gekozen om niet te voldoen aan wet en regelgeving.

Op een andere wijze test data anonimiseren

Onlangs ben ik betrokken bij een anonimiseringstraject waarbij de organisatie een andere realisatiestrategie heeft gekozen, namelijk anonimisering per gegeven. Dat houdt in dat voor een gegeven wordt bepaald hoe deze geanonimiseerd moet worden en de realisatie van de anonimisering direct ketenbreed wordt geïmplementeerd. Dit heeft als groot voordeel dat direct een anonimisering wordt opgeleverd die ingezet kan worden. Dat sluit aan bij de Agile gedachte van veel klanten. Bovendien levert deze werkwijze - ongeacht het type softwarevoortbrengingsproces – een directe bijdrage aan de businesswaarde en het vertrouwen in de oplossing.

Voorbeeld: BSN-gegevens

Neem bijvoorbeeld het gegeven BSN. Er is voor dit gegeven geanalyseerd waar deze voorkomt in welke databases. De manier van anonimiseren is afgestemd tussen de verschillende partijen en er is een compromis gevonden tussen de verschillende belangen. De anonimisering wordt gerealiseerd en getest. Na goedkeuring is er een database beschikbaar waarin het gegeven BSN is geanonimiseerd en waarmee nog steeds ketentesten uitgevoerd kunnen worden. Vervolgens herhaalt de organisatie dit proces voor een nieuw gegeven, bijvoorbeeld alle velden die als adresgegeven dienen.

De uitdaging bij anonimiseren per gegeven

Per gegeven anonimiseren heeft dus zo zijn voordelen, maar elk voordeel bevat een keerzijde, een risico, en dus vallen er kanttekeningen te plaatsen bij deze werkwijze. Wat opvalt in de afwegingen tussen per database of per gegeven anonimiseren, is dat het vaak een afweging is in efficiëntie versus focus. Per gegeven anonimiseren geeft namelijk focus, aan zowel analyse als realisatie en het testen daarvan. Tegelijkertijd betekent het ook dat bij 10 gegevens je 10 keer dezelfde database doorgaat voor de analyse. En evenzo voor je overige projectactiviteiten, terwijl overhead nagenoeg hetzelfde blijft. Niet bepaald efficiënt dus. Anderzijds geldt dat bij het analyseren van de gehele database in één keer, de kans dat je een veld mist relatief groot is. Dit omdat je op alle gegevens typen tegelijkertijd moet letten. Er is onvoldoende focus, waardoor je de velden die je anders waren opgevallen, over het hoofd ziet.

Balans tussen efficiëntie en focus

De uitdaging zit in het vinden van de optimale balans tussen efficiëntie en focus. Dit valt goed te combineren met het Agile gedachtegoed om binnen een gedefinieerde periode van tijd, een werkend product op te leveren. In dit geval is het product een ketenbrede anonimisering. Een product dat groeit naar gelang meer gegevens onderdeel uitmaken van de anonimisering. Afhankelijk van het aantal databases, hoe vaak het gegeven voorkomt en de complexiteit van de benodigde anonimisering, kun je de impact en de benodigde tijd inschatten.

Daarmee is de basis gelegd om aan de hand van de prioriteit te kunnen bepalen wat onderdeel kan zijn van de eerstvolgende sprint. Ook hier geldt dat het werken in sprints regelmatige en kort cyclische feedbackloop over de te realiseren en gerealiseerde anonimisering met zich meebrengt. De geleidelijke realisering zorgt ervoor dat onzekerheid afneemt en binnen de organisatie een brede acceptatie ontstaat om met geanonimiseerde data te werken. Daarnaast ontstaat de mogelijkheid om ervaringen te delen en invloed uit te kunnen oefenen op het anonimiseringsproces.

Het resultaat

Onze ervaringen met deze wijze van anonimiseren zijn zeer positief. De eerste sprints lijken niet productief te zijn als je kijkt naar het opgeleverde resultaat. Maar juist deze sprints zijn essentieel voor de latere productiviteit, omdat deze de te hanteren werkwijze opzetten, evalueren en optimaliseren. Eenmaal uitgekristalliseerd, kan de realisatie op volle kracht plaatsvinden. Dit zorgt er tevens voor dat je er op enig moment voor kunt kiezen om de scope van een sprint qua anonimisering te reduceren in het voordeel van andere prioriteiten. Denk hierbij aan borging in de organisatie ten behoeve van beheer, zoals overdrachtsdocumentatie of opleiding van interne medewerkers. Hiermee zorg je niet alleen voor een optimale anonimisering, maar ook een optimale integratie. En wat de scope van een sprint ook mag zijn, aan het einde daarvan heb je altijd een consistent geanonimiseerde keten.

Hoe ga jij test data anonimiseren?

Weet jij al hoe je gaat zorgen voor een GDPR-compliant test dataset? Deel je mijn visie op het anonimiseren per gegeven of kiest jouw organisatie waarschijnlijk toch voor de aanpak per database?