Do not test pipelines on a raw copy of production. Use synthetic data for logic tests, a small masked subset for realistic shape, and a locked down staging area for the rare case that needs real values. Each copy of production personal data is another system you must secure, monitor and delete.
Why copies are the real risk
Production has access controls, monitoring and backups designed for it. A copy in a dev project has none of that, yet it holds the same people. Developers query it from laptops, notebooks cache it, and nobody remembers to delete it. Many data exposures start in a test environment.
Option 1: synthetic data
Generate rows that match the schema and the statistical shape you care about: value ranges, null rates, key relationships, odd edge cases. Synthetic data is best for unit tests and logic checks, because you can include nasty cases on purpose: empty strings, very long text, unicode, duplicate keys, late arriving events.
Limits: it will not reproduce every real world oddity, and poorly generated data can be unrealistically clean.
Option 2: masked subset
Take a small sample of production, and transform it inside the production boundary before it moves: drop direct identifiers, replace them with random surrogates, generalize dates and locations, and scrub free text. Then check the result with the same detection you use for personal data elsewhere. See how to find PII before you copy it.
Be careful about the word anonymous here. A masked subset can often still be linked, as covered in our piece on pseudonymisation.
Option 3: restricted staging with real data
Sometimes a bug only reproduces on real values. If so, use a staging environment with production grade controls, named people with access, logging, and a deletion date. Write down who approved it.
A simple rule set
- Default to synthetic. Ask for an exception to use anything else.
- Transform before you move. Masking after the copy means the raw data already traveled.
- Give every test dataset an owner and an expiry date.
- Block production credentials from dev environments, so a test job cannot read the real tables by accident.
- Include test fixtures in code review. A fixture file with real looking emails deserves a question.
Contract tests help
Where several teams share a table, write a schema contract and test against it with generated data. You catch breakage without ever touching real rows.
Cleanup
Find old copies: list tables and buckets in non production projects by creation date and owner, and delete anything unowned. Add this to a quarterly review.
Where Safeguard fits
Safeguard offers policies and gates on pull requests, dependency scanning, and compliance evidence automation, which together help you show the process was followed. Free scan: https://gold.safeguard.sh/scan.
Quick check
When is a copy of production acceptable?
Only when a bug truly needs real values, and then in a restricted environment with production grade controls, named access and a deletion date.
Should masking happen before or after the copy?
Before. Transform inside the production boundary so raw values never travel.
Last reviewed: 19 October 2026.
