IT Disaster Recovery Checklist

An IT disaster recovery checklist for small and mid-sized teams: priorities, backups, runbooks, incident response, recovery and testing.

Published October 18, 2026

Download PDF

Scope and Priorities

List every critical system, application and data store
Map which business processes depend on each system
Set a recovery time objective (RTO) for each system
Set a recovery point objective (RPO) for each system
The RPO sets your backup frequency: a one-hour RPO needs at least hourly backups or replication.
Rank systems into recovery tiers, with dependencies first
Identity, DNS and networking usually have to come back before the applications that rely on them.
Get management sign-off on the targets and the budget they need

Backups and Data Protection

Follow the 3-2-1 rule: three copies, two media types, one off-site
Keep at least one immutable or offline backup copy
Ransomware commonly targets connected backups first, so an offline or immutable copy is your last line of defense.
Back up cloud and SaaS data, not just on-premises servers
Encrypt backups and store the keys separately
Use separate credentials with MFA for backup administration
Monitor backup jobs and alert on failures

Recovery Environment

Choose a recovery site: cloud, secondary data center or hot, warm or cold standby
Document network, firewall and DNS settings needed to fail over
Keep spare hardware or a replacement plan for key devices
Store licenses, installers and configuration exports off-site

Runbooks and Contacts

Write step-by-step recovery runbooks for each tier-one system
Assign a recovery owner and a backup person for each system
Keep a contact list for staff, vendors, ISP, insurer and cloud providers
Store the plan where you can reach it if your systems are down
Keep a printed copy and a copy outside your own network, since the plan is useless if it lives only on the systems that failed.
Prepare message templates for staff and customers

During an Incident

Declare the incident and name an incident lead
Contain the problem: isolate infected or failing systems
Preserve logs and evidence before wiping anything in a security incident
Notify management, insurers and any regulators that require it
Log every decision and action with a timestamp

Recovery and Validation

Restore systems in tier order, starting with dependencies
Check restored data is complete and from a clean point in time
Have system owners confirm each service works before go-live
Reset passwords and keys if credentials may be compromised
Watch restored systems closely for errors or reinfection

Testing and Review

Run a test restore of sample files every month
Run a full disaster recovery test or tabletop exercise every year
Measure actual recovery times against your RTO and RPO
Hold a lessons-learned review after every test or real incident
Update the plan after major system, staff or vendor changes

0 / 36 done

An IT disaster recovery plan answers three questions in advance: which systems must come back first, how much data you can afford to lose, and exactly who does what to restore them. Decide those before an outage, ransomware attack or site failure, because during one there's no time to work them out.

This checklist walks a small or mid-sized IT team through building that plan: setting recovery time and recovery point objectives, protecting backups so an attacker can't delete them, writing step-by-step runbooks, and then proving it all works with restore tests. It sits alongside a wider business continuity plan, which covers people, premises and suppliers.

The structure follows the contingency planning process in NIST Special Publication 800-34, the US government's widely used guide to IT contingency planning. Adapt the targets to your own systems; a plan nobody has tested is only an assumption.

FAQ

What is the difference between RTO and RPO?

The recovery time objective (RTO) is how long a system can be down before the impact is unacceptable. The recovery point objective (RPO) is how much data, measured in time, you can afford to lose. A four-hour RPO means backups must run at least every four hours.

What is the 3-2-1 backup rule?

Keep at least three copies of your data, on two different types of storage, with one copy off-site. Many teams now add an immutable or offline copy as well, because ransomware often tries to delete or encrypt connected backups first.

How is disaster recovery different from business continuity?

Disaster recovery focuses on restoring IT systems and data. Business continuity is the wider plan for keeping the whole organisation running, including staff, premises, suppliers and customer communication. A disaster recovery plan is one part of business continuity.

How often should a disaster recovery plan be tested?

Test at least once a year and after any major change, such as a new system, a cloud migration or a change of backup provider. Restore individual files more often, for example monthly, to confirm backups are actually usable.

Built from public guidance and kept up to date — how we write our checklists. Spotted a mistake? Tell us.