Legal
Writing a Document Retention Policy You Can Follow
A policy that says 'keep everything for seven years' is easy to write and impossible to defend. The workable version names categories, periods, and a deletion mechanism.
Retention policies fail in two directions. Keep too little and you cannot evidence your own position when a dispute arrives. Keep everything forever and you have a growing liability: more to disclose in litigation, more to breach, and a harder time meeting deletion requests under privacy law.
Start from categories, not systems
Retention attaches to the kind of record, not the folder it lives in. Build a schedule by category and let each system inherit from it.
• Statutory records — company, tax and accounting, where the period is set by law.
• Contracts — typically kept for the term plus the limitation period.
• Employment records — with separate, usually longer, treatment for pensions and safety.
• Customer personal data — held only while there is a lawful basis.
• Operational and internal correspondence — the largest volume, usually the shortest period.
• Litigation and dispute files — retained on their own timetable.
Say when the clock starts
This is the detail that makes a policy operable. 'Seven years' means nothing until you say seven years from what: the end of the financial year, the termination of the contract, the last customer interaction, the closure of the matter. Without a trigger event the rule cannot be automated, and a retention rule that cannot be automated will not be applied.
A retention period without a defined trigger event is a sentence, not a rule.
Build the legal hold before you need it
When litigation is reasonably anticipated, routine deletion of relevant material must stop — and in some jurisdictions failure to stop it carries serious consequences. That means you need a mechanism that can suspend deletion for a defined set of records, quickly, and evidence that it was applied. Designing this during a dispute is far too late.
Make deletion the default action
If deletion requires someone to remember, nothing is deleted. Retention has to be implemented as a scheduled process with exceptions, not as an instruction people follow. Where automatic deletion is too risky to start with, automate the review — a monthly list of records past their period, sent to a named owner who confirms or holds.
Log what you destroyed
Keep a destruction record: category, volume, date, authority, method. It is short, it is cheap, and it is the difference between routine records management and an unexplained gap. The log itself should have a long retention period.
Test it once a year
Pick three categories and check that records past their period are actually gone — in the live system, in backups, and in whatever shadow copies have accumulated in file shares and mailboxes. Backups are where policies most often turn out to be aspirational.
Retention periods are set by law and vary considerably by jurisdiction, industry and record type. Use this as the structure and have the schedule itself set by qualified counsel for the places you operate.
The trigger-event point is the difference between a policy and a poster. 'Seven years' is unimplementable; 'seven years from end of the financial year in which the contract terminated' can be automated.
Backups are exactly where ours turned out to be aspirational. Live system was clean, and there were seven years of nightly snapshots holding everything we thought we'd deleted.