Article · Continuity
IT disaster recovery planning, step by step
A disaster recovery plan answers one question before it becomes urgent: if our systems go down tomorrow, what do we restore first, how, by whom and how fast? This guide walks through building a plan that a small or mid-sized organization can actually maintain and use.
- Published
- 7 min read
On this page
Key takeaways
- Disaster recovery (DR) is the IT part of business continuity: restoring systems and data after a disruption.
- A business impact analysis identifies which processes matter most and how long each can tolerate an outage.
- Recovery time objective (RTO) and recovery point objective (RPO) translate business tolerance into technical targets.
- Runbooks turn the plan into step-by-step instructions someone else can follow under pressure.
- Tabletop exercises and technical restore tests show whether the plan works and keep it current.
Disaster recovery, business continuity and incident response
These terms overlap, so it helps to separate them. Business continuity planning covers how the whole organization keeps operating during a disruption: alternate workspaces, manual workarounds, supplier arrangements and communications. Disaster recovery is the technology component of that plan: bringing systems, applications and data back. Incident response covers how you detect, contain and investigate a security event such as ransomware or a compromised account.
In a cyber attack all three run at once. Incident response determines when it is safe to restore, disaster recovery performs the restoration, and continuity planning keeps clients served in the meantime. A good DR plan references the other two rather than trying to replace them.
Start with a business impact analysis
A business impact analysis (BIA) is a structured conversation with the people who run the business. It is the foundation of every recovery decision.
List critical processes
Identify the activities that generate revenue, serve clients or meet obligations, such as invoicing, payroll, scheduling, client file access and email.
Map dependencies
For each process, list the applications, data, devices, network services, identities and third parties it relies on. Include easily forgotten items like DNS, the internet connection, multifactor authentication and a payment processor.
Estimate impact over time
Ask what happens after one hour, one day and one week without each process, considering financial, client, contractual, legal and reputational effects.
Set tolerances
Agree the maximum tolerable downtime for each process and how much data the business could afford to re-enter or lose.
Rank and sign off
Group systems into recovery tiers and have leadership approve the priorities, because they will drive both the plan and the budget.
RTO and RPO in practical terms
Recovery time objective (RTO)
How long a system can be unavailable before the impact becomes unacceptable. An RTO of four hours means the recovery approach must realistically restore the system within four hours, including the time to notice the problem and decide to act.
Recovery point objective (RPO)
How much data, measured in time, you can afford to lose. An RPO of one hour requires backups or replication at least hourly; nightly backups imply losing up to a day of work.
Tiering
Not every system needs the same targets. Tier 1 might be identity, email and the core line-of-business application; Tier 3 might be archives that can wait several days.
Cost follows targets
Shorter RTOs and RPOs cost more, through replication, standby infrastructure or higher-tier services. The BIA lets the business choose targets with that trade-off in view.
Choosing recovery strategies
Once targets are set, choose a recovery approach for each tier and confirm it can meet them.
- Restore from backup to existing or replacement hardware: lowest cost, longest recovery time, suitable for lower tiers.
- Restore or fail over to cloud infrastructure: backup platforms that can boot protected servers in a cloud environment shorten recovery without a second office.
- Replication to standby systems: near-current copies ready to start, used where RTO and RPO are short.
- Software-as-a-service resilience: Microsoft 365 and other SaaS platforms remove infrastructure recovery from your plan but still require data backup, identity recovery and access planning.
- Clean-room recovery for ransomware: an isolated environment where restored systems are scanned and validated before being reconnected, so you do not restore the attacker along with the data.
- Manual workarounds: paper forms, phone trees or read-only exports that keep critical processes moving while systems are restored.
Writing runbooks people can follow
A runbook is a step-by-step procedure for recovering a specific system or handling a specific scenario. It should be usable by a competent technician who has never touched that system, at two in the morning, under stress. That means exact locations of backups, the accounts and where their credentials are stored, the order of operations, how to validate success, and who to call if a step fails.
Order matters. Identity usually comes first, because nothing else can be administered without working admin accounts and MFA. Network and DNS follow, then core data and applications, then lower-tier systems. Record dependencies explicitly so nobody spends an hour restoring an application whose database server is not yet back.
Store runbooks where they remain available during the disaster: a printed copy, an offline encrypted copy, or a separate cloud location that does not depend on your primary tenant. Include an up-to-date contact list for staff, your IT provider, internet and phone carriers, key software vendors, your cyber insurer and your bank.
Roles and communications
Assign clear roles: an incident lead who makes decisions, a technical lead who directs recovery, a communications lead who updates staff, clients and suppliers, and a scribe who records decisions and timings. In a small business one person may hold more than one role, but each role should have a named backup.
Prepare communication templates in advance for staff, clients and suppliers, and agree which channels you will use if email and Teams are unavailable. In a security incident, check with your insurer and legal advisers before making external statements, since wording can matter for both privacy obligations and insurance claims.
Test the plan with tabletop exercises and technical drills
An untested plan is a hypothesis. Two kinds of testing complement each other.
Tabletop exercise
Gather the decision makers for an hour or two and walk through a realistic scenario, such as ransomware discovered on a Monday morning or a fire that closes the office. A facilitator introduces developments and the group talks through decisions using the plan. Gaps surface quickly: missing contacts, unclear authority, assumptions about backups.
Technical recovery test
Actually restore a system from backup in an isolated environment and time it against the RTO. Validate with a business user that the data is complete and the application works.
After-action review
Record what worked, what did not and who will fix each gap by when. Update runbooks immediately while details are fresh.
Maintain
Review the plan at least annually and after significant changes such as a new application, office move, provider change or staff turnover in key roles.
Check your cyber insurance policy
Many cyber insurance policies set conditions on how incidents are handled, such as notifying the insurer promptly and using approved response firms. Read your policy and reflect its requirements in the plan so recovery decisions do not jeopardize coverage.
Frequently asked questions
How long should a disaster recovery plan be?
Long enough to be usable and no longer. Many small businesses work well with a short plan document covering priorities, roles and contacts, plus separate runbooks for each critical system.
What is the difference between RTO and RPO?
RTO is how quickly a system must be restored. RPO is how much recent data you can afford to lose. A system might need to be back within a day but lose no more than an hour of data.
Do we need a DR plan if everything is in Microsoft 365?
Yes, though it will be simpler. You still need to recover from deleted or encrypted data, a compromised admin account, loss of devices or an internet outage, and you need to know who decides and how staff keep working.
How often should we run a tabletop exercise?
At least once a year is a reasonable rhythm for most small and mid-sized organizations, with an additional exercise after major changes to systems, providers or key staff.
Related services
Products and packages
Build a recovery plan you can test
We can facilitate a business impact analysis, set realistic recovery targets, write runbooks for your critical systems and run a tabletop exercise with your leadership team.