Using Real Customer Data in Test Environments: The UK GDPR Problem

Data protection · August 2026 · 7 min read

Copying production data into staging is processing personal data under UK GDPR. What the law actually requires, what the ICO has fined organisations for, and what to do instead.

"We just took a copy of the production database" is one of the most common sentences in software engineering, and one of the least defensible under UK data protection law.

*This article is general information for engineering teams, not legal advice. Talk to your data protection officer about your specific circumstances.*

The legal position, briefly

Under the UK GDPR and the Data Protection Act 2018, a name and address together are personal data. Copying them into a staging environment is processing, and processing needs a lawful basis under Article 6 and must satisfy the principles in Article 5 — in particular purpose limitation, data minimisation, and integrity and confidentiality.

The consent your customer gave to have their order delivered does not extend to their address being loaded into a developer's laptop database. Legitimate interests is difficult to argue when a synthetic alternative exists and costs nothing, because the balancing test asks whether the processing is *necessary*.

Article 32 requires security appropriate to the risk. Staging environments are, empirically, less well protected than production: weaker access control, no audit logging, shared credentials, dumps in object storage, copies on laptops. Same data, lower protection, is exactly what Article 32 tells you not to do.

And a breach in staging is still a breach. If personal data is exposed there, the 72-hour notification duty under Article 33 applies just as it does in production.

What actually goes wrong

The failure modes are boringly consistent:

A staging database is exposed to the internet with default credentials while someone debugs a network issue.
A test email run sends real messages to real customers, because the mail server was not stubbed.
An SMS test dials real numbers copied from production.
A database dump lands in a public bucket or a shared drive.
A developer takes a copy home, and the laptop is stolen.
A screenshot with real names goes into a public bug report or a conference slide.

None of these require a sophisticated attacker.

"We anonymised it" usually means "we pseudonymised it"

Replacing names but keeping addresses, postcodes and dates of birth produces pseudonymised data, which UK GDPR still treats as personal data. Full postcodes are especially identifying: a unit postcode covers roughly fifteen addresses, so postcode plus one more attribute frequently identifies a household.

Genuine anonymisation — where re-identification is not reasonably likely for anyone — is hard to achieve and hard to prove. Synthetic data sidesteps the argument entirely, because there is no data subject to re-identify.

What to do instead

Generate the data. Synthetic UK addresses with real postcode districts and fictional buildings exercise the same code paths as production data: postcode validation, address parsing, sorting, delivery pricing, label printing, character-set handling.

Keep production data in production. Restrict dumps, and if you must reproduce a specific bug with real data, do it in a controlled environment with named access, a time limit and an audit trail.

Make your test environment safe by construction. Point outbound mail at a catcher. Use telephone numbers from Ofcom's reserved drama ranges so an accidental SMS run cannot reach anyone. Use example.com addresses so email cannot escape.

Keep enough realism to be useful. Include the awkward cases: names with apostrophes and hyphens, addresses with no house number, long Welsh street names, Northern Irish BT postcodes, central London AA9A postcodes, buildings with names instead of numbers.

A migration that takes an afternoon

1. Add a seeding script that calls a synthetic generator instead of restoring a production dump. 2. Seed with a fixed seed so fixtures are reproducible. 3. Delete existing staging copies of production data and rotate any credentials that touched them. 4. Add a CI check that fails if a production dump path appears in your infrastructure code. 5. Write the change down in your record of processing activities — you are reducing scope, which is worth documenting.

Start with the bulk test data generator, which will produce a seed file in JSON, CSV or SQL in one request.