Proof, Not Promises: Putting the Annual Restore Test on the Board Agenda

Most boards in the UK can obtain, within minutes, a schedule showing when backups run, where the copies are held and how long they are retained. Far fewer can produce a document showing the date on which the organisation last proved it could bring a service back from those copies, how long that took, and who confirmed the data was whole. The first is a promise. The second is proof. Only one of them is of any use at three o'clock on a Sunday morning during a ransomware incident, and only one will help a caseworker at the Information Commissioner's Office understand how you established that personal data had not been lost.

Backup is a discipline the sector has largely industrialised. Restoration remains, in many mid-market firms, an act of faith.

Why the gap survives scrutiny so easily

Backup reporting is a matter of dashboards. The tooling sends a green tick when a job completes, and that tick means the software successfully wrote bytes somewhere. It says nothing about whether those bytes can be assembled into a working system, whether the encryption keys are still held by someone who can find them, or whether the copy is clean rather than a faithful reproduction of an already-compromised estate.

The second reason is institutional. Backup appears on the risk register as a control marked "in place", and a control marked in place rarely attracts a follow-up question. Internal audit checks that a policy exists and that a schedule is documented. The question that actually matters — when did we last bring something back, and how did it go — is not in the standard test programme, so it is not asked.

The third reason is cost. A proper restore test consumes staff time, a clean environment and, often, a supplier's goodwill. Deferring it produces no immediate consequence. That asymmetry is the whole problem: the consequence arrives all at once, and always at the worst possible moment.

Four layers, and the one most often skipped

A credible drill exercises more than a file share. There are four practical layers, and most organisations test only the first.

Files and unstructured data. The simplest layer and the easiest to evidence. Pick a representative directory, restore it to an isolated location and ask the business owner to confirm it is the version they expected.

Databases and line-of-business applications. Restoration here is rarely a single click. It involves the database engine, the application binaries, connection strings, service accounts and often a supplier's licence server. Record every dependency the team had to reconstruct from memory, because that list is your real runbook gap analysis.

Whole systems. Rebuilding a server or an entire workload from an image proves that the imaging process, the drivers and the boot sequence survive outside the production estate. This is where immutable and offline copies earn their keep; a copy the attacker could have reached is not evidence of resilience.

The identity and configuration layer. This is the layer most often left untested and most likely to render the other three useless. Restoring a file server is a hollow victory if the directory that governs who may reach it no longer exists, or if the privileged accounts used to rebuild are themselves compromised. Include domain controllers, identity providers, conditional access policy configuration and the secrets vault in scope, and prove you can recover administrative control before you recover data.

Measuring against the number you published

Your continuity documentation, and probably a supplier contract, already states a recovery time objective and a recovery point objective. The drill exists to test those numbers honestly rather than to affirm them.

Measure three things and write them down: the time to the first usable copy, the time to full service for the business function, and the actual data loss window in hours or transactions. Compare each against the published objective and record the variance, positive or negative. A test that reports "successful" without a stopwatch has told the board nothing it did not already assume.

Integrity is not the same as availability

A restored database that opens, authenticates and serves a login page may still have lost its final day of postings. Validate at the data level: row counts, checksums, a sampled reconciliation against a known source, and a business user confirming that the figures in front of them make sense. An honest failure discovered in a scheduled drill is worth considerably more than a silent corruption discovered after a real incident, when the organisation has already told regulators and customers that services are being restored.

Who should be present, and who should sign

Three roles matter. The technical team performs the restore. The application or business owner confirms that what came back is genuinely usable, because only they can. An independent witness observes — internal audit, a non-executive director or the senior information risk owner — and signs the record. The signature is not ceremonial; it is the difference between a claim and an attestation, and it is the element that converts an operational exercise into board-level assurance.

The one-page record

Keep the technical runbook separate. Directors need a summary with fixed fields, completed on the day: date and duration; services in scope; target and achieved recovery time and recovery point; the age and location of the data set used; integrity checks performed and their results; dependencies that had to be reconstructed manually; exceptions and variances; decisions taken; and the date of the next test. One page, deliberately.

When the drill fails

Failure is a legitimate outcome and should be reported as such, without euphemism. Log the defect, assign an owner, remediate and retest within thirty days. Confirm in the minutes that the retest took place. If the failure is material, the risk committee and the insurer should hear it from you first.

Cadence and realism

An annual full restore is the minimum. Add a quarterly exercise for the service that would hurt most if it stopped, and a monthly spot restoration of a randomly chosen file to keep the muscle memory alive. Vary the environment: restoring into the live estate proves less than restoring into an isolated, clean-room environment, because the former assumes the estate is trustworthy.

A fire evacuation test is not valued because fires are frequent. It is valued because the drill converts an untested assumption into a dated, signed fact that a board can point to. Recovery capability deserves the same treatment, and the organisation that can produce a one-page restore record is in a materially stronger position than the one that can only produce a schedule.