The Case Against Keeping Everything: A Retention-Deletion Audit for UK Compliance Records

Retention drift is a control failure, not a filing problem

Most UK firms can produce a retention schedule. Fewer can demonstrate that it is applied. The gap is rarely caused by bad faith. It emerges from small, sensible-sounding decisions: a case file kept open because a former client might return, a draft assessment retained because it took effort to produce, an email archive preserved because nobody is quite sure what is in it. Each decision is defensible in isolation. Cumulatively, they turn a storage-limitation policy into an aspiration.

Under the UK GDPR, Article 5(1)(e) requires personal data to be kept in a form that permits identification for no longer than is necessary for the purposes for which it is processed. That is not a suggestion to delete when convenient. It is a principle of law, enforceable by the Information Commissioner's Office. The same logic runs through sector rules: the Money Laundering Regulations 2017 require five years' retention after the end of a business relationship, but that figure is a minimum, not a licence to keep records indefinitely. FCA-regulated firms are expected to retain records to evidence compliance; they are not expected to hoard every working draft forever.

The practical risk is easy to underestimate. A subject access request compels disclosure of personal data in scope — including obsolete assessments, superseded risk ratings and correspondence about matters that closed years ago. The wider the archive, the broader the search, the heavier the redaction burden, and the greater the chance that stale material is disclosed without the context that once explained it. Regulators, meanwhile, may ask not only whether records exist but why they still do.

A retention-deletion audit is the control that answers those questions. It is not a purge. It is a documented, evidence-based process for confirming that records are held for a stated purpose and deleted when that purpose ends.

Step 1: Test the schedule against what the business actually holds

Begin with the schedule itself. Many were drafted years ago, refer to teams that no longer exist and list systems that have been decommissioned. Test each entry against three questions: what event starts the retention clock, how long the period lasts, and what legal or contractual basis supports it.

Look for entries marked 'permanent' or 'indefinite' without a clear justification. Inherited schedules from acquired businesses are a common source of inconsistency. So are categories such as 'general correspondence' or 'miscellaneous compliance records', which tend to become a home for anything that does not fit elsewhere. A schedule that cannot be applied by a records owner without interpretation is not yet a control.

Step 2: Reconcile the schedule to the data map

A schedule describes categories. A data map describes locations. The audit should connect the two. Sample records from each system — case management, customer relationship platforms, shared drives, email archives and legacy applications — and check whether the closure or end-of-relationship date is actually recorded. Without a reliable trigger date, a retention period cannot be calculated.

Pay particular attention to shadow archives: personal drives, exported mailbox files, team SharePoint sites and local databases maintained outside the formal record-keeping environment. These are where 'just in case' retention tends to live. Assign a named owner to each category and location. Ownership is not a bureaucratic detail; it is the difference between a schedule that is monitored and one that is merely published.

Step 3: Scope legal holds before any deletion

Deletion must pause wherever a legal hold applies. Litigation, a regulatory investigation, an employment dispute or a live subject access request can all require material to be preserved beyond its ordinary retention period. The audit should therefore examine the hold register before any deletion is executed.

The common failure is not an absent hold but a stale one. Holds applied informally by email, never reviewed and never released, quietly become permanent retention. Record each hold with its matter reference, scope, custodians, date applied, reviewer and release date. Where a hold has lapsed, document the release decision. Where it remains active, exclude the affected records from the deletion population and record why.

Step 4: Define backup and archive exceptions explicitly

Backups are the most frequently cited reason for not deleting data. They are also the least clearly governed. A defensible policy states what happens to data in backups, how long backup cycles persist, and the conditions under which data may be restored. If restored for disaster recovery, retention rules should be reapplied rather than reset.

The same discipline applies to offline archives, cloud snapshots and disaster-recovery copies held by third parties. An exception is acceptable if it is documented, time-bound and approved. 'We cannot delete from backup' is not an exception; it is an unexamined process.

Step 5: Execute deletion and verify the result

Run a controlled pilot on one low-risk category before extending the approach. Use system reports rather than assurances. For the pilot population, record how many records were due for deletion, how many were deleted, how many were retained and on what basis, and how many could not be deleted because of a hold or technical constraint.

Verification matters. Re-run the query after deletion to confirm the records are no longer present in the live environment. Check that scheduled deletion jobs are actually running; automated tasks fail silently when permissions change or interfaces are updated. Where deletion is manual, expect inconsistency and document the control that compensates for it.

Step 6: Evidence the deletion decision

The audit file should allow a regulator or the ICO to reconstruct what happened without relying on recollection. That means retaining the approved policy and schedule version, the data map, the hold register, the deletion log with dates and record counts, approvals for exceptions, and the verification report. A certificate of destruction for every individual file is rarely proportionate; a clear, consistent record of the decision and its execution is.

The evidence should itself have a retention period. Deletion logs do not need to be kept forever, and retaining them indefinitely would undermine the principle the audit is designed to uphold.

Proportionality and repetition

A retention-deletion audit should not become an exercise in destroying records that still serve a purpose. Contractual claims, regulatory minimums and sector-specific rules may all justify longer retention. The objective is a conscious, documented decision rather than an inherited habit.

Treat the audit as an annual control, not a one-off project. Report three measures to the board or compliance committee: the proportion of record categories with a tested retention period, the volume of records past their deletion date, and the number and age of open exceptions. Those figures turn storage limitation from a policy statement into something the business can actually see.