Prove deletion with three artifacts: a teardown log tied to the job, a post run check showing the target tables, buckets and indexes are empty, and a dated record of who ran it and under which policy. Keep them alongside the pipeline run so they are easy to find later.
What counts as evidence
Saying "we delete test data" convinces no one. A reviewer wants something they can inspect. For test environments, the most useful evidence is mechanical and automatic, because people forget manual steps.
| Evidence | What it shows | Where to keep it |
|---|---|---|
| Teardown job log | The delete step ran, with a timestamp and job id | CI run history |
| Verification query output | Row counts or object counts are zero after teardown | Job artifact or log |
| Policy reference | Retention rule that required the deletion | Linked wiki or repository file |
| Exception record | Any dataset kept longer, with owner and expiry | Ticket |
Steps
- Define the deletion point. State when test data must be gone: at job end, within 24 hours, at the weekly refresh. Write it down once.
- Automate teardown. Make teardown a required pipeline stage that runs even when tests fail. In most CI systems this is an "always run" or "finally" step.
- Verify, then record. After teardown, run a check script that counts rows in the tables that held test data, lists objects in test buckets and queries search indexes. Print the results to the log, and fail the job on a nonzero count.
- Save the log with the run. Do not rely on a developer's screenshot. Retention of CI logs varies by platform and plan, so export the verification output if you need it for longer than the platform keeps it.
- Cover copies. List where else test data may sit: exports, laptops, attachments in tickets, backups. For each, name the deletion method or the point at which it expires.
- Sample audit. Once a quarter, pick three recent runs and check that the evidence exists and the check was meaningful.
Backups and snapshots
Deleting rows does not remove them from existing backups. State how long test environment backups are kept, and prefer not to back up ephemeral test databases at all. For a shared staging environment, document that deleted data persists in backups for a stated period and expires with them. The GDPR principle of storage limitation is the underlying idea: identifiable data should not be kept longer than necessary for its purpose. This is general information and not legal advice.
Mistakes to avoid
- Verification that checks the wrong environment, so it passes even when the target is full.
- Teardown that is skipped when a test fails, which is exactly when messy data appears.
- Keeping the proof but not the policy that required it.
- Treating a deletion request from a customer as a test cleanup. Customer erasure has its own process, and it should not rely on test teardown.
Try it yourself
Click through it at your own pace, or open it full screen. Click through the mapping to see how one piece of evidence can answer several framework controls.
Quick check
Do I need evidence for synthetic data?
Less. Synthetic data holds no real person's information, so deletion is housekeeping rather than a privacy duty. Evidence is still good practice if you run a SOC style review of cleanup controls.
How long should I keep deletion logs?
Match your wider evidence retention policy. Keep them long enough to cover your audit period, and no longer than you need.
Can screenshots count as proof?
They are weak. A job log with a timestamp and an automatic count is harder to dispute and easier to collect.
Sources
Last reviewed: 19 October 2026.
