What Is Retention Policy Design?

Retention policy design is the practice of deciding how long each backup copy is kept, on which storage, and under what immutability rules — and doing it deliberately rather than by default. It determines which moments in time you can still return to.

The distinction that matters most is this: retention is usually treated as a compliance question, but it is decided by recovery. Regulators tell you the minimum you must keep. Ransomware tells you the minimum you can survive with. A policy tuned only to the first can leave you without a clean restore point when it matters.

What a retention policy has to balance

Every retention decision is a trade between four pressures that pull in different directions.

• Recovery need. How far back you might realistically have to reach to find an uncorrupted copy.
• Regulatory obligation. Statutory minimums for financial, medical or legal records, which vary by jurisdiction and data type.
• Cost. Every additional day of retention is storage you pay for, which is why placement across backup storage tiers matters as much as duration.
• Data minimization. Privacy regimes such as GDPR push the other way, requiring that personal data is not kept longer than necessary.

A workable policy states, for each data class, how long copies live, where they sit and whether they are immutable — rather than applying one blanket rule to everything.

Where retention policies go wrong

The common failures are structural rather than careless.

• Uniform retention for everything. One global setting means critical systems are under-protected while trivial data is expensive to keep.
• Retention shorter than dwell time. If clean copies expire before an intrusion is discovered, every surviving copy is already compromised.
• Immutability window shorter than retention. A copy kept for a year but locked for thirty days is deletable for eleven months, which is precisely the gap backup tampering exploits.
• Policy set in the backup application only. Application-level retention can be changed by anyone with console access; storage-level locks cannot.
• Never revisited. Data classes, regulations and threat timelines change; a policy written three years ago probably no longer matches any of them.

Designing for dwell time

Attackers commonly sit in an environment for weeks before triggering. That single fact should shape the policy more than any other.

• Retain past the discovery window. Keep enough restore points, far enough back, that at least one predates any plausible intrusion — and treat industry dwell-time figures as a floor, not a target.
• Keep granularity, not just duration. A year of monthly copies is not the same as a year that includes daily copies for the recent past; point-in-time recovery needs points close together.
• Match the lock to the retention. S3 Object Lock in compliance mode should cover the full retention period, so no account can shorten it.
• Align with the wider rule. Retention is how the immutable copy in the 3-2-1-1-0 backup rule stays available long enough to be useful.
• Prove the old copies still restore. Include aged restore points in restore testing, since those are the ones you will reach for after a late discovery.

Retention policy design and ARTESCA

Scality ARTESCA is backup-first object storage on standard servers, which makes longer, safer retention practical rather than expensive.

• Retention enforced at the storage layer. S3 Object Lock in governance and compliance modes, plus legal hold, applies the policy where the backup console cannot override it.
• Long retention at commodity cost. Running on standard servers means keeping more restore points online, instead of shortening retention to control spend.
• Granularity without a penalty. Efficient storage supports frequent restore points across long windows, so density and duration are not in conflict.
• Policy through your backup tools. Retention configured in Veeam, Commvault, Rubrik or Cohesity is enforced by ARTESCA underneath, with no parallel policy to maintain.

The result is a retention policy that holds even when the systems above it are compromised.

Retention policy FAQs

How long should we keep backups?

Long enough to outlast the time it would take to discover an intrusion, and at least as long as any regulation requires — whichever is longer. Work from the recovery scenario rather than the storage bill: the question is which moment in time you would need to return to, not how many days you can afford.

Does longer retention always mean better protection?

No. A long retention period with a short immutability window offers little, because the copies remain deletable. Duration only helps when it is paired with a lock covering the same period, meaningful granularity, and evidence that the aged copies still restore.

Can we shorten retention to save money?

You can, but model the consequence first: which restore points disappear, and whether any of them are the ones you would need after a late-discovered compromise. Cheaper tiering for older copies is usually a better lever than cutting the window, provided retrieval times still fit your recovery targets.

How does GDPR affect backup retention?

Data minimization limits how long personal data should be kept, which can conflict with long backup retention. Most organizations resolve this by documenting backup retention as a defined, time-bounded purpose and ensuring copies expire automatically — rather than attempting to delete individual records from immutable backup sets.