Most retention policies are written before anyone checks whether the platform can apply them. Build the schedule from obligations, then confirm the labels exist.
There is a reliable sequence of events. Somebody downloads a retention policy template. It is edited to fit, approved, and filed. Two years later an auditor asks for evidence that records are being deleted on schedule and the honest answer is that nothing has ever been deleted.
The policy was not wrong. It was simply never connected to anything that could carry it out.
Start from the obligation, not the preference
The practical consequence of that ordering is that most categories have a defensible answer available in an afternoon of research, and the arguments only start in the bottom two layers.
Where the argument usually lands: legal wants longer because of limitation periods, operations wants longer because the data might be useful, and nobody in the room represents the cost and risk of keeping it. Somebody has to make that argument, because data you hold is data you can lose, data you must produce in discovery, and data you must include in a subject access response.
The default should be the shortest period your obligations allow, with longer retention requiring a stated reason.
Organise by category, not by system
This is the structural decision that determines whether the policy is usable.
A schedule organised by system ("SharePoint: seven years") is meaningless, because every system holds several categories of record with different obligations. A schedule organised by category works, because the category is what the obligation attaches to.
Six to ten categories is enough for most organisations:
- Client and matter files
- Contracts and commercial agreements
- Finance and tax records
- HR and personnel records
- Marketing and prospect data
- Operational logs and system records
- Internal correspondence
- Board and governance records
For each, record: the retention period, where it comes from, what triggers the clock to start, who owns the category, and what happens at the end, meaning deletion, anonymisation or review.
The trigger matters more than people expect. "Seven years" is ambiguous. Seven years from creation, from the end of the relationship, or from the end of the tax year are three different schedules.
Confirm it is enforceable before you approve it
Before the policy goes to approval, take each category and answer: which system holds this, can that system apply retention automatically, and how does the system know which items are in this category?
That last question is where most schedules fail. A platform can apply a seven-year label to a SharePoint site, which works if the site contains one category of record. It cannot read a document and decide it is an HR record rather than a contract. So either your information architecture aligns with your categories, or somebody is applying labels by hand, which means it will not happen.
The usual resolution is to redesign the containers so that each one holds a single category. That is a real project, and it is better to know that at the point of writing the policy than two years later.
Email, which is the hard one
Email is the category where almost every organisation has a policy that is not applied, because email contains every category of record simultaneously and users will not file it.
Three positions, each defensible:
Delete everything after a fixed period, commonly one to three years, with instructions that anything needing longer retention is filed in the system of record. This is clean, defensible, reduces discovery exposure, and is unpopular with staff on the day it is announced.
Keep everything indefinitely. Simple, increasingly expensive, and it means every piece of litigation involves searching a decade of mail.
Let users apply labels. Appealing in theory. In practice adoption is low, the result is inconsistent, and inconsistent application is worse than a blanket rule because it is unpredictable.
Most organisations that think about this properly end up at the first, with a defined exceptions process. The announcement needs care, a long notice period, and a clear explanation of where things belong instead.
Legal hold overrides everything
When litigation is reasonably anticipated, retention stops for the relevant material. Deleting on schedule after that point is a serious problem, and "the policy did it automatically" is not a defence.
So the policy needs a hold process: who can trigger it, how it is applied across each system, how it is documented, and who releases it. Test that you can actually apply one. In most platforms this is a specific feature with specific licensing, and finding out it is not enabled during a dispute is a bad afternoon.
Make deletion visible
A policy nobody can verify is a policy nobody trusts. Build one simple report: what was deleted under the schedule this quarter, by category and volume.
That report does two jobs. It proves the policy operates, which is the evidence an auditor wants. And it surfaces the cases where it is not operating, which is almost always more informative.
The document itself
Short. A page of principles, a table of categories, and an appendix with the process for holds and exceptions.
The table is the policy. Category, retention period, source of the obligation, trigger event, owner, disposal method. If a row cannot be filled in completely, that row is not ready and should be marked as under review rather than given a number that nobody can justify.
