Backup and Recovery Testing Checklist for Ransomware

A backup job that reports success proves only that data was copied, not that the business can be restored after ransomware, when the domain controllers, identity provider and backup console may all be untrusted at once. This checklist is the working document for a restore test: it records what was in scope, how the isolated recovery environment was built, whether restored data was clean and complete, how identity systems were brought back, and the measured recovery times and recovery points set against the targets. It is written for infrastructure and backup owners, business continuity leads and the auditors and executives who sign off results. Backup design (immutability, isolation, retention) is covered in the Backup Security and Immutable Backup Guide, and the testing programme behind this checklist in the Restore Testing and Recovery Assurance Guide; this page is the evidence form you fill in on the day.

How to use this template

Copy the checklist for each test. Replace text in square brackets, such as [Organisation], [Recovery lead] and [4 hours], with your own values. Bracketed numbers are suggested defaults, not external requirements.
Mark each check Pass, Fail or Not tested in the Result and evidence column and record where the evidence is kept (screenshot, log export, ticket, timestamped chat). A check without evidence is recorded as Not tested.
Recovery time objectives (RTO) and recovery point objectives (RPO) must come from your business impact analysis and the Backup and Recovery Policy Template tiers, not from this page.
Run sections 1 to 3 for every test. Sections 4 to 6 apply to isolated, full-system and ransomware scenario tests; for a routine file-level restore they may be marked Not applicable with a reason.
Store the completed checklist with the test report so the trend of measured times can be shown to auditors and the board.

1. Test record

Field	Entry
Test ID, date and start time	[RT-2026-11] [Date] [Time, time zone]
Test type (see section 2)	[File / Application / Full system / Isolated environment / Ransomware scenario]
Services and systems in scope, with recovery tier	[Service, Tier 1] [Service, Tier 2]
Backup platform, copy and restore point used	[Platform] [Immutable or offline copy] [Restore point timestamp]
Target RTO and RPO for each service	[RTO] [RPO]
Scenario assumption	[For example: production directory and backup server are untrusted; only the immutable copy and the break-glass accounts are available]
Recovery lead, participants and observers	[Names and roles; include the system owner and an independent observer]
Result	[Pass / Pass with findings / Fail]

2. Scope and test type

Pick the test type that matches the question you need answered. A file restore proves the media is readable; only an isolated environment test proves you can rebuild a working service when production is untrusted.

Test type	What it proves	What it does not prove	Suggested frequency
File or object restore	Backup media is readable, catalogue is intact, permissions allow restore	That an application works or can be rebuilt	[Monthly, automated where possible]
Application or database restore	Data is consistent and the application starts and serves transactions	Dependencies such as identity, DNS and certificates	[Quarterly per Tier 1 application]
Full system restore	A server or virtual machine can be rebuilt from backup or golden image within the RTO	Recovery when the backup platform itself is compromised	[Quarterly sample]
Isolated environment (clean room) recovery	A service and its dependencies can be rebuilt in a network with no path to production, using only protected copies	Production cutover and capacity at full load	[Twice a year for Tier 1]
Ransomware scenario exercise	People, decisions, communications and technical recovery work together under realistic assumptions	Every system: scenario tests sample the critical path	[Annually, combined with a tabletop]

#	Check	Result and evidence
2.1	The services in scope are on the critical recovery path agreed in the business impact analysis, and the sample rotates so every Tier 1 service is tested at least [annually]. See the Minimum Viable Company and Critical Service Recovery Order Guide.	[ ]
2.2	Dependencies for each service are listed: directory and identity provider, DNS, DHCP, certificate authority, key management, secrets vault, licensing servers, network and firewall configuration.	[ ]
2.3	SaaS data in scope (mail, collaboration, CRM, source code) is included where the business depends on it, restored from the third-party copy rather than the provider's own recycle bin.	[ ]
2.4	The restore point chosen is older than [the assumed attacker dwell time, for example 30 days] for at least one test a year, to prove that an older clean copy is usable.	[ ]
2.5	Success criteria are written before the test: what "restored" means for each service (application login works, last transaction visible, reports run), not just "the VM booted".	[ ]

3. Pre-test preparation

#	Check	Result and evidence
3.1	The recovery runbook for each service is available offline (printed or on a device outside the production domain). CISA's #StopRansomware Guide recommends keeping hard copy and offline versions of the incident response plan.	[ ]
3.2	Backup job history for the restore point shows success and no unexplained gaps, retention changes or deletions in the backup platform audit log for the last [30 days].	[ ]
3.3	Encryption keys needed for the restore are available from their protected location, including an out-of-band copy. The NCSC principles for ransomware-resistant cloud backups warn that a deleted or altered key makes backups unrecoverable even if the data survives.	[ ]
3.4	Break-glass accounts for the backup platform and the recovery environment have been checked, and their credentials are held outside the production identity provider. See the Backup Identity Isolation Guide.	[ ]
3.5	Installation media, golden images and infrastructure-as-code templates are available from an offline or immutable store, as CISA recommends for rapid redeployment.	[ ]
3.6	Change management, the security operations team and the service desk have been told the test window, so alerts from restored systems are recognised and not escalated as an incident.	[ ]
3.7	A timekeeper is named and the clock start is defined (declaration of the scenario, not the first restore command), so measured recovery time matches what the business would experience.	[ ]

4. Isolated recovery environment

#	Check	Result and evidence
4.1	The recovery network has no route, VPN, peering or trust relationship to production; this was confirmed by a connectivity test from inside the environment, not assumed from the design diagram.	[ ]
4.2	Restored systems cannot resolve or reach production DNS, directory, management or update servers. Outbound internet is blocked or limited to an allow list needed for the test.	[ ]
4.3	The recovery environment uses its own administrative accounts and multi-factor authentication, created for the test or held in reserve, not synchronised from production.	[ ]
4.4	Capacity in the recovery environment (compute, storage throughput, bandwidth from the backup copy) is recorded, so a slow restore can be attributed to capacity rather than process.	[ ]
4.5	Logging and endpoint detection are running in the recovery environment before restored systems start, so indicators of compromise in the restored data are seen. See the Cloud Recovery and Clean Room Guide.	[ ]
4.6	The environment is torn down or reset after the test, and any production data copied into it is securely deleted, with evidence.	[ ]

5. Clean restore and integrity validation

NIST CSF 2.0 RC.RP-03 expects the integrity of backups and other restoration assets to be verified before they are used, and RC.RP-05 expects the integrity of restored assets to be verified before normal operation is confirmed. These checks provide that evidence.

#	Check	Result and evidence
5.1	The restore point was scanned with current malware signatures and indicators of compromise from threat intelligence before restored systems were connected to anything.	[ ]
5.2	Restored systems were checked for persistence: new local or domain accounts, scheduled tasks, services, startup items and remote access tools that are not in the baseline.	[ ]
5.3	Data completeness was confirmed against an independent record: file counts and checksums, database row counts, the last known transaction ID or a reconciliation report.	[ ]
5.4	Database consistency checks ran without errors and transaction logs were replayed to the intended point.	[ ]
5.5	Encrypted or corrupted files were not present in the restore point (sample opened by the data owner, not only by the backup tool).	[ ]
5.6	The system owner confirmed the application works end to end: users log in, a test transaction completes, integrations and scheduled jobs run.	[ ]
5.7	Operating system and application versions on restored systems were recorded, and any critical patches missing since the restore point are listed for remediation before cutover.	[ ]

6. Identity system restore

Ransomware recovery stalls when the directory or identity provider cannot be trusted, because almost every other restore depends on it. Test identity recovery explicitly. Deep procedures are in the Active Directory Forest Recovery Runbook Template, the IdP configuration backup and restore for Entra ID and Okta guide and Recovering IAM and PAM After Ransomware or Domain Compromise.

#	Check	Result and evidence
6.1	A directory domain controller (or equivalent) was restored from a backup older than the assumed compromise, in isolation, and the documented forest or domain recovery steps were followed.	[ ]
6.2	Privileged and service account passwords, Kerberos ticket-granting account keys and trust secrets were reset as the runbook requires, and the time taken was recorded.	[ ]
6.3	Cloud identity provider configuration (conditional access, federation, application registrations, group assignments) was restored or rebuilt from exported configuration and compared with the last known good export.	[ ]
6.4	Non-human identities needed by the restored services (service accounts, API keys, certificates, workload identities) were re-issued from the recovery secrets vault, not reused from the restore point. See the Secrets Management Guide.	[ ]
6.5	The privileged access vault and its break-glass procedure were recovered, and at least one administrator authenticated through it.	[ ]
6.6	Certificate authority and key management configuration needed for TLS and code signing were available, or a documented interim process worked.	[ ]

7. RTO and RPO evidence

Record measured values per service. Recovery time runs from declaration to the owner confirming the service works (check 5.6), and includes rebuilding the platform, not only copying data.

Service	Target RTO	Measured recovery time	Target RPO	Achieved recovery point (age of data restored)	Met?	Main delay
[Identity provider and directory]	[4 hours]	[ ]	[1 hour]	[ ]	[Yes / No]	[For example: key retrieval, approvals, restore throughput]
[Tier 1 application]	[8 hours]	[ ]	[15 minutes]	[ ]	[ ]	[ ]
[Tier 2 application]	[48 hours]	[ ]	[24 hours]	[ ]	[ ]	[ ]

#	Check	Result and evidence
7.1	Timestamps for each recovery step (declaration, keys retrieved, environment ready, restore started, restore finished, validation passed, owner sign-off) are recorded from a single clock.	[ ]
7.2	Where several services were restored in sequence, the total elapsed time for the whole critical path is recorded, not only each service on its own.	[ ]
7.3	Restore throughput (for example terabytes per hour from the immutable copy) is recorded and extrapolated to a full-estate recovery, and the extrapolation is compared with the RTO.	[ ]
7.4	Any target missed is raised as a finding with an owner, not quietly adjusted after the test.	[ ]

8. Findings, remediation and sign-off

#	Check	Result and evidence
8.1	Every failed or Not tested check has a finding with an owner, severity and due date in [the risk or issue register].	[ ]
8.2	Runbooks were updated with the steps that were missing, wrong or slow, and the version number recorded.	[ ]
8.3	A retest date is set for any Tier 1 service that failed its RTO or RPO.	[ ]
8.4	Lessons are fed into the incident response and disaster recovery plans. See the Disaster Recovery Plan Template.	[ ]
8.5	The result is signed by the recovery lead, each system owner and [the CISO or Head of Infrastructure], and summarised for [the risk committee].	[ ]

Role	Name	Decision	Date
Recovery lead	[ ]	[Pass / Pass with findings / Fail]	[ ]
System owner(s)	[ ]	[Accept / Reject]	[ ]
Independent observer	[ ]	[Confirms evidence is complete]	[ ]
[CISO or Head of Infrastructure]	[ ]	[Approve]	[ ]

Implementation guidance

Start small, then make it harder. Begin with automated file and application restores so the basic mechanics are routine, then add a quarterly full system restore and a twice-yearly isolated environment test for Tier 1. A small organisation with one site can combine the isolated test and the annual ransomware exercise; a large estate should rotate the sample so every Tier 1 service is tested each year.
Assume the worst on the day. Write the scenario so production identity, the backup server and the hypervisor management plane are untrusted. Tests that quietly use production domain accounts to run restores hide the most common real failure.
Automate the evidence. Many backup platforms can run scheduled restore verification and produce reports. Use them for sections 3 and 5 at scale, and keep the manual checklist for the dependencies and decisions automation cannot see, such as key retrieval and identity recovery.
Test safely and be able to back out. Never restore into production networks for a test. Confirm isolation (check 4.1) before powering on restored systems, and keep a documented stop condition: if any path to production is found, power off and investigate before continuing.
Measure the trend. Report five figures each quarter: share of Tier 1 services with a passing test in the last [12 months] (target 100 percent), median measured recovery time against RTO, restore throughput from the immutable copy, number of open findings older than [90 days], and time to retrieve encryption keys and break-glass credentials.
Tie it to the frameworks. CIS Controls v8.1 Safeguard 11.5 (Test Data Recovery) asks for recovery testing at least quarterly on a sample of in-scope assets, and NIST SP 800-53 CP-4 and CP-9(1) require contingency plan testing and backup reliability and integrity testing. The checklist record is the evidence for all three.

Framework mapping

Checklist area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1
Scope, plan and runbooks (sections 2, 3)	CP-2, CP-4	RC.RP-01, ID.IM-02	5.29, 5.30	11.1
Backup integrity and clean restore (sections 3, 5)	CP-9, CP-9(1), CP-9(8)	PR.DS-11, RC.RP-03	8.13	11.3, 11.5
Isolated recovery (section 4)	CP-9, SC-7	PR.IR-03	8.13, 8.22	11.4
Restoration and reconstitution (sections 6, 7)	CP-10, CP-10(2)	RC.RP-05	5.30, 8.14	11.5
Findings and improvement (section 8)	CP-4, IR-4	ID.IM-02	5.27	11.1

The attacks these tests guard against are mapped in MITRE ATT&CK as T1490 Inhibit System Recovery, T1485 Data Destruction and T1486 Data Encrypted for Impact. See the T1490 Inhibit System Recovery Defensive Guide.

Standards and references

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Restore Testing and Recovery Assurance Guide · Backup Security and Immutable Backup Guide · Ransomware Response and Recovery Guide · Cyber Recovery Vault Guide · Top 10 Backup and Recovery Mistakes

Backup and Recovery Testing Checklist: Prove You Can Restore After Ransomware