Give staging data a fixed lifetime written in policy, then enforce it by schedule. For synthetic data a weekly or nightly reseed is common. For anything that came from real people, keep it as short as the purpose allows, with a named owner and a hard end date. There is no single correct number.
Why a lifetime beats good intentions
Staging data without an expiry only grows. Old bug reproductions, one off imports and half finished experiments pile up. When someone later asks what is in staging, nobody knows.
The GDPR's storage limitation principle says personal data should be kept in an identifiable form no longer than necessary for the purposes it is processed for. Its data minimisation principle says it should be adequate, relevant and limited to what is necessary. Both push toward short lifetimes. This is general information, not legal advice.
Choosing an interval
| Data in the environment | Suggested approach |
|---|---|
| Fully synthetic, regenerated from code | Reseed on a regular schedule, nightly or weekly |
| Synthetic plus hand made scenarios | Reseed, but keep scenarios in the seed script |
| Masked copy of production, approved exception | Short fixed period, delete at the end, record it |
| Real data, emergency debugging | Hours or days, restricted access, delete at closure |
Pick the shortest interval that does not stop your team working. If reseeding takes ten minutes and runs overnight, there is little cost in doing it daily.
Steps to put it in place
- Write the rule. One paragraph: what staging may hold, the maximum age of data, and who can approve exceptions.
- Tag data and environments. Tag each database and bucket with an owner and an expiry date. Untagged resources become a daily report.
- Automate the wipe and reseed. Run it from a scheduled pipeline job rather than a person's calendar. Include caches, queues, search indexes and object storage.
- Handle exceptions through tickets. Anyone who needs data to survive the refresh opens a ticket with a reason and an end date. The ticket goes on the evidence trail.
- Alert on age. A job compares the oldest record or the last reseed time with the policy, and alerts if the limit is passed.
- Align backups. If staging is backed up, keep those backups short lived too, or skip them for synthetic environments.
- Review periodically. Once a quarter, read the exceptions list and close the stale ones.
Reseeding without breaking people's work
Developers dislike losing their test accounts at random. Give them stable, documented fixture accounts that the seed script recreates every time, with the same logins and data. Announce the schedule, and provide a way to snapshot a scenario into the seed script.
Mistakes to avoid
- A policy that says "as short as possible" with no number or owner.
- Refresh jobs that drop the database but leave uploaded files.
- Keeping a long lived copy "as a baseline" with real data in it.
- Letting integrations store records on third party sandboxes that never refresh.
Quick check
Is weekly too often?
If the reseed is automated and fast, no. Frequent reseeding also proves your seed script works, which pays off when you need a clean environment in a hurry.
What about audit evidence of the schedule?
Keep the pipeline run history and the policy page. Together they show both the rule and that it runs.
Sources
Last reviewed: 19 October 2026.
