Retention policy design for email archives

A policy that says "mailboxes are retained for seven years" is not a retention schedule. It is a storage setting with a legal-sounding sentence attached: it cannot explain why seven, it applies the same period to a signed contract and a lunch arrangement, and it collapses the moment somebody asks for the reasoning.

What follows is the method we use. It is not complicated, but it requires the business to make decisions it would rather avoid, and that is the part that takes time.

Start from purposes, not from systems

Under the GDPR the constraint is storage limitation: personal data kept in identifiable form no longer than necessary for the purposes it was collected for. Paired with accountability, that means you must be able to show the reasoning, not merely assert it. Both point at the same unit of work — the purpose, not the container.

So the first exercise is classification. In practice it collapses to a manageable set of classes: accounting and tax correspondence; contract formation and variation; employment and HR matters; customer service records; operational and project correspondence; internal administration; and transient chatter. Most estates need between six and twelve. If you find yourself designing thirty, you are describing departments rather than records.

Attach a reason to every period

Each class gets four things: a period, the reason for it, the event the clock starts from, and the action at the end. The reason is the part most often omitted and the part that makes the schedule defensible. It generally comes from one of three places:

• A statutory obligation — national bookkeeping and tax law is the usual source, and periods differ meaningfully between member states.
• A limitation period — how long a claim could be brought, which for contractual matters typically means the contract term plus the limitation period rather than a flat number.
• Business necessity — a genuine operational need, stated honestly. "We refer back to project correspondence for about eighteen months" is a legitimate reason. "It feels risky to delete" is not.

The trigger event matters as much as the duration. "Six years" is ambiguous; "six years from the end of the financial year in which the transaction was recorded" is implementable. A schedule that cannot be turned into a rule an engine can evaluate will not be applied, whatever it says.

Capture at the transport layer

Retention design assumes the archive contains what actually happened. That means journaling — capturing messages in transit, before a user can act on them.

Periodically copying mailbox contents produces something different: an archive of what users chose to keep. For anything with evidential value that distinction is decisive, and it is not recoverable later — you cannot retrospectively journal mail that was deleted in 2023.

Legal hold overrides everything, and must be reversible

When a matter arises, affected material must stop being disposed of, whatever the schedule says. Three properties make hold work: it is scoped by query rather than by mailbox, it is logged with who placed it and why, and it can be released — with the release logged and disposition resuming.

Holds that are never released are the commonest quiet failure here. They accumulate, nobody remembers the matter, and after five years the organisation is retaining everything again — this time believing it has a policy.

Deletion has to be real

Removing an item from the index while it remains restorable from backup has not deleted anything, and an auditor will ask.

Treat backups and the archive as different systems with different jobs. Backups exist for recovery and should have short, fixed cycles; the archive exists for retention and disposition. Where a disposed item may still exist on a backup, write down the maximum interval before the last copy ages out, and make that interval part of the policy rather than an embarrassment discovered later.

Design for subject access from the start

An archive that can only be searched by mailbox and date range cannot serve a subject access request efficiently, and you will feel that the first time one arrives with a deadline attached. Index for retrieval by data subject, and distinguish clearly between material that can be erased on request and material retained under a legal obligation where erasure may lawfully be refused. Both answers need to be producible, with a record of which was given.

Getting the business to decide

The technical work is straightforward; the classification is not, because it requires people to state what they need. My method is a series of ninety-minute sessions, one per function, with a single question: what would you need to produce if someone challenged a decision made three years ago? That produces useful answers. "How long should we keep email?" produces "forever, to be safe" every time.

Then verify. Once a year, sample the archive: check that items which should have been disposed of are gone, and that items under hold are retained. Write it up with a date. That annual page of evidence is worth more in an audit than the policy document itself, because it shows the schedule is running rather than merely published.