Prefer synthetic data for most tests, use masked data only when you need production shaped edge cases, and treat a subset of raw production data as production itself. Copying live personal data into a test environment moves the risk without moving the controls.
Why this matters
Test environments usually have weaker access control, wider developer access, and less logging. If real customer records land there, a leak from a laptop, a CI log or a shared staging database becomes a data breach. Regulations on personal data apply to a copy as much as to the original.
The three options
Synthetic data is generated from rules. It contains no real person. You control the shape, volume and edge cases.
Masked data starts from production and replaces sensitive fields with fake values, keeping structure and distributions. Quality depends on how thorough the masking is.
A subset is a smaller slice of production, often chosen to keep related rows together. Without masking it is still real data.
How to choose
- Unit and most integration tests: synthetic. Build small factories that make a user, an account and an invoice.
- Performance tests: synthetic at the right volume, or masked if your query plans depend on real skew.
- Reproducing a customer bug: reproduce with synthetic data shaped like the problem. Do not pull the customer's record.
- Analytics and model testing: masked, with a review of re-identification risk.
Masking mistakes to avoid
Masking one column is not enough. Combinations of birth date, postcode and job title can identify a person even when the name is gone. Free text fields such as notes and support messages often contain names, numbers and secrets that column rules miss.
Keep referential integrity, or tests break. Use consistent replacement so the same input always maps to the same fake value, but do not use a reversible scheme with a key stored next to the data.
Remember logs, backups and file attachments. Data hides in blob columns and in exported CSVs.
Make it routine
Put the data factory in the repository and review it like code. Add a CI check that fails if a test database dump or a fixture file contains patterns such as email addresses from real domains or card number lookalikes. Restrict who can restore production backups into any non production system, and log each restore.
Quick check
Is anonymized data outside privacy law?
Only if re-identification is not reasonably possible, and that is a legal and technical judgment. Weakly masked data often still counts as personal data. Ask your privacy lead or counsel for your case.
Can I use real data for a one time test?
Treat it as a production grade handling event with approval, access limits and deletion afterwards. Most of the time a synthetic equivalent does the job.
If you handle health records, see also the related post on PHI in test and staging environments at /resources/blog/phi-in-test-and-staging-environments-hipaa.
Last reviewed: 19 October 2026.
