A disaster recovery plan is the documented procedure for getting your IT systems and data back after something takes them down — a dead server, a ransomware attack, a flooded comms room, a cloud outage. It answers four questions for every system: what gets recovered, in what order, how quickly, and by whom.
It is the IT-focused part of a wider business continuity plan. Here is how to build one that will actually work when you need it.
Step 1: Inventory what you have
You cannot recover what you have not written down.
- Every system: line-of-business apps, email, file storage, accounting, the website, phones
- Where each one lives — a physical server, a VM, a cloud service, a workstation under someone’s desk
- The data each holds and where its backups go
- Dependencies — system B needs the database on system A; everything needs the network and internet
- Vendor and support contacts, licence keys, and admin credentials (stored securely, and reachable when systems are down)
Step 2: Set RTO and RPO for each system
Not every system deserves the same speed of recovery. For each one, agree with the business:
- Recovery Time Objective — how long it can be down
- Recovery Point Objective — how much data you can afford to lose
This is the core of the plan — it drives the backup frequency and the recovery method. Our full explainer: RTO vs RPO.
Step 3: Backup and replication strategy
Recovery is only as good as the copies you can restore from. Follow the 3-2-1 rule: three copies, two media types, one offsite, plus one immutable copy ransomware cannot reach, and zero untested restores. For low-RTO systems, add image-based backup or replication to a standby so you fail over rather than rebuild.
Step 4: Write the recovery procedures
For each system, or group of systems, a short procedure:
- Preconditions — what must be working first (network, domain controller, internet)
- Steps — where to restore from, to what target, in what order
- Who does it, and who is the backup person
- How to verify it worked — a specific check, not “it looks fine”
- Rough time expected, so you know if it is going wrong
Include the recovery order: identity and network first, then core data, then the systems that depend on them.
Step 5: Roles and communication
- Who declares a disaster and starts the plan
- Who runs the technical recovery
- Who keeps management and staff informed
- Contact details for the IT provider, key vendors and ISPs, stored offline
Step 6: Test it
- Restore tests — monthly or quarterly, pull real files and a database back from backup
- Failover test — at least yearly, stand a critical system up from scratch on alternate infrastructure
- After changes — retest when you add or move a major system
- Record the result and the recovery time, and fix what failed
Plan outline (copy this)
- Purpose and scope
- System inventory — table: system, location, data, backup target, dependencies
- RTO / RPO per system
- Backup and replication setup
- Recovery procedures — one per system or group, in recovery order
- Roles and contacts (offline copy)
- Communication plan
- Test schedule and results log
- Revision history
Cloud and hybrid considerations
Cloud services have their own resilience, but you are still responsible for your data, your configuration and your accounts — and “the provider had an outage” is not a recovery plan. Keep an independent backup of cloud data (including Microsoft 365), and know how you would operate if a provider is unavailable for a day. See cloud vs on-premise for where each model’s risks sit.
Common gaps
- Backups run but restores are never tested
- The plan and credentials only exist on the systems they are meant to recover
- No recovery order, so teams work on the wrong system first
- Microsoft 365 assumed to be “backed up” — it is not, by default
- One person knows how everything works
When to get help
Building and testing a DR plan is exactly what a managed IT provider does. We inventory your environment, set targets with you, put 3-2-1 backups and recovery in place, and test on a schedule — part of our managed IT support and backup and disaster recovery services.
Want a disaster recovery plan you have actually tested? See our backup and disaster recovery service or talk to our Edmonton team.
Frequently asked questions
What is a disaster recovery plan?
A documented plan for restoring your IT systems and data after a disruptive event – a failed server, ransomware, a site loss. It defines what gets recovered, in what order, how fast, and by whom.
What should a disaster recovery plan include?
An inventory of systems and data, recovery time and recovery point targets for each, the backup and replication setup, step-by-step recovery procedures, roles and contacts, and a testing schedule.
How is a disaster recovery plan different from a backup?
Backups are one input. The DR plan is the whole procedure – where backups are, how to rebuild or fail over each system, in what order, and how to confirm it worked. A backup with no plan and no tested restore is not disaster recovery.
How often should a disaster recovery plan be tested?
Restore tests monthly or quarterly, and a fuller failover test at least once a year. Test after any major infrastructure change. Untested recovery is an assumption, not a plan.