Test data and GDPR: why a production database copy is not a test strategy
A copy of a production database can quickly fill a test environment with realistic records. On its own, however, it does not define which data the test needs, who may access it or when it will be removed. A test-data strategy makes those decisions deliberately and selects the smallest representative dataset that can verify a particular risk.
Why a convenient copy creates another problem
Production contains data for live operation, whereas a test has a narrower purpose: verifying a discount calculation, a schema migration or search performance, for example. Moving every customer, order and attachment may extend personal-data processing into a less protected environment even though the test does not use most of it. It also creates more exports, logs, screenshots and backups that are harder to inventory and remove.
The European Commission’s overview of GDPR principles explains purpose limitation, data minimisation, storage limitation, integrity and confidentiality. These principles do not translate into a simple technical rule such as “never use production data for testing”. They do mean that the controller should assess the purpose, necessary scope, legal basis, retention period and proportionate safeguards for its particular case. A technical procedure does not replace that assessment.
Anonymised, pseudonymised and synthetic data
These terms describe different situations:
- Anonymised data can no longer be related, in the relevant context, to an identified or identifiable person by means reasonably likely to be used. This is a high threshold and depends on context, available additional information, and the ability to link records or draw inferences from them.
- Pseudonymised data has direct identifiers replaced or separated, with additional information needed to attribute it to a particular person. This is a useful safeguard, but the data may remain personal data and remain subject to GDPR.
- Synthetic data consists of generated records intended to reproduce the necessary formats, relationships and distributions. It can reduce the need to copy reality, but the team should verify that the generator, its input samples or its output do not reproduce real people.
The EDPB distinguishes anonymisation from pseudonymisation by whether the link to an individual has been severed or merely made less direct. Replacing a name or encrypting an identifier does not, by itself, demonstrate anonymity.
How to design test data
1. Start with the test purpose. For each scenario, record which data properties affect the result: format, boundary value, language, item count, state history or a relationship between tables. This is part of a broader risk-based test strategy. A field that the test does not use need not enter the dataset simply because it exists in production.
2. Choose a proportionate source. Precisely generated cases are often sufficient for functional scenarios. For performance testing, you can create a large synthetic set with a similar distribution rather than identical records. If a migration or specific incident requires part of the production structure, use subsetting: a limited selection of rows and columns with a documented reason. The controller decides whether personal data may be used, acting through its designated processing owner. The data protection officer (DPO) independently advises and monitors compliance; involve legal and security specialists as appropriate.
3. Mask consistently. Masking transforms values to reduce the possibility of identification or unintended use. The same customer must still receive the same substitute key in an order, payment and complaint. Preserve referential integrity, uniqueness, allowed formats and important distributions; otherwise, a test may fail because of a masking artefact or, conversely, miss a defect. Inspect free text and attachments separately, as personal data is not confined to a column labelled “name”.
4. Isolate runs and provide a reset. A test should create the data it owns and remove it after the agreed period or return the environment to a known state. Separate accounts, tenants or namespaces reduce collisions between teams and prevent one run from reading another run’s records. The reset also needs to cover dependent queues, caches and search indexes.
5. Cover the complete lifecycle. Set access on a need-to-use basis, apply time-limited permissions and keep an audit trail proportionate to the risk. Retention is not only about the database: include exports, logs, reports, videos, screenshots and records in issue trackers. Define backup expiry and restoration procedures so that an old dataset is not made available again without control.
What you gain
A smaller, deliberately designed dataset limits the spread of unnecessary personal data while preserving the properties that the test actually needs. Isolation and a controlled reset improve repeatability; an inventory of access, copies, and retention periods supports technical and legal assessment. These measures do not, by themselves, demonstrate GDPR compliance, but they provide better evidence for a responsible decision.
What to check before the first import
The team should be able to answer five questions: What testing purpose does the data serve? Which fields and volume are necessary? Is the data genuinely anonymised, or is it still personal data, including pseudonymised data, and on what assessment is that classification based? Who can access it, and until when? Where will derived copies appear, and how will they be removed or reset?
Next step
Record the answers alongside the environment-generation or refresh process and review them regularly. A practical first step is to select one critical scenario, create a small synthetic dataset for it and measure which production characteristics it genuinely lacks. Only then add targeted subsetting or masking. This creates a repeatable test-data strategy. The controller remains responsible for the final decision and compliance; the DPO and legal advisers support it within their respective roles.