Do not copy raw production personal data into staging, test or developer databases. Use synthetic data first, masked subsets when you need realism, and tight access with expiry as a last resort. Lower environments usually have weaker controls, so every copy widens your exposure and complicates deletion requests.
Why it keeps happening
Realistic data finds bugs. A developer takes a nightly dump, restores it to staging and moves on. Months later that database is shared with contractors, has a public endpoint for a demo, and is missing the patches production gets.
Article 5(1)(c) wants personal data limited to what is necessary for the purpose, and Article 25 asks for data protection by default. Debugging a layout rarely needs real names.
Option 1: synthetic data
Generate fake records with realistic shape: valid formats, plausible distributions, edge cases like long names and unusual characters. Seed them with a script kept in the repository, so every environment starts equal.
Strengths: no personal data, repeatable, easy to share. Weakness: it misses real world oddities, so add cases from bug reports by hand.
Option 2: masked production subsets
When you need real structure, such as a migration test against actual volumes, extract a subset and transform it before it leaves production:
- Replace direct identifiers with generated values.
- Keep referential integrity so joins still work, using a consistent mapping.
- Remove free text fields, which hide personal data.
- Generalise dates and locations.
Run masking inside the production boundary and ship only the masked output. A masked dataset can still identify people when fields combine, so review it as you would any release. Treat it as personal data unless you have shown otherwise.
Option 3: controlled access to real data
Sometimes there is no alternative, for instance diagnosing a production only issue. Then:
- Use a time boxed, approved access path, not a standing copy.
- Work inside production or an equivalent isolated, logged environment.
- Record who accessed what and why.
- Destroy the copy when the task ends.
Rules to write down
- Production data does not leave production without approval.
- Staging has no real data by default.
- Scheduled restores to lower environments use the masked pipeline only.
- Developer laptops get synthetic data.
Detect leaks
Scan staging databases and object stores for patterns like email addresses and national ID formats. Findings tell you where process broke. Also check that deletion requests reach any lower environment that somehow holds real data, which is a reason to avoid having any.
Quick check
Is a masked copy still personal data?
It can be. If people can be re-identified by combining fields or with outside data, treat it as personal data.
Can we use production data in CI?
Avoid it. Use synthetic fixtures so pipelines carry no personal data and logs stay clean.
Sources
Last reviewed: 19 October 2026.
