No Owner, No Rule: A Two-Week Retention Audit for Orphaned Data
Most UK organisations accept that data has value. Far fewer can say, with confidence, who owns a given store of it, how long it should be kept, or what should happen when that period ends. The result is an inherited archive: shared drives, exported CRM records, email archives and backup catalogues that accumulate quietly after reorganisations, supplier changes and acquisitions. Nobody deliberately created the problem, but nobody is accountable for solving it either.
That is a board-level issue, not merely a housekeeping one. Orphaned data increases storage and backup costs, complicates subject access and erasure requests, and widens the disclosure surface in litigation or regulatory inquiry. It also makes a retention policy look credible on paper while remaining unenforceable in practice. A short, disciplined audit can replace that ambiguity with a defensible baseline.
Begin with the question the board can answer
A retention audit should not start with a policy template. It should start with the question the board is actually able to approve: which stores contain personal or regulated data, which named role owns each store, and which retention rule applies? The aim of a two-week exercise is not perfect classification of every file. It is a reliable register of stores, a documented set of obligations and a one-page schedule that turns policy into decisions.
Sponsorship matters. The audit should be led by the IT director or chief information officer, with the data protection officer, records manager, finance and legal functions involved. A board or executive sponsor should receive the output. Without that sponsorship, unresolved ownership questions tend to be deferred rather than decided.
Set a realistic scope
Define the estate before examining it. A practical scope includes on-premises and cloud file shares, Microsoft 365 or Google Workspace collaboration sites, CRM exports, line-of-business databases, email archives and PST files, backup catalogues, and removable media. Paper records should be noted where they exist, even if the first audit concentrates on electronic stores. Live transactional systems can be excluded from file-level review, provided their retention settings and exports are captured.
The register should use consistent fields: store name, system or location, business function, accountable owner, data types, approximate volume, lineage, access groups, backup status, known legal hold and proposed disposition. Volume can be estimated from system reports; it does not need to be exact. Lineage matters because an export taken from a CRM three years ago may contain the same personal data as the live system, but with weaker controls and no obvious owner.
Week one: inventory and evidence
The first week is about evidence, not opinion. Use storage reports, Microsoft 365 or Google Workspace administrative exports, backup catalogue metadata and interviews with business managers. Sampling is usually sufficient: the objective is to characterise the store, not to open every document. Record confidence levels where ownership or content is uncertain. A store with no accepted owner should be assigned an interim owner by business function, not left blank.
Avoid treating individual file custodians as owners. Accountability should sit with a named role or function that can make retention decisions and attest to them. The audit should also identify stores that are technically orphaned: former employee drives, abandoned project sites, legacy systems with no support contract, and backup sets whose original application has been decommissioned.
Week two: obligations, holds and disposition
The second week maps obligations to the inventory. Under UK GDPR and the Data Protection Act 2018, personal data must not be kept longer than necessary. Sector rules, employment requirements, health and safety duties, pension obligations and financial legislation may require longer periods. Finance and tax rules commonly point to six years for accounting records, but the precise position should be confirmed with legal and tax advisers rather than assumed.
Legal holds override any retention schedule. The audit should identify actual or reasonably anticipated litigation, regulatory investigation, insurance claim or employment dispute, and place a written hold on the relevant stores. The hold should state its reason, scope, date and review point, and it should suspend normal deletion. A hold that exists only in a lawyer's file is not defensible operationally; IT and records owners need to see it and act on it.
Disposition should then be proposed store by store. Some data will be retained for a defined period. Some will be deleted at a set trigger, such as contract end plus six years. Some will be transferred to an approved archive. Backup copies require their own statement: deletion from the primary system does not necessarily remove data from backup media, so the schedule should explain how backup expiry and hold requirements interact.
Produce a one-page schedule
The output should fit on one page. Use categories rather than every folder: finance records, HR files, customer contracts, marketing lists, project archives, legacy exports, backup sets. For each, record the accountable owner, retention period, trigger event, disposition action, hold status and next review date. Exceptions should be listed separately with an owner and an expiry date. A one-page schedule forces choices and is far more likely to be read by a board than a fifty-page policy.
Approval should be explicit. The board or executive committee should minute the schedule, note any unresolved exceptions and set a review date. The schedule then needs to be embedded in practice: records management settings, backup configuration, project closure checklists, supplier exit plans and acquisition integration playbooks.
Make retention routine
A two-week audit is a baseline, not a permanent cure. Quarterly owner attestations, an annual review and event-driven checks after acquisitions, system decommissioning or supplier changes will keep the register honest. The board does not need to see every store. It needs to see that orphaned data has an owner, that retention rules are applied, and that legal holds are visible and controlled. That is a defensible position, and it is one the organisation can explain.
