Backup Is Not Recovery: What to Test Before You Trust It

Somewhere in your organization, a dashboard shows a long run of green checkmarks: last night's backup jobs completed. Leadership reads that as safety. It is not. It is proof that copies were made, which is a different claim from the one that matters.

The claim that matters is recovery: that on the worst day, with the usual people unavailable and the usual systems hostile, you can bring the business back. Backup success is an input to that claim. It is not the claim.

CISA's ransomware guidance says to maintain offline, encrypted backups and to regularly test them. Both halves matter. The untested backup is a hope with a retention policy.

TLDR

• Backup success proves copies exist. Recovery requires proof the copies restore.

• Test restores, not jobs: sample real systems, end to end, on a clock.

• Verify integrity of what comes back, not just that files appear.

• Keep and test an off-system copy an attacker or a ransom event cannot encrypt with the rest.

• Report tested restore evidence to the board, not backup completion rates.

A completed backup job is not evidence of recovery

A backup job completing means data moved from one place to another without the tool complaining. It says nothing about whether the copy is complete, whether it can be restored in order, whether the restored system actually runs, or how long any of that takes.

The distance between those two claims is where ransomware events are lost. Organizations discover, mid-crisis, that the database backup excludes the transaction logs, the restore needs a license server that is also down, or the runbook references a tool nobody has installed in two years.

Why restores fail when backups succeed

The common failure modes are boring, which is exactly why they survive:

• Scope drift. New systems and data stores appear faster than the backup policy is updated, so the green dashboard covers last year's estate.
• Order and dependency. The application restores before its identity service or database, so the service cannot start even though every file is present.
• Encryption without keys. Backups are encrypted, correctly, and the keys live on a system that is also encrypted by the attack.
• No timed runs. Nobody knows the restore takes forty hours until hour thirty-nine of a real event.
• Single-point copies. The backup shares infrastructure, credentials or admin access with production, so one compromise takes both.

The restore-test evidence checklist

Trust the backup when a checklist like this produces recent, passing evidence. The specific rows below are illustrative; the discipline is what transfers.

Test	What it proves	Frequency	Evidence to file
Sample file restore	The copy is readable	Monthly	Restore log with timestamps
Full system restore to isolated network	The system actually runs	Quarterly per critical system	Timed record, witness sign-off
Integrity check on restored data	The data is not corrupt or truncated	With each full restore	Checksum or application-level validation
Dependency-ordered restore	Services come back in working order	Annually	Sequence record with timings
Off-system copy restore	The protected copy survives a production compromise	Annually	Restore record from the isolated copy

Two rows do the heavy lifting: the full system restore on a clock, and the off-system copy. The first converts "we have backups" into a number the board can hold. The second is the difference between a bad week and a bad year.

What belongs in front of the board

Replace the backup completion metric in the board pack with three recovery facts: the last timed restore for each critical system, the date the off-system copy was last proved, and any system whose tested restore misses its recovery objective.

That is the same evidence standard as the recovery test that includes customers, not just servers: the question is never whether the process ran, but whether the outcome is proven.

Frequently asked questions

How often should restore tests run?

Sample file restores monthly, full restores of critical systems quarterly, and a dependency-ordered or off-system restore at least annually. Frequency matters less than recency: the board should never see evidence older than the current architecture.

What is an off-system or offline backup and why does it matter?

A copy that does not share credentials, network reachability or admin control with production. In a ransomware event, anything reachable gets encrypted together; the off-system copy is the one that survives to rebuild from.

Who should witness or sign off restore tests?

Someone outside the team that runs the backups: an internal control owner, IT leadership or internal audit. Self-attested tests grade their own homework.

Is cloud-provider backup enough on its own?

Usually not. Provider snapshots share the provider account and its credentials with production, so an account compromise can take both. Test restores and keep at least one copy outside the blast radius.

A Defensible Next Step

Ask for the most recent timed, witnessed full restore of your most critical system. If the answer is a date, you have evidence. If the answer is a description of the backup tooling, you have a project. Book a Decision-Clarity Call to set the test calendar and the board reporting around it.