Elke keer als er een groot datalek in het nieuws verschijnt, stijgt het aantal vragen over testomgevingen. Terecht. Want een datalek in een testomgeving is net zo meldingsplichtig bij de Autoriteit Persoonsgegevens als een datalek in productie. Toch wordt de beveiliging van testomgevingen door veel organisaties een stuk minder serieus genomen. In dit artikel leest u wat de AP precies verwacht, welke risico’s er spelen en hoe u die structureel elimineert.
Wat zegt de Autoriteit Persoonsgegevens over testen met persoonsgegevens?
De AP hanteert het principe van dataminimalisatie: u verwerkt alleen persoonsgegevens die strikt noodzakelijk zijn voor het doel. Bij testen is het doel het valideren van processen en functionaliteit. Daarvoor zijn geen echte namen, BSN-nummers of salarisgegevens nodig. Fictieve maar realistische data volstaat volledig.
De AP stelt daarnaast dat persoonsgegevens alleen voor het doel mogen worden gebruikt waarvoor ze zijn verzameld. Medewerkers die hun gegevens hebben verstrekt voor salarisverwerking, hebben daarmee geen toestemming gegeven voor gebruik in een testomgeving. Daarvoor ontbreekt een geldige grondslag.
Concreet betekent dit: als u niet kunt onderbouwen waarom echte persoonsgegevens nodig zijn voor uw test, handelt u in strijd met de AVG. Ook al gaat het om een interne testomgeving.
Drie situaties waarbij AVG-risico’s het grootst zijn
Acceptatietests bij een nieuwe softwarerelease
Veel softwareleveranciers brengen meerdere releases per jaar uit. Elke keer maakt uw organisatie een acceptatieomgeving aan om de update te valideren. Als die omgeving een kopie is van productie, werkt u meerdere keren per jaar met onbeschermde persoonsgegevens buiten uw productieomgeving.
Onboarding en training van nieuwe medewerkers
Nieuwe collega’s leren een systeem kennen in een oefenomgeving. Als die omgeving echte medewerkersinformatie bevat, oefent iemand zonder zakelijke noodzaak met privacygevoelige gegevens van collega’s.
Implementatietrajecten met externe partijen
Bij het uitrollen van nieuwe modules of koppelingen werken externe consultants regelmatig in een testomgeving. Als die omgeving echte data bevat, deelt u persoonsgegevens met een derde partij. Daarvoor gelden aanvullende eisen rondom verwerkersovereenkomsten en verantwoording.
Waarom testomgevingen extra kwetsbaar zijn
Testomgevingen zijn doorgaans minder goed beveiligd dan productieomgevingen. Toegangsrechten zijn ruimer, logging is minder strikt en updates worden later doorgevoerd. Een incident met testdata is echter even meldingsplichtig als een incident met productiedata. De meldingstermijn bij de Autoriteit Persoonsgegevens is 72 uur na ontdekking.
Bovendien zijn testomgevingen een aantrekkelijk doelwit. Aanvallers weten dat de beveiliging er minder strak is, terwijl de data er net zo gevoelig kan zijn als in productie.
Hoe pseudonimiseren het risico structureel elimineert
Pseudonimiseren vervangt identificerende gegevens door fictieve maar consistente tegenhangers. Een medewerker krijgt een andere naam, een ander BSN en een ander adres. De structuur en samenhang van de data blijven intact, zodat alle systemen en processen gewoon werken in de testomgeving.
Het voordeel ten opzichte van anonimiseren: pseudonimisering is deterministisch. Dezelfde persoon krijgt bij elke run dezelfde fictieve identiteit. Testcasussen zijn daardoor herhaalbaar, ook na een nieuwe release.
Voor organisaties die werken met AFAS Profit is er een directe oplossing beschikbaar. DataFactory4AFAS is native ingebouwd in de standaard AFAS omgevingswizard en pseudonimiseert testomgevingen automatisch tijdens het aanmaken ervan. Geen apart systeem, geen implementatietraject. Meer informatie via entrd.nl/datafactory4afas.