After GDPR, is it still OK to perform testing with personal data?
GDPR is about protecting the personal data of EU citizens. The regulation will be fully enforced in May 2018, and it protects all personal data that can identify an individual. If an organization fails to comply, it faces the risk of lost reputation and sanctions.
In many companies, development teams play around with data from real production environments. Often, this data originates from customer databases.
It is tempting to use real data instead of purely synthetic data: It is the fast lane to acquire data for testing purposes. It might also reduce the potential number of bugs related to differences between testing and production environments.
However, testing with real data has always involved issues over information security and privacy. What is new is that going forward, GDPR requires specific attention to this practice. The reason is simple: All data that includes personal data is subject to GDPR compliance. It is forbidden to have personal data anywhere where it is not needed.
Test data may easily remain a blind spot in your preparations for GDPR. For solving the challenge, I suggest that you follow these four steps:
Like for the rest of your GDPR preparations, documenting the processing of personal data should be your first step. Remember to include backups, as well as eventual personal copies that testers have created for themselves. And don't forget the defect management systems!Be forewarned: This step might reveal uncomfortable surprises, such as dozens of different test environments and massive amounts of personal data in endless database tables.
To stay in control for the long term, you need a lean and adaptable process for your test data management. You should analyse and document where the real data comes from, and where it ends up to. This is important in order to ensure that no real personal data is exposed to software testers, test managers, business users, and other development team members during software development, maintenance and test phases.
While using synthetic data is preferable to real data, it is not always possible. If you decide that you can't avoid using real personal data in testing, GDPR doesn't mean you will automatically break the law. But there's a condition: Such usage requires data masking. It is critical to avoid any risks of exposing identities by traces left from real data.
GDPR requires that personal data should not be exposed for persons who are not authorized to handle it. Make sure testers, developers or infrastructure administrators don't have unnecessary access to personal data. Also ensure that those who need such access are aware of the rules regarding data usage.
Additionally, educate your developers, testers, analysts and business experts about GDPR and how it will change their work. Remember that preparing for GDPR should be seen more as an opportunity to improve than a necessary evil for compliance.
Also keep in mind that many other organizations struggle with the same problems. Have you got enough test data experts to solve them all in time?
To get more insight on making your test environments GDPR compliant download my practical guide. In it you can read when and how to use real or synthetic data, for instance.
Tuija has almost 20 years of expertise in product and tailored system development for several industries. Currently she is a unit manager with 50 quality assurance professionals in Finland and Sweden. She is curious about the best ways to improve the quality of software and is responsible of the Application Security testing area. Tuija is passionate about continuous improvement and simplifying ways of working.