Data retention policy: deciding what to keep and for how long

A data retention policy states what information the business keeps, for how long, on what basis, and how it is disposed of afterwards. It is unusual among policies in that its real subject is deletion — keeping things is the default that happens without a decision, and the policy exists to interrupt it.

Two costs push companies to write one. The obvious one is legal: in most jurisdictions you may not keep personal data indefinitely just because storage is cheap, and holding it longer than you can justify turns every breach into a larger incident. The less obvious one is operational: an archive nobody has curated is one nobody can search, so the company keeps everything and can find nothing.

What the policy must contain

• Scope: which systems and which categories of information, named specifically enough that someone can classify a file.
• Categories that match how you actually work — customer records, employee files, financial records, contracts, marketing lists, logs, backups — rather than an abstract taxonomy.
• A retention period per category, with the reason: a statutory requirement, a limitation period, a contractual term, or a business justification you can defend.
• Where each category lives. A period you cannot apply because nobody knows where the data is is a period on paper only.
• An owner per category — the role accountable for the data actually being deleted.
• The disposal method: deletion, anonymisation, or secure destruction for physical records.
• Backups, explicitly. They are the reason most deletion is incomplete, and pretending otherwise makes the policy untrue.
• Legal holds: how retention is suspended when litigation or an investigation is anticipated, and who can impose one.
• How deletion requests from individuals are handled, and by whom.
• An owner and a review date for the policy itself.

Do not invent retention periods. Financial records, employment records, tax documentation and health and safety records all have statutory minimums that differ by country, and personal data carries a separate obligation not to keep it longer than necessary. Get the list of periods from your accountant and, where personal data is involved, from someone who knows your jurisdiction's data protection law. This is one of the few documents where copying a template from another country is actively harmful.

Building it

1. Inventory first: list where information actually lives — the document store, email, the accounting system, the CRM, spreadsheets on laptops, paper in a cupboard. The last two are the ones policies forget.
2. Group into a manageable number of categories. Fifteen is workable; sixty is a taxonomy nobody applies.
3. For each category, find the longest applicable obligation and write it down with its source. Where several apply, the longest governs.
4. Where no obligation exists, set a period you can justify commercially and say so — "no statutory requirement; retained three years for reference" is a defensible entry.
5. Assign an owner per category, by role.
6. Decide the disposal method, and confirm it is actually possible in the system holding the data before writing it down.
7. Write the backup reality honestly: state your backup cycle and that deleted data persists in backups until the cycle completes.
8. Set a deletion rhythm — annually is enough for most categories — and diarise it, because retention that never triggers a deletion is not retention.
9. Review the policy annually and whenever a system or a rule changes.

The parts people get wrong

Backups are the first. A policy that promises deletion within thirty days while backups are held for a year is describing something that does not happen; the honest version states both and explains that restored data is re-deleted. The second is email, which is where most personal data actually sits and which almost no retention schedule addresses. The third is the assumption that deletion is a technical act — for paper, for laptops, and for anything a departing employee copied, it is a process problem, and the policy should say who checks.

In Ettex, the policy document lives in Ettex Docs with version history — which matters here, because "what was our stated retention in 2024" is a question that gets asked — and threaded comments while it is agreed. The schedule itself, with a row per category and columns for period, basis, location, owner and next deletion date, fits Ettex Records: typed fields, saved views, revision history and row comments. Deletion request intake works as a form in Ettex Forms, timestamped in one inbox, which is itself part of the evidence that requests were handled.

Plainly: Ettex has no retention automation. Nothing here expires documents on a schedule, applies legal holds, deletes data automatically, classifies files, or reports on what is overdue for deletion. The policy and the schedule are documents you maintain, and the deletion is a task somebody performs. Enforcing retention across many systems is what information-governance software exists to do.

How retention policies fail

• Periods copied from a template written for another country, so they satisfy no actual obligation.
• Categories too granular to classify or too vague to apply.
• No owner, so deletion is everybody's job and therefore nobody's.
• Backups unmentioned, which makes the deletion promise false.
• Email and laptops out of scope, which excludes most of the personal data you hold.
• No deletion rhythm, so the schedule exists and nothing is ever deleted.
• Legal holds undefined, so relevant data is deleted during a dispute — a much worse problem than keeping too much.
• Written once and never reviewed, while systems and rules change around it.

A data retention policy is a table of decisions: category, period, basis, location, owner, disposal. Get the periods from your jurisdiction rather than a template, be honest about backups, and diarise the deletion — otherwise the schedule is decoration.