Most businesses have backups. Far fewer have a plan that says exactly how they would get running again after a ransomware attack, a failed server, a cloud outage or a fire, and fewer still have tested that plan. The difference only becomes visible on the worst day of the year.
A disaster recovery (DR) plan is a formal document with detailed instructions for restoring IT systems and data after an unplanned incident. This guide covers what the plan should contain, how to set recovery targets using RTO and RPO, and how to test it before a real incident tests it for you.
Disaster recovery vs business continuity
The two are related but not the same. Business continuity is about keeping the whole organisation operating during disruption: people, premises, suppliers and communications. Disaster recovery is the IT part of that picture: restoring systems, applications and data. A good DR plan sits inside a wider business continuity approach.
RTO and RPO, explained
Two numbers drive every recovery decision.
- Recovery Time Objective (RTO): how long a system can be unavailable before the impact becomes unacceptable. It is your target for getting it back.
- Recovery Point Objective (RPO): how much data you can afford to lose, measured in time. If your RPO is four hours, you need recovery points at least every four hours.
Set them per system, not for the whole company. Your accounts system, email, phone system, file shares and line-of-business application will each have different tolerances. A simple tiering works well:
| Tier | Example systems | Typical approach |
|---|---|---|
| Critical | Systems that stop trading or client service | Shortest RTO and RPO; replication or rapid failover |
| Important | Systems people need within the working day | Frequent backups with tested restores |
| Deferrable | Systems that can wait a few days | Standard backups, restored after the higher tiers |
Shorter targets cost more to achieve, so agree them with the people who run the business, not just with IT.
What a DR plan should include
- Scope and assumptions: which systems, sites and scenarios the plan covers.
- Roles and contacts: who declares a disaster, who leads recovery, and contact details for staff, suppliers, your IT provider and your insurer.
- System inventory and dependencies: what runs where, and what each system depends on, such as identity, network, licensing and other applications.
- Recovery priorities: the order systems come back, with an RTO and RPO for each.
- Backup and replication details: what is backed up, how often, where the copies are and how long they are kept.
- Step-by-step runbooks: recovery instructions clear enough for someone under pressure to follow.
- Activation criteria: when an incident becomes a disaster and the plan is invoked.
- Communication plan: how staff, clients and suppliers will be told, including if email itself is down.
- Offline access: copies of the plan, key documentation and emergency access arrangements that do not depend on the systems that might fail.
- Return to normal: how you move back to primary systems once the cause is fixed.
- Testing schedule and change log: when the plan is tested and how it is kept up to date.
Plan for the incidents you cannot ignore
- System and hardware failure: failed servers, storage or network equipment.
- Cyberattack: ransomware, malicious access or data corruption that disables core systems.
- Cloud or supplier outage: a dependency on a cloud platform, telecoms provider or software vendor.
- Power, site or natural event: losing access to an office, a utility or a whole location.
Ransomware changes the rules
Modern ransomware often looks for backups first. Plan on the assumption that attackers will try to delete or encrypt them.
- Follow the 3-2-1 principle: at least three copies of important data, on two different types of storage, with one copy offsite.
- Keep at least one copy immutable or offline, so it cannot be altered from the network.
- Restore into a clean, isolated environment and confirm the restore point predates the compromise.
- Preserve evidence for investigation before wiping affected systems.
- Remember your obligations: where personal data is involved, GDPR requires notifying the Data Protection Commission without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to result in a risk to individuals.
Do not forget the cloud
Cloud services such as Microsoft 365 are highly resilient, but resilience is not the same as backup. Accidental deletion, a compromised account or a malicious insider can still remove data, and built-in retention features are not a substitute for an independent, tested backup. Include cloud services in your plan alongside on-premise systems.
How to test your plan
An untested plan is a theory. Build up through these levels:
- Walkthrough: the team reads the plan together and checks it is complete and current.
- Tabletop exercise: talk through a realistic scenario, such as “ransomware encrypted the file server at 9am”, and test decisions, roles and communication.
- Restore tests: actually restore a file, a mailbox, a database or a whole server, and time it against the RTO.
- Failover test: run a critical system from its recovery location under controlled conditions.
Record the actual recovery times, compare them with your targets, fix the gaps and update the plan. Test at least once a year, run restore tests more often, and retest after significant changes such as a migration, a new system or a new office.
Frequently asked questions
We have backups. Isn’t that enough?
Backups are essential, but they are only one part of recovery. Without priorities, runbooks, roles and tested restores, a business can have perfect backups and still take far too long to recover.
How often should backups run?
Often enough to meet each system’s RPO. A system with a one-hour RPO needs recovery points at least every hour; one that can lose a day’s data can be backed up daily.
Who should own the DR plan?
A named person in the business, supported by IT. The business decides what matters and how quickly; IT designs and runs the recovery.
Would your recovery plan work tomorrow?
Everything IT provides disaster recovery planning and testing for cloud, on-premise and hybrid environments. We assess critical services and dependencies, define recovery objectives, build the recovery architecture and procedures, and test the plan under controlled, realistic conditions, then keep it aligned as your business changes.