Proof of Restore: An Evidence Standard for Systems That Lost Their Owner
Photo: Stephen Standifird, Public domain, via Wikimedia Commons
Most UK IT functions can produce a backup report within minutes. Far fewer can produce a restore record for a specific business service, dated within the last twelve months, signed by someone who understands what the data is for. The gap between those two artefacts is where operational resilience quietly erodes, and it widens fastest around systems that have lost their owner.
A backup job is a statement about a process. A restore is a statement about a service. The first is automated, monitored and usually green. The second is manual, disruptive, occasionally embarrassing and very often unscheduled. When a system is well owned, that distinction tends to be caught during routine change activity. When ownership has lapsed — a departed contractor's reporting database, an inherited tool from an acquisition, a line-of-business application whose internal champion moved on in 2023 — nobody is close enough to the system to notice that its recoverability has never been demonstrated.
The gap between a completed job and a recovered service
Backup software answers a narrow question: did the data leave the source and land in the repository? It says nothing about whether the application will start, whether the database will pass consistency checks, whether dependent services will resolve against it, or whether the business will accept the recovered state as usable. Orphaned systems concentrate this risk because the knowledge required to define 'recovered' has usually left with the person who once held it.
There is a second, quieter problem. Orphaned systems are frequently excluded from the business impact analysis, which means they carry no recovery time objective and no recovery point objective. A restore drill without agreed targets is not a test; it is an experiment. The result may be technically successful and still fail the organisation, because nobody had defined what success should look like.
Ownership checks before any drill is scheduled
Before booking a restore window, establish three things for each in-scope system. First, who can authorise a restore into production, including out of hours. Second, who defines the acceptable recovered state in business terms — not 'database online', but 'the month-end reconciliation reconciles'. Third, who signs the evidence afterwards and accepts it into the risk register.
A practical way to surface candidates is to query the configuration management database for systems with no named service owner, no change record in the past eighteen months, no entry in the business impact analysis, or a software licence registered to an individual who has left. Cross-reference against the backup catalogue to confirm which of those are actually being backed up. The intersection is your orphan list, and it is usually longer than expected.
What an evidence standard should contain
A screenshot of a progress bar is not evidence. A defensible restore record typically holds: the system and data scope tested; the agreed RTO and RPO; the point-in-time target and the point-in-time actually achieved; integrity checks such as record counts, checksums or referential integrity queries; application-level verification performed by a business representative; the elapsed time for each stage; any discrepancies, partial recoveries or manual interventions; and a named sign-off. Retain it alongside the change record, not in a shared drive owned by one engineer.
Two further conventions are worth adopting. Record failures verbatim — an evidence register that only contains successes is not an assurance document. And store the restore procedure itself with the evidence, because the drill is also a test of whether the runbook still works when the original author is unavailable.
A 2026 restore calendar for a UK operating year
A quarterly rhythm suits most organisations, layered over lighter monthly and weekly checks. Align it to the UK financial year and the change freezes that surround it.
January to March: complete the orphan inventory, and run a restore of at least one low-criticality orphaned system into an isolated environment. The purpose is to learn, not to impress. April to June: move up a tier, restoring a business-critical service with a business representative present to verify output. Avoid the weeks around the April year-end. July to September: attempt a fuller invocation for one service, including DNS, authentication dependencies and network placement, and schedule around the August leave peak rather than through it. October to December: review the year's evidence, report to the risk or audit committee, retest anything that failed, and complete a single-file or single-mailbox restore as a routine control. Hold the December change freeze sacred; a restore drill that collides with it will be cancelled and will not be rescheduled.
Monthly, restore a sample file or mailbox and time it end to end. Weekly, verify backup integrity, immutability windows and repository access controls, because a backup that can be deleted by the same credentials that created it is a weaker control than the dashboard suggests.
Where restore evidence meets accountability
For UK organisations processing personal data, restore capability is not merely an infrastructure concern. Article 32(1)(c) of the UK GDPR expects an ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident, and Article 5(1)(f) requires appropriate security against unauthorised processing, loss and damage. The ICO's breach reporting clock does not pause while a recovery is attempted; if a system cannot be restored within a defensible window, the assessment of notifiable harm changes accordingly.
Operational resilience expectations point the same way. Firms within the FCA and PRA regimes must evidence the continuity of important business services; ISO 22301 and NCSC guidance encourage the same discipline for everyone else. In practice, the audit question has moved on from 'do you back up?' to 'show me your most recent restore, and tell me who owned the system'.
Making the discipline stick
Assign restore accountability to the service owner, not the backup team. The backup team runs the mechanism; the owner accepts the outcome. Publish the evidence register so that gaps are visible rather than inferred. Treat a failed restore as an incident with a named resolver, and add orphaned systems to the internal audit plan until ownership is either restored or the system is decommissioned.
The uncomfortable finding is rarely that backups are broken. It is that confidence has been assembled from job logs rather than recoveries, and that the systems least likely to be tested are precisely the ones nobody would know how to rebuild.
