To test ransomware recovery, restore your most critical system from the offline backup into an isolated network, check it works, and time every step. CISA and the NCSC both say backups must be tested regularly. A test that only confirms files exist is not enough.
Why the test matters
The NCSC states that up-to-date backups are the most effective way of recovering from a ransomware attack, and advises you to regularly test that they work as expected. CISA's guide says the same about testing and adds that recovery should be prioritised by critical services.
Most teams have backups. Fewer have rehearsed the restore with the people, credentials and documents they would have during a real incident.
Step 1: pick the right target
Use your critical asset list. CISA's checklist says to triage systems for restoration based on a predefined critical asset list and its dependencies. Choose one service that has dependencies, such as an application with a database and an identity provider, rather than a single file server.
Step 2: restore in isolation
Create a separate network segment. CISA advises avoiding reinfection of clean systems and gives the example of a recovery VLAN that holds only clean systems. Use that pattern for the test.
Step 3: restore without normal admin access
Assume your usual directory is unavailable. Do you have the credentials, keys and runbook to restore without it? The NCSC advises keeping offline playbooks and contact details available in case systems are down. Test that they can be found and read.
Step 4: verify the result
Check more than "the VM boots."
- Does the application start and serve a real transaction?
- Is the data as recent as the backup schedule promises?
- Does the restored system depend on something that was not backed up?
Step 5: scan before you trust
The NCSC says to scan backups for malware before restoring, because ransomware may have been present before it was found. CISA also warns that rebuilding without finding dropper malware can allow continued compromise.
Step 6: record the numbers
Write down how long the restore took, what failed, and who had to be called. Those numbers go into your recovery plan. Do not copy a recovery time from a vendor brochure. Use the one you measured.
Step 7: fix and repeat
Update the runbook, fix what broke, and put the next test on the calendar.
Quick check
How often should we test restores?
CISA and the NCSC say regularly but give no fixed interval. Pick one you will keep, and test again after any major change to your backup system.
Can we test by restoring one file?
That proves very little. Restore a full service with its dependencies, in isolation, and time it.
Sources
Last reviewed: 19 October 2026.
