Test data and GDPR: testing without copying production

Copying the production database to test a change or reproduce a bug is a common reflex. Under the GDPR, it is far from harmless: the copy multiplies the places where personal data is held and the people who can access it, and it often outlives the acceptance testing. The CNIL, the French data protection authority, recommends developing and testing on fictitious or anonymised data. This guide explains why, how to go about it, and what to plan for when a service provider works on the application.

It is aimed at CIOs, application owners and executives whose application processes personal data (customers, employees, users) and who have it developed or maintained, by their own team or by an application maintenance provider.

Why copying production to test is a problem

A copy of the production database installed on an acceptance-test server or on a developer’s workstation contains the same personal data as the original, but rarely the same protections: broader access, less logging, backups that nobody tracks. And it tends to stay in place long after the tests are over.

Three GDPR principles are at stake.

• Minimisation. Data must be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed” (Article 5). Testing a screen does not require customers’ real names.
• Data protection by design. Article 25 requires the controller to put in place, from the design stage, measures “such as pseudonymisation” to implement these principles effectively. Test environments are part of that design.
• Security. Article 32 requires the controller and the processor to ensure a level of security appropriate to the risk. An acceptance database filled with real data inherits that risk without having the protections.

The CNIL sums up the danger in its GDPR guide for development teams: using production database data for tests increases security risks, and may give access to the data to people who have no need to know it.

What the CNIL recommends

The CNIL’s guide to personal data security devotes a sheet to supervising IT development. For testing, its recommendations come down to four points.

• Develop and test in an environment separate from production: other machines, physical or virtual.
• Work on fictitious or anonymised data: “fictitious datasets must be used as far as possible”.
• If that data is not enough, test in pre-production with real data, in an environment “configured and secured to the same level as the production environment itself”.
• Only present a service or an update there that has already passed its unit, integration and functional tests in the development and test environments.

The CNIL’s GDPR guide for development teams points in the same direction. Its “Test your applications” sheet rules out real production data during development and testing, and advises building a set of fictitious data that resembles the data the application will process: if it is disclosed, the people concerned suffer no consequences. Failing that, test environments must receive the same security measures as production, and a configuration imported from production must be anonymised.

Fictitious, anonymised, pseudonymised: don’t confuse them

The three words do not mean the same thing, and the difference has a direct consequence: data that is genuinely anonymised falls outside data protection law, whereas pseudonymised data does not.

Definitions based on Article 4 of the GDPR and the CNIL. The “Use in testing” column is our summary of its recommendations.

Successful anonymisation can be checked. The CNIL uses three criteria.

• Singling out. It must not be possible to isolate an individual in the dataset.
• Linkability. It must not be possible to link distinct datasets together.
• Inference. It must not be possible to deduce, with near certainty, new information about a person.

In practice, deleting names and email addresses is almost never enough: a date of birth, a town and a profession can be enough to find someone. Free-text fields (comments, notes, attachments) are the hardest to handle, because they contain names, numbers and details of people’s lives. The CNIL also calls for ongoing monitoring: re-identification techniques are improving, and anonymisation judged sufficient yesterday may no longer be so.

Pseudonymisation is defined by Article 4 of the GDPR: the data can no longer be attributed to a specific person without additional information, kept separately. It remains reversible, and the data retains its personal nature. It is a good security measure, cited in Articles 25 and 32, not a way of escaping the GDPR.

Reproducing a production bug without copying the database

This is the situation where the temptation is strongest: a user reports an anomaly, it only occurs with their data, and copying the database seems the shortest route. There is almost always another way.

• Describe the case, not the person. What triggers the anomaly is a property of the data: an empty field, a special character, a deadline, a volume, a combination of options. It is noted in the ticket, without copying the user’s record into it.
• Rebuild the case with fictitious data. The test set receives a record that has the same property. It then joins the automated tests: the anomaly cannot come back without being noticed.
• Extract the minimum, anonymised at source. If some of the real data is indispensable, only the useful tables and fields are extracted, and they are anonymised before they leave the production environment.
• Diagnose on site, under control. When nothing else works, the analysis is done in production, or in a pre-production secured like it, by an authorised person, with traced access limited in time, rather than by moving the data out.
• Clean the logs. Error logs and traces sent to monitoring tools often contain personal data: they must be masked too.

These practices are not one more constraint: a case reproduced with fictitious data can be replayed at will, shared without precautions and tested automatically. It is also what makes tests reliable over time.

When a service provider develops or maintains the application

Consulting data is one of the processing operations defined by Article 4 of the GDPR. As soon as it accesses personal data on behalf of its client, a service provider that develops or maintains the application therefore acts as a processor. The contract governing it must contain the clauses required by Article 28, and the provider may not itself engage another processor “without prior specific or general written authorisation of the controller”.

For test data, five points deserve a line in the contract or its appendix.

• Access to production data: forbidden by default, or reserved for named people, for described operations.
• Test data: who provides the dataset, who builds it, and using which anonymisation method.
• Environments: where they are hosted, who accesses them, and how any pre-production is secured.
• Traceability: named, logged access, withdrawn when each team member leaves.
• The end of acceptance testing: destruction of copies, backups included, and proof that it took place.

One more point if the provider’s team works outside the European Economic Area (EEA): according to the European Data Protection Board’s Recommendations 01/2020, remote access from a third country to data located in the EEA is a transfer, to be governed by the tools of Chapter V of the GDPR. A team that only sees fictitious or genuinely anonymised data receives no personal data at all.

Our guide to the application maintenance contract details the other clauses to check, and the one on outsourcing your application maintenance covers what the company always keeps in-house.

At iones, this is the rule: no developer has direct access to production databases, and the teams work on isolated development and staging environments, with anonymised or test data (see your data security).

The checklist before each acceptance test

• The test set is fictitious or anonymised, and the method is written down.
• No direct identifier remains: name, email address, telephone number, postal address, customer or contract number.
• Free-text fields and attachments have been emptied or replaced.
• Logs and error-tracking tools do not receive real data.
• If real data is indispensable, the environment is secured like production and the decision is documented.
• Access is named and traced.
• The date for destroying copies, backups included, is set.

Frequently asked questions

Test data: a deliverable like any other

Not copying production is not one more constraint: it is what allows you to test often, to share a case without precautions and to entrust an application to an external team without exposing its users. The rule fits in one sentence: fictitious data by default, anonymised data when realism matters, real data only in an environment protected like production.

iones’ nearshore team provides application maintenance and testing for existing applications, with no direct access to production databases. You can also write to us for an initial conversation.