A good checklist covers eight areas: where test data comes from, how it is masked or generated, who can access staging, what the environment can send out, what its logs hold, which snapshots exist, how long data lives, and what proves deletion. Use it at every new environment and every quarter after that.
How to use this list
Treat each line as a question with a yes or no answer and an owner. A "no" becomes a ticket. The list is general guidance for software teams, not legal advice.
| Area | Question | Related post |
|---|---|---|
| Source | Is all test data generated or approved masked data, with no raw production copies? | Seed scripts |
| Generation | Is generation seeded and reproducible, with reserved example domains for emails? | Safe email domains |
| Masking | Is masking consistent across tables, with the key stored outside staging? | Keeping joins working |
| Risk | Have we checked uniqueness on combinations of fields? | Re-identification |
| Access | Do only current people and systems have staging access, with expiry on grants? | Who should have access |
| Credentials | Does staging use its own sandbox keys, never production ones? | Payment test cards |
| Outbound | Does staging mail, SMS and webhooks go to catchers or allowlists? | Stop emailing customers |
| Logs | Do logs hold identifiers only, with short retention? | Staging logs |
| Snapshots | Are snapshots inventoried, expiring and unshared? | Hidden snapshot copies |
| Previews | Are preview environments seeded from synthetic data and destroyed on close? | Preview environments |
| Retention | Is there a written lifetime and an automated reseed? | Staging data lifetime |
| Deletion | Do we keep a log and verification output for teardown? | Proving deletion |
| Third parties | Do contractors receive synthetic packages, not dumps? | Contractor handover |
| Incidents | Do we have a plan for real data in git or tickets? | Git fixtures |
Steps to run the review
- Pick one environment. Start with the one with the widest access.
- Assign an owner for each row. One person is accountable even if several do the work.
- Gather evidence. For each yes, link a config, a policy or a pipeline run. A yes without a link is a maybe.
- Record gaps as tickets with a priority. Weigh anything that exposes real personal data above the rest.
- Fix fast things first. Mail catchers, key separation and expiry dates are quick and cut real risk.
- Re-run quarterly. Calendar it. Environments drift.
- Keep the results. A dated checklist with evidence is useful in customer questionnaires and audits, where you can describe what you operate today without claiming more.
Where compliance frameworks touch this
Several frameworks ask about test data handling, change management and access control, for example in security questionnaires from customers. The checklist gives you true, specific answers. Keep wording to what you actually do, and attach the evidence rather than describing intentions.
Mistakes to avoid
- A checklist with no owners.
- Scoring "yes" because a policy exists, when the configuration says otherwise.
- Applying the list only to staging and forgetting developer machines and preview environments.
- Treating the first pass as the finish line.
Where Safeguard fits
Safeguard offers compliance and evidence automation alongside dependency scanning and SBOM, which can hold the evidence from reviews like this one. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Click through to see how a single dated checklist can map to more than one framework control.
Quick check
How long does a first review take?
For one environment, a few hours with the right people in the room. The slow part is usually finding who owns each system.
Do small teams need all fourteen rows?
Skim them all, then act on the ones that apply. A team with no previews or contractors can mark those not applicable and move on.
Sources
- GDPR Article 5, principles
- GDPR Article 25, data protection by design and by default
- GDPR Article 32, security of processing
Last reviewed: 19 October 2026.
