Vanaf 1 januari 2016 is het wettelijk verplicht om datalekken te melden. Wie data lekt of persoonsgegevens verwerkt zonder zich netjes aan de wet te houden, maakt kans op een boete. En geen kleintje ook. Deze boetes kunnen per overtreding oplopen tot € 820.000 of 10% van de jaaromzet. Geen wonder dat veel organisaties hun processen en systemen hebben aangescherpt. Toch is er een categorie processen en omgevingen die systematisch over het hoofd wordt gezien als het gaat om het gevaar van privacygevoelige datalekken: de testomgeving.
Testen is goed. Veilig testen is beter.
Laten we voorop stellen dat het geweldig is dat er bijna geen systemen en applicaties meer live gaan die niet eerst meer of minder uitgebreid functioneel getest worden. En terecht. Immers, een niet functionerende productieomgeving kan een organisatie grote schade berokkenen. De ROI van functioneel testen is daarmee al langer onomstreden. Maar dit geldt natuurlijk ook voor het gevaar van datalekken. Ook hierbij is het zo dat de gevaren met betrekking tot bedrijfsschade of reputatieverlies altijd al aanzienlijk waren. Het is echter pas nu, met de meldplicht-wet, dat daar ook een financieel tastbare component aan hangt. Veel organisaties hadden blijkbaar dit zetje nodig om hun privacy verder op orde te brengen.
Voor de productieomgeving althans, want in de praktijk blijken testomgevingen zich nog vaak te onttrekken aan de beveiligingsprocessen. De redenen zijn divers: vaak gaat het om gescheiden afdelingen, systemen en verantwoordelijkheden. De functionele tests vallen onder een testmanager, en een eventuele security officer heeft er dan weinig mee van doen. En omdat het niet om een live systeem gaat, zijn de risico’s niet erg groot, toch?
Kans op datalek bij testen extra groot
Dat is helaas een denkfout. Bij testen van systemen zijn vaak meerdere partijen betrokken, en bij allemaal is er een kans dat delen van het systeem en de informatie ‘lekt’. Dat hoef niet het gevolg van een gerichte hack te zijn, maar is veel vaker het aanwezig zijn van testdata op usb-sticks, schijven of in via het internet makkelijk toegankelijke directories. En dat zou nog niet zo erg zijn, als het om gegenereerde testdata ging, en niet om echte persoonsgegevens. Maar helaas is dit wél vaak het geval. Voor een snelle uitvoering van een zo realistisch mogelijke test, lijkt het werken met live productiedata de snelste weg. Dat zijn immers precies de data en formats waar het om gaat?
Quick? Ja! Dirty? Ook!
Gegenereerde testdata zijn beter
Quick and Dirty. Want de risico’s dat privacygevoelige gegevens uitlekken is opeens weer veel groter dan gewenst. En de wetgever onderkent dit ook. Testen met productiedata mag dan ook niet.
Maar net zo belangrijk: in heel veel situaties is het testen met productiedata helemaal niet beter of makkelijker of sneller dan het werken met special gegenereerde testdata. Zeker als er testautomatisering gaat plaatsvinden is het vanwege de voorspelbaarheid en onderhoudbaarheid van geautomatiseerde testscript juist beter om gebruik te maken van eigengemaakte en controleerbare testdata. Meer hierover in ons whitepaper.
Speciaal met het oog op het overlapgebied tussen compliance en testing hebben we aansluiting gezocht met Verdonck Klooster & Associates en gezamenlijk een heldere whitepaper geschreven over privacy-vriendelijk testen. Download hem nu.
Niet (alleen) vanwege het risico op lekken en boetes, maar vooral omdat u zó kwalitatief beter kunt testen.
