Backup Restore Proof: Evidence Auditors and Insurers Want

Ninety percent of security leaders say they are confident they can recover within their recovery time objectives. Yet only 28% of ransomware-affected organisations fully recovered their data, according to the Veeam Data Trust and Resilience Report 2026. The report surveyed more than 900 leaders at organisations with 1,000 or more employees. It links the gap partly to untested disaster recovery procedures.

Recovery testing is the controlled restoration of backed-up systems. It confirms that data is intact, that applications start, and that recovery meets the recovery time objective. The result is recorded as evidence. A completed backup job proves that data was written. It does not prove that data can be restored.

Auditors and cyber insurers increasingly ask for the second kind of proof. This article sets out what reviewers typically ask for. It defines a five-field record that answers them. It also shows how scheduled, isolated testing produces that record without touching production.

Veeam’s 2026 report found 90% of leaders confident they can meet recovery time objectives, while only 28% of ransomware victims fully recovered data.

Why Recovery Testing Beats Backup Job Success Reports

A green job status is an operations signal. The Forttic 2026 Continuous Resilience Evidence report puts the difference plainly. Job success is not recoverability, and recovery proof is a governance signal. A job report confirms that a copy reached a repository. It says nothing about whether the copy mounts. It does not show whether the application boots. It cannot tell you if the dependencies around it (name resolution, identity services, licensing) still exist.

Independent survey data points the same way. In a Triangle survey reported by Think Business, 64% of the 130 IT and security decision-makers polled said they cannot verify the integrity of their backup data. Only 49% had tested recovery processes within the past 12 months. The sample is small, but the direction matches the Veeam findings.

Backups are also the path most organisations rely on after an attack. The Sophos State of Ransomware 2026 survey covered 2,158 leaders across 17 countries. It found that backup-based recovery reached 66% of encrypted-data cases, up 12 points from 2025. It also found that average recovery costs rose 11% to $1.7 million. When the recovery path is used this often and costs this much, testing backups before an incident is a financial control as much as a technical one.

There is also a security reason. Thinkon notes that when a disaster recovery plan restores from a compromised backup, the attack does not end. It restarts.

Business Continuity Plan Versus Disaster Recovery Plan

A business continuity plan (BCP) covers how the whole organisation keeps working through a disruption. That includes people, facilities and suppliers. A disaster recovery plan (DRP) is narrower. It covers how IT systems and data are restored. Disaster recovery plan testing therefore belongs to the technical side. A tabletop walk-through of the plan does not replace a restore test that moves data and starts workloads. NIST maintains Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1, the long-standing reference for how contingency plans are structured.

What Auditors and Insurers Expect From Recovery Testing

Reviewers use different words. Their requests share one idea: show the artifact, not the assertion. The cyber insurance readiness checklist from UnderDefense says each control needs an artifact rather than an assertion. It maps backups to a dated restore-test log. It also advises running a real restore test by the 60-day mark before renewal.

The guidance on cadence and content is more specific. Cyber Advisors recommends scheduling restore tests quarterly for Tier 1 systems. It also recommends documenting the date, system, duration, success or failure, and lessons learned. In its earlier 2026 guidance on what is changing in cyber insurance, the same firm reports that insurers look for clearly documented restore-testing procedures. They also look for defined recovery time objective (RTO) and recovery point objective (RPO) targets. The firm expects regular restore tests at an annual minimum.

These are advisory-firm readings of what underwriters typically ask for. No insurer has published them as rules. Treat them as a baseline and confirm them against your own renewal questionnaire.

Regulators write in legal language rather than checklists, but the principle is the same. Article 12 of the Digital Operational Resilience Act (Regulation (EU) 2022/2554) is reproduced in the Article 12 text on Springlex. It requires periodic testing of backup procedures and of restoration and recovery procedures. It also says one more thing. When financial entities restore backup data on their own systems, those ICT systems must be physically and logically segregated from the source system. This article describes what the text says. It is not legal advice, and no product or process makes an organisation compliant by itself.

The CISA guidance fits the same pattern. The CISA #StopRansomware Guide tells organisations to keep offline, encrypted backups of critical data. It also tells them to regularly test the availability and integrity of those backups in a disaster recovery scenario. Taken together, the guidance asks for four things. First, a documented procedure with defined targets. Second, a dated record of each test. Third, restoration away from production. Fourth, a cadence that matches system criticality.

The Recovery Testing Evidence Pack: Five Fields

Every restore test should leave behind one record with fixed fields. Without fixed fields, a reviewer cannot compare one quarter with the next. The record below is a working framework built from the guidance above. No standards body publishes it.

Recovery testing is the controlled restoration of backed-up data and systems. It measures whether recovery works, how long it takes, and whether the restored workload is usable. The recovery time objective is the longest acceptable time to restore a service after disruption. The recovery point objective is the maximum acceptable age of the restored data. In practice, it sets how much recent work an organisation can afford to lose.

The five fields are:

1. Restore trace. The timestamp, the source recovery point, the target environment, and who or what started the restore.
2. Clean-point status. The malware scan result for the recovery point, confirming that no dormant ransomware was restored.
3. Measured RTO. The elapsed restore time compared with the stated target, with a note on when the clock started and stopped.
4. Application validation. Evidence that the system booted, services started, and the application can read the data, not just that the data sits on disk.
5. Retention state. The immutability status and retention period of the recovery point at the time of the test, so a reviewer can see that the evidence itself was protected. The guide to immutable file-level WORM retention explains how that protection works.

Add a sign-off line and a remediation note to every record. A failed test with an owner, a fix and a retest date is stronger evidence than a perfect record with no history.

The five-field recovery-proof record, plus a sign-off and remediation note, gives every restore test a consistent shape.

A Disaster Recovery Testing Checklist

This disaster recovery testing checklist turns the record into a repeatable procedure. Follow it from start to finish for each restore test.

1. Select the recovery point and record why it was chosen.
2. Start the clock and restore into an isolated environment.
3. Scan the restored data and record the clean-point result.
4. Boot the workload, confirm that dependencies resolve, and record the application check as pass or fail.
5. Stop the clock, compare the time with the RTO, and record the retention state.
6. Tear down the environment and file the signed record.

Measured results matter because stated targets are often optimistic. Veeam makes a related point in its summary of the 2026 findings. Only 69% of respondents say their RTOs align with business continuity goals.

Sandbox Testing for Safe, Repeatable Restore Tests

Every restore test competes with production for capacity and change windows, which is why many teams test less often than they plan to. Sandbox testing removes that conflict. The recovery point is restored into an isolated environment. It is booted, validated, scanned and then discarded. The test cannot collide with live networks, and it cannot bring an infected workload back. The DORA wording on segregated systems and the CISA advice on integrity testing both support this principle.

Cadence should follow system tier. Cyber Advisors recommends quarterly restore tests for Tier 1 systems, as noted above. For lower tiers, a rotation that covers every system at least once a year is a reasonable minimum. Any major change to an application, identity service or network should trigger an extra restore test. Treat lower-tier cadence as a recommendation and set it against your own recovery objectives.

Four failure modes appear repeatedly in restore tests:

• Missing dependencies. Name resolution, identity services and licensing servers are often absent from the isolated environment, so the application starts but cannot sign in.
• Stale credentials. Service accounts and keys that changed after the recovery point was written no longer work.
• An infected recovery point. The restore succeeds, but it returns the malware that caused the incident.
• Undersized recovery compute. The restore completes, but the measured RTO exceeds the target because the recovery environment is smaller than production.

A job report hides all four, and a restore test surfaces them. That is the strongest argument for running disaster recovery tests on a schedule rather than only after an incident.

A sandbox restore test moves from recovery point selection to a signed evidence record in six steps without touching production.

How StoneFly Supports Recovery Testing Evidence

The five-field record is only practical if tests run without manual effort. This is the problem StoneFly DR365V addresses. It is a Veeam Ready air-gapped and immutable backup and disaster recovery solution. Automated recovery testing is one of its capabilities. Its on-demand isolated sandbox supports backup validation, disaster-recovery plan testing and ransomware-free recovery validation. It can verify that protected systems boot and operate. Tests can run unattended on daily, weekly, monthly or custom schedules, with reporting on test results.

Several other capabilities map to the fields in the record. A centralized dashboard shows sandbox and recovery-test status, immutable retention status, and audit and activity reporting. That supports the retention state and sign-off fields. The patented Air-Gapped Vault® with immutable storage keeps retention immutable for the configured period. Machine learning-based ransomware detection runs during backup jobs. That supports the clean-point question before a test begins. Instant multi-VM recovery lets several protected virtual machines be recovered and spun up on the appliance. That supports testing application groups rather than single machines. The StoneFly Veeam Ready backup and disaster recovery appliance page describes how administrators launch an isolated sandbox to test recovery processes without affecting production workloads.

For replication-based recovery, StoneFly Cloud Connect can replicate virtual machines as images and support remote spin-up with an RTO as low as five minutes. That figure applies to Cloud Connect replication and not to DR365V.

Organisations that use Veeam cloud backups can also use StoneFly Veeam Cloud Backups. Its documentation states that a successful job alone does not establish that a workload can be recovered. It also states that backup testing and professional services can validate selected recovery points and document the outcome. StoneFly AI SandboxHub™ is a separate on-premises appliance that can restore backups into an isolated sandbox for analysis and disaster-recovery testing.

The evidence record is assembled from test results, dashboard status and audit reporting. No product makes an organisation compliant on its own.

Building a Recovery Testing Programme Auditors Can Trust

A programme earns trust through consistency, not through one impressive test. Start with governance. You need a named owner, a schedule, scope tiers, retention of the evidence itself, exception handling, and retests triggered by change. Auditors and underwriters can then see that the process continues when staff change.

Four mistakes weaken otherwise sound programmes. Teams test file restores but not full application recovery. They test only the latest recovery point, which hides older points that may hold a different state. They leave the clock start undocumented, so the RTO cannot be reproduced. They also record failures without a remediation loop, so the same fault appears again in the next test.

A 30-60-90 day plan gives a team a practical start. It uses the timing in the Cyber Advisors guidance.

1. Days 1 to 30: define Tier 1 systems, write the restore-testing procedure, set RTO and RPO targets, and schedule the first restore test.
2. Days 31 to 60: complete at least one Tier 1 restore test and file the five-field record. This also meets the day-60 point in the UnderDefense advice.
3. Days 61 to 90: fix the failures found, automate the schedule for Tier 1 systems, and agree how test records are reviewed and signed.

Conclusion: Replace Job Status With Recovery Testing Proof

The Veeam figures, 90% confident against 28% fully recovered, show how far belief can sit from evidence. Reviewers now ask for dated, measured records instead of dashboard screenshots. A five-field record gives every test a consistent shape. It covers the restore trace, clean-point status, measured RTO, application validation and retention state. Isolated, scheduled tests make that record continuous instead of annual.

Start with one Tier 1 system: run a restore test this quarter, and file the record. If your Veeam environment needs a repeatable way to do that, talk to StoneFly about recovery testing for Veeam environments.