Designing a retention policy that survives an audit

Most retention policies are written twice. Once as a sentence in a compliance document, and once — accidentally, years later — as whatever the backup tool happened to be configured to do. The audit finds the gap between them.

A policy that survives scrutiny is not a longer policy. It is one where the retention written down, the retention configured, and the retention you can prove are the same three things.

Start from the obligation, not the tool

Every class of data you keep is kept for a reason, and the reason sets the clock. Financial records answer to statutory retention, often six or seven years. Personal data answers to the opposite pressure: GDPR requires you not to keep it longer than the stated purpose needs. Operational logs are usually a security question — long enough to investigate an incident nobody noticed for months, which in practice means a year, not a fortnight.

Write the list before you touch a console: data class, why it is kept, how long, and who signs off on deletion. Four columns. If a class cannot be justified, that is a finding you get to fix quietly rather than one an auditor writes up.

Then map each class onto storage. This is where object storage earns its place — one bucket or prefix per retention class, so the rule is a property of where the data lives rather than a note in a runbook.

Separate the three questions

Retention conversations go in circles because three different questions get treated as one: how far back can we restore, how long must we keep evidence, and how quickly must we be able to produce it.

Restore depth is an operations question, measured in days and weeks. It is served by frequent copies you can reach in minutes. Evidence retention is a legal question, measured in years, and is served by far fewer copies that need to be complete and tamper-evident, not fast. Production speed is a discovery question — an auditor or regulator asking for a specific record within a deadline — and it is about the index and the naming scheme, not the storage tier.

Conflating them is expensive in both directions. Keeping nightly operational backups for seven years costs a fortune and answers no legal question well. Keeping only annual archives means a corrupted table from last Tuesday is unrecoverable.

What has to be beyond reach

The question an auditor asks that catches teams out is not how long you keep data. It is who can delete it early.

If the same credential that writes backups can also delete them, your retention is advisory. That is true for an insider and true for ransomware, which now routinely goes looking for backup credentials first. The control is boring and effective: the writing identity gets put and list permissions, not delete; a separate identity, used by nobody day to day, can remove objects; and where the requirement is strict, the objects sit under a lock that makes early deletion impossible for anyone, including the account owner, until the term expires.

Two more habits close the gap. Keep at least one copy in a different region, so a regional incident and a retention failure cannot be the same event. And keep the deletion log — what was removed, when, under which rule — as long as you keep the data itself. A policy with no record of enforcement is a claim, not evidence.

What longer retention actually costs

The instinct is to keep everything forever, because storage is cheap and deleting feels risky. Run the arithmetic before committing.

Take a database whose full backup is 400 GB, growing ten per cent a year, with daily incrementals of 20 GB. Keep thirty daily copies and twelve monthly copies and you are storing a few terabytes — a bill in the low tens of euros a month at flat object-storage pricing, and unremarkable. Extend the monthly copies to seven years and you are holding eighty-four fulls, tens of terabytes, and a bill that has grown by an order of magnitude to satisfy a requirement that probably only covers a specific subset of records.

That is the real optimisation: retain the record, not the whole system image. A yearly export of the tables under statutory obligation is a rounding error next to seven years of full-system backups, and it is far easier to produce on request.

The other cost to check before you sign anything is retrieval. Deep-archive tiers advertise a low price per terabyte and recover it on the way out, through per-request fees, minimum storage terms and egress charges. A policy that says produce records within five working days is incompatible with a tier whose restore takes twelve hours and bills per gigabyte read. Price the answer, not just the storage.

Prove it, on a schedule

Configuration drifts. Someone adds a bucket for a new service, and it inherits nothing. Once a quarter, list every bucket and prefix, check each one against the four-column table, and record the check. Restore one item from the oldest copy you claim to hold — an untested seven-year archive is a seven-year assumption.

The output of that quarterly hour is the thing that ends an audit conversation early: a current inventory, a rule per class, evidence of enforcement, and a restore you have actually performed.

The short version

Classify the data and justify each clock. Split restore depth from evidence retention from production speed. Make sure the identity that writes copies cannot delete them, keep one copy in another region, and keep the deletion log as long as the data. Retain records rather than whole system images for the long tail, price retrieval before you choose a tier, and re-verify quarterly with a real restore.

Antyxsoft object storage gives you lifecycle rules, scoped access keys and high durability on every object, with Veeam Backup and DRaaS for the long tail — see how object storage works.