How to Prove Your Backups Will Actually Restore

A green backup job proves that data was copied. It does not prove that the copy is complete, that it is readable, that it is free of the thing you are recovering from, that anyone knows the procedure, or that the business can run on what comes back. The only artifact that proves any of that is a restore test with a written result — and in the assessments we run, the single most common answer to “when did you last do one” is a pause.

This is how to close that gap: what to test, how to design the drill so it produces evidence rather than reassurance, and what to write down so the result is still useful to an insurer, an acquirer, or a board six months later.

Want to put this into practice? Use our free Cyber Risk Self-Assessment.

What the frameworks actually require

Two NIST CSF 2.0 subcategories carry the whole argument. PR.DS-11: “Backups of data are created, protected, maintained, and tested.” RC.RP-03: “The integrity of backups and other restoration assets is verified before using them for restoration.” Testing is not an optional maturity flourish in CSF 2.0; it is written into the outcome itself, and it appears twice — once as a protective duty and once as a step you owe yourself in the middle of an incident.

The FBI’s guidance in the 2025 Internet Crime Report is more specific about what “protected” means: create off-site or offline backups and regularly maintain backup and restoration, and ensure all backup data is encrypted, immutable — that is, it cannot be altered or deleted — and covers the entire organization’s data infrastructure. Each of those four properties is separately testable, and organizations routinely have two of them.

CISA’s #StopRansomware Guide, developed through the Joint Ransomware Task Force established by Congress in the Cyber Incident Reporting for Critical Infrastructure Act of 2022, is the fuller mitigation reference and is worth reading alongside the recovery design rather than after an incident starts.

The five properties a restore test has to prove

Completeness. Does the backup set cover everything the business needs, including the parts nobody registered — the file share a department stood up, the SaaS tenant with no export, the on-premises box running the licensing service, the configuration that lives only in someone’s console. Scope drift is the most common failure and the least dramatic.

Integrity. Is the restored data readable and internally consistent, and can that be verified before it is used? RC.RP-03 exists because restoring from a compromised or corrupted backup turns a recoverable incident into a repeated one.

Isolation. Can the backup be reached, altered, or deleted using credentials that an attacker who owns the production identity estate would also hold? If the same administrative account governs both production and the backup platform, the backup is a copy, not a control. Immutability and offline or off-site separation are what make the answer no.

Recovery time. How long does the restore actually take under realistic conditions — with the real data volume, the real network path, the real person, and no vendor on the phone. Nearly every first drill runs longer than the estimate, and the size of that gap is the finding.

Operability. Once restored, does the business function? Applications need their dependencies, their identity provider, their certificates, and their integrations. A restored database that no application can authenticate to is not a recovery.

Set the objectives before you test

A drill without objectives produces an anecdote. NIST SP 800-34r1, the contingency planning guide, gives the two definitions the exercise is measured against:

• Recovery Time Objective (RTO) — the maximum amount of time a system resource can remain unavailable before there is an unacceptable impact on other resources and the supported business processes.
• Recovery Point Objective (RPO) — the point in time, prior to the disruption, to which business process data can be recovered given the most recent backup copy; it is a measure of how much data loss the process can tolerate.

Both are business decisions, not IT settings. The useful version of the conversation is not “what RTO do you want” — everyone wants zero — but “how long can order entry be down before we start losing customers rather than time,” asked of the person who owns order entry. Write the answer down per business process, then let the drill tell you whether the current architecture can meet it. Where it cannot, you have either a budget decision or a documented accepted risk. Both are legitimate; silence is not.

Designing a drill that produces evidence

A defensible restore test looks like this:

1. Pick a real business process, not a file. “Restore the invoicing system to a state where a test invoice can be issued” beats “restore a folder.”
2. Restore to isolated infrastructure. Never over the top of production, and never into a network segment where a latent implant could reach anything.
3. Have someone other than the backup owner run it. The drill is testing the runbook as much as the data. If it only works when one person does it, that person is the single point of failure.
4. Start the clock at declaration, not at first byte. The realistic RTO includes decision-making, access to credentials, and finding the runbook — not just transfer time.
5. Validate at the application layer. Log in. Run a transaction. Reconcile a record count against a known-good figure.
6. Test the immutability claim directly. Attempt an authorized deletion of a protected recovery point using an administrative account and record that it was refused. A vendor feature list is not evidence that the feature is enabled on your policy.
7. Record the failures, not just the outcome. The value is in what went wrong at 40 minutes in.

What to write down

The artifact is the point. A restore-test record that stands up later contains: the date; the scope restored; who ran it; the RTO and RPO targets for that process; the measured recovery time with the clock-start definition; whether application-layer validation passed; the integrity verification method; the immutability check result; every deviation from the runbook; and the remediation items with owners and dates. One page. Signed by the process owner, not only by IT.

We keep a fill-in version of exactly these fields — a timed restore log, a data-integrity check, and an immutability result — in our backup and recovery test worksheet.

Keep the last two or three of these in the evidence pack. They do more work than any policy document — for an insurer’s underwriting questionnaire, for a customer’s diligence review, and for a board that wants to know whether “we have backups” is a fact or a habit. The related evidence set is covered in the cyber insurance evidence readiness checklist.

Cadence, and the triggers that beat the calendar

Annual is the floor for a full-process drill, quarterly is better for the tier-one processes, and monthly spot restores of individual items are cheap enough to automate. More important than the interval are the triggers: a platform or major version change on the backup product, a migration of any protected workload, a change to the identity model that governs backup access, a material acquisition, and any incident — because the post-incident drill validates the assumptions that the incident just stress-tested.

Where this fits in a wider readiness program — role mapping, tabletop exercises, first-hour decisions, and the after-action roadmap — is the scope of our incident response and ransomware readiness engagement, which records RTO and RPO and representative restore-test evidence as part of the deliverable. It is readiness work: not live digital forensics, not malware eradication, and not a 24/7 response retainer. If you have no internal security function to run the planning side, incident response planning without a security team covers how to build it with the staff you have.

FAQ

How do you prove a backup will restore?

By running a restore test against a real business process into isolated infrastructure, measuring the time from declaration to application-layer validation, verifying data integrity before use, confirming that the recovery point could not be deleted by production credentials, and recording the result — including deviations and failures — in a one-page record signed by the process owner. A successful backup job report proves a copy was made; only a restore test proves the copy is usable.

How often should backups be restore-tested?

At minimum annually for a full business-process drill, quarterly for tier-one processes, with automated spot restores of individual items more frequently. Event triggers matter more than the interval: a backup platform or major version change, a workload migration, a change to the identity model governing backup access, a material acquisition, or any security incident should each trigger a drill.

What is the difference between RTO and RPO?

NIST SP 800-34r1 defines the Recovery Time Objective as the maximum time a system resource can remain unavailable before there is unacceptable impact on the business processes it supports, and the Recovery Point Objective as the point in time prior to the disruption to which data can be recovered given the most recent backup — that is, how much data loss the process can tolerate. RTO is about downtime; RPO is about data loss. Both are business decisions.

What makes a backup ransomware-resistant?

The FBI’s 2025 Internet Crime Report recommends off-site or offline backups, regularly maintained backup and restoration, and backup data that is encrypted, immutable so it cannot be altered or deleted, and covering the entire organization’s data infrastructure. The practical test is whether an attacker holding production administrative credentials could also reach, alter, or delete the recovery points. If they could, the copy is not a control.

Is a cloud file service the same as a backup?

Not by itself. Native retention, versioning, and recycle-bin windows in a productivity suite are recovery features with finite windows that are governed by the same identity estate as production. They are worth documenting, but a separate copy under separate control — with its own restore test — is what answers the question during an incident.

What this guide is / What it is not

What it is: A practitioner method for designing and evidencing a restore test, anchored to NIST CSF 2.0 subcategories PR.DS-11 and RC.RP-03 (NIST CSWP 29, February 26, 2024), the recovery objective definitions in NIST SP 800-34r1, CISA’s #StopRansomware Guide, and the FBI IC3 2025 Internet Crime Report. What it is not: Legal advice, an audit, a certification, an attestation, or a guarantee that recovery will succeed, that ransomware will be prevented, or that any insurance claim will be paid. A restore test evidences a specific scope at a specific point in time. DSE’s readiness work is planning, facilitation, and validation — not live digital forensics and incident response, malware eradication, or a 24/7 response retainer.

The Bottom Line

The organizations that recover well are not the ones with the best backup product; they are the ones that have restored something recently and wrote down what went wrong. Set RTO and RPO per business process with the process owner, drill a real process into isolated infrastructure with someone other than the backup owner at the keyboard, verify integrity before use, try to delete a protected recovery point and confirm you cannot, and keep the one-page record. That record is the difference between saying you have backups and being able to show it.