The Shutdown Brief: Five Gates Between a Retired System and an Evidence Gap
Photo: Jemimus, CC BY 2.0, via Wikimedia Commons
Most data-governance attention is paid at the front door. New systems are assessed, classified, registered and reviewed. The back door receives far less scrutiny, yet it is where records disappear, retention obligations are left without an owner and evidence chains end abruptly. A system switch-off is not merely an IT event with a data footnote. It is a lifecycle decision that should be planned, evidenced and signed off like any other control.
The question for the governance function is not whether the hardware can be powered down. It is whether the organisation can still account for the information that passed through it. Under the accountability principle in UK GDPR, and within the records-management expectations that apply across UK public and private bodies, the burden is to show what happened to the record — not simply to assert that the system is gone.
This brief sets out five gates that should sit between a decommissioning decision and the final shutdown. Each gate produces evidence. None is complete without a named owner.
Gate one: map the dependencies, including the untidy ones
A decommissioning brief that lists only the application and its database is incomplete. Records rarely stay where they were entered. They are copied into reporting layers, exported to spreadsheets, attached to emails, cached in shared drives, embedded in interfaces and replicated to test environments. They may also sit with a processor, a managed-service provider or a legacy archive whose own contract is nearing expiry.
The dependency map should record where records travel, who can retrieve them and which downstream processes rely on them. It should include reporting and analytics extracts, batch interfaces, shared mailboxes, scanning queues, local working copies and backup generations. It should also identify the people who know how to retrieve the data. A retirement that removes the last person who understands the schema is a governance risk, not just a knowledge-management one.
Gate two: reconcile retention schedules with legal holds
Two clocks run in opposite directions during decommissioning. A retention schedule may say that records are due for disposal. A legal hold, investigation, complaint, subject access request or freedom of information request may say that they must be preserved. Neither clock should be resolved informally.
The brief should list every active hold and every applicable retention rule, then record how conflicts are resolved and by whom. Where a hold applies, deletion pauses, and the pause is documented with a review date. Where a schedule authorises disposal, the authority should be cited. If records are migrating, retention metadata must travel with them; a destination that stores content but loses its disposal status has not solved the problem, it has postponed it.
The same review should update the record of processing activities, any relevant data protection impact assessment and the information asset register. Retirement is a change event. Registers that still describe the old system as live are misleading evidence.
Gate three: prove migration integrity before the source is closed
If records are moving to an archive or replacement system, the organisation needs evidence that the record survived the move intact. That means testing completeness, metadata, audit trails, rendering, access controls and redactions. Sampling should be planned rather than improvised, and the sample should include the awkward cases: superseded versions, attachments, linked records, deleted-but-retained items and records with mixed access rights.
Where the destination cannot meet the retention and deletion obligations that applied to the source, the migration should not be treated as complete. A migration that loses context is not a migration. It is a partial loss with a project closure note attached.
Gate four: make deletion evidential
Deletion is often asserted rather than demonstrated. A decommissioning record should distinguish between data that has been deleted, data that is no longer accessible through the retired application, and data that remains in backups or supplier systems pending expiry. Those are different states and they carry different risks.
Evidence may include deletion certificates, system logs, backup expiry schedules, media sanitisation records and written confirmation from suppliers. Processor exit terms should be checked against what actually happens, not what the contract promised. Removable media, local drives and unstructured copies should be included. Where something cannot be deleted, the residual risk and its owner should be recorded.
Gate five: obtain accountable sign-off and review after retirement
The final gate is not a technical test. It is an accountability test. A named business owner, data owner and records manager should sign off the decommissioning record, with data protection and legal input where relevant. The sign-off should confirm that dependencies have been addressed, holds reconciled, migration tested, deletion evidenced and residual risks accepted.
A short post-retirement review at 30 and 90 days should confirm that no orphaned references remain in data catalogues, AI inventories, contracts, registers or request-handling routes. It should also check whether any subject access or freedom of information request has exposed a gap that the closure process missed.
A practical evidence table
| Gate | Core question | Evidence to retain | Accountable owner |
|---|---|---|---|
| Dependency map | Where did the records go? | System and interface map, extract register, retrieval contacts | Data owner |
| Holds and schedules | Which clock governs? | Hold register, retention authority, conflict decisions | Records manager |
| Migration integrity | Did the record survive? | Test plan, sample results, metadata and audit-trail checks | Migration lead |
| Deletion | What was removed, and what remains? | Certificates, logs, backup expiry, supplier confirmations | IT and supplier manager |
| Sign-off and review | Who accepted the residual risk? | Signed closure record, risk register, 30/90-day review notes | Business owner |
Retirement as a control, not an afterthought
A system can be switched off in an afternoon. The governance work is in being able to explain, months later, what happened to the records it held. Treating decommissioning as a control means giving it a plan, a paper trail and an accountable owner. Without those, the plug may be pulled cleanly, but the evidence gap will remain open.
