Deletion fails because the individual incentive runs the wrong way
The downside of keeping something is diffuse; the downside of deleting something needed is immediate and personal. The rational individual choice is always to keep it.
Microsoft Purview · Public Sector
The cost of keeping everything
Most agencies have a documented retention schedule and delete nothing. The bill arrives with the next records request.
Abstract
The cost of keeping everything
Summary
There is a moment in every public records request where somebody realises the scope includes fifteen years of material that should have been disposed of a decade ago. The request is still valid, the material is still discoverable, and it all has to be reviewed.
This paper examines why retention schedules reliably fail to operate, argues that the disclosure cost rather than the storage cost is the real business case, and sets out how to design disposal so that no individual has to make the decision that nobody wants to make.
Key findings
Four things this paper argues
If you read nothing else, read these. The analysis that follows sets out the evidence for each.
Storage cost is the weakest argument and the one most often used
Disclosure scope is the argument that moves agency leadership, because it converts a compliance obligation into an operational cost they already feel.
Event-based retention matches how public schedules are actually written
Most series retain from case closure or contract end, not from creation. Calendar-based retention misapplies the schedule at scale.
Disposition review is what makes disposal defensible
A named reviewer and a timestamp answer the question 'why was this destroyed' in a way that 'the policy did it' does not.
Analysis
The argument in full
Why schedules do not operate
Applying a retention schedule requires a decision that nobody wants to make individually. Deletion is irreversible, the person who created the record has usually left, and the consequence of destroying something later needed lands on the person who approved it.
So the estate grows indefinitely, and it grows in a way that is invisible until a disclosure exercise forces somebody to look at it.
The design response is to remove the individual judgement and replace it with automatic application plus a review step. Labels applied by location and content type rather than by asking users to classify. Retention triggered by an event rather than a date. Disposition confirmed by a named records officer rather than happening silently.
- Retention labels applied automatically by location and content type
- Event-based triggers on case closure, contract end or departure rather than on a date
- A small label set grouped by retention behaviour rather than mirroring every series
- Disposition review with named reviewers and deputies per series
- Every disposal decision logged, with the log itself retained
The disclosure argument
Storage cost falls, which is worth mentioning and rarely persuades anyone. The argument that lands with agency leadership is different.
A public records request scoped against a properly disposed estate is a fraction of the work. One agency we worked with reduced its response time from weeks to days purely because there was dramatically less material in scope; nothing about the review process itself changed.
That is a service-delivery argument and a cost argument simultaneously, and it is measurable in a way storage savings are not. It also answers the question members ask, which is not about efficiency but about whether the agency can meet its statutory obligations.
The AI connection
Retention is also the control that makes AI adoption defensible. An assistant that can reason across your content will reason across superseded drafts, working papers and material that should have been disposed of.
Agencies planning an AI deployment tend to discover retention as a prerequisite partway through, at which point it becomes an obstacle rather than a programme. Designing it first is considerably easier and it delivers the disclosure benefit regardless of whether the AI programme proceeds.
Framework
Something you can apply without us
Every paper in this series ends with a framework you can run internally. We would rather you used it and reached your own conclusion than took ours on trust.
Framework
Making a schedule operate
Five stages. The first is the one agencies most often skip.
1
Review
Confirm the schedule is current. Automating an obsolete schedule automates the wrong thing at scale.
2
Group
Collapse records series into a small label set organised by retention behaviour, not by series.
3
Automate
Apply by location and content type. Asking users to classify produces inconsistency.
4
Trigger
Use event-based retention where the schedule is event-driven, which is most of it.
5
Review again
Disposition review with named officers, so destruction is a recorded decision.
Implications
What this means, depending on your seat
The same argument lands differently across an executive team. These are the three versions worth separating.
References
Where to check this for yourself
Microsoft's own documentation for the product behaviour described above. We would rather you verified the basis than accepted our summary of it.
01
Retention policies and retention labels
02
Automatically apply a retention label
03
Start retention when an event occurs
04
Disposition of content
05
eDiscovery in Microsoft Purview
On these references: each entry names a Microsoft Learn article or documentation area by title, because deep links change while titles are stable. Searching the title on learn.microsoft.com will reach the current version. Where we have cited a figure or a product behaviour, it is Microsoft's statement rather than ours; where we have given a number of our own it is labelled as such in the text.
Recognise the situation?
We will run a scoped retention review against one department, including what a records request currently pulls in and what it would pull in afterwards, so the disclosure argument is made with your own numbers.
Discuss this paper Run the related checklist We reply to every message within one business day.
Keep reading
Related papers
Cloud economics in the public sector
Public cloud programmes fail at procurement and governance far more often than at technical migration. This paper examines why and proposes a procurement approach that survives review.
June 28, 2026 · 15 pages · 16 min readRead
Third-party risk in public supply chains
Public sector organizations work with many suppliers, and each one that reaches your systems extends the attack surface into an organization whose security you do not control.
February 15, 2026 · 13 pages · 14 min readRead