A disaster recovery plan is the IT half of staying in business. It lists the systems you run, says how fast each must come back and how much data each can lose, records how the data is protected, and gives the steps to restore it in a form someone other than your usual administrator can follow. For a small business the whole thing fits in 8 to 12 pages plus a short runbook for each critical system. The template below covers the eight components every DR plan needs, then fills them in for a fictional 22-person design office.
It sits under your business continuity plan, which sets the targets this plan must meet. If that does not exist yet, start with our business continuity plan template. For how the two documents split the work, see business continuity plan vs disaster recovery plan.
The components of a disaster recovery plan
- Scope and plan control
- System inventory with recovery tiers
- Recovery targets (RTO and RPO) for each system
- Backup and replication method for each system
- Activation, contacts and escalation
- Recovery runbooks
- Testing schedule and results
- Return to normal and plan upkeep
NIST SP 800-34, the federal contingency planning guide, arranges the same material as supporting information, an activation and notification phase, a recovery phase and a reconstitution phase, plus appendices. If an auditor or customer expects that structure, the mapping is direct.
The template
Square brackets mark what you fill in. Tables can live in a spreadsheet, as long as they get printed with the plan.
1. Scope and plan control
[Sites, systems and cloud services covered] [Plan owner, usually the IT lead or your managed service provider, and the business sponsor who approves targets] [Version, approval date, next review] [Copies: one printed, one offline, one somewhere that does not depend on your own systems]
2. System inventory and tiers
| System | What it supports | Tier | Where it runs | Depends on | Owner |
|---|---|---|---|---|---|
| [name] | [activities from the BCP] | [0 to 3] | [office, data center, cloud, SaaS] | [identity, network, license server, other systems] | [name] |
Suggested tiers for a small firm: tier 0 is foundation (internet, firewall, sign-in and email, DNS), tier 1 is needed the same day, tier 2 within three days, tier 3 within two weeks. Include SaaS. You do not recover the vendor's platform, but you do own your data in it and your plan for the days it is down; our guide to building a SaaS dependency inventory covers what to record.
3. Recovery targets
| System | RTO | RPO | Source of the target | Last achieved RTO and RPO |
|---|---|---|---|---|
| [name] | [hours] | [minutes or hours] | [BCP activity it serves] | [from the last test, with date] |
A system inherits the tightest target of any activity it supports. Its RTO plus the time people need to check data and catch up must fit inside that activity's tolerance.
4. Backup and replication method
| System | Method | Frequency | Copies and where | Offline or immutable copy | Retention | Last restore test |
|---|---|---|---|---|---|---|
| [name] | [image, file, snapshot, replication, SaaS backup] | [hourly, nightly] | [local, cloud, off site] | [yes or no, and how] | [days] | [date and result] |
At least one copy of every tier 0 and tier 1 system should be one that an attacker holding your admin passwords cannot alter or delete. Our piece on immutable backups and clean-room recovery explains the options.
5. Activation, contacts and escalation
[Who can declare a disaster, and the criteria] [Who is told, in what order, and by which channel if email is down] [Vendors: internet provider, managed service provider, software support, with account numbers and support hours] [Break-glass access: where emergency credentials are kept and who can retrieve them; never write passwords in the plan itself]
6. Recovery runbook skeleton
Write one per tier 0 and tier 1 system, two to four pages each:
- Preconditions. What must be working first (power, network, sign-in, the license server).
- Decision. Restore in place, or somewhere else? Criteria for each.
- Restore steps. Numbered, with the exact backup job or snapshot names and where the installation media and keys live.
- Validation. A named business user completes a real task, such as opening a current project file.
- Catch-up. Who re-enters work done since the recovery point, and how.
- Record. Start time, finish time, problems, achieved RTO and RPO.
7. Testing schedule
| Test | How often | Who | Pass means |
|---|---|---|---|
| Backup job alerts reviewed | Weekly | IT | Every failure followed up within one business day |
| Single-file restore | Monthly | IT | File opens and matches the expected date |
| Full restore of each tier 1 system | Once or twice a year | IT and a business user | Within RTO, business user signs off |
| Ransomware tabletop | Yearly | IT and business owners | Gaps logged with owners and dates |
| Contact and vendor list check | Quarterly | Plan owner | Every number answered or corrected |
8. Return to normal and upkeep
[How you move back from temporary systems, and how data created in the meantime is reconciled] [Who decides the disaster is over] [Events that force a plan update: new system, new provider, office move, staff change, every test and real incident]
Readiness kit
- Synology DS223 2-bay NAS2 drive baysShop on Amazon
- SanDisk Extreme 2TB portable SSD2 TBShop on Amazon
- APC Back-UPS Pro 1500VA (BR1500MS2)1500 VA / 900 WShop on Amazon
As an Amazon Associate I earn from qualifying purchases. All picks
Worked example: a fictional 22-person design office
The firm is invented and the figures are illustrative. It is a 22-person architecture and engineering office on one floor, with project files on a local file server, design software that checks out licenses from a small license server, and email, office apps and accounting in the cloud.
| System | Tier | RTO | RPO | Method |
|---|---|---|---|---|
| Internet and firewall | 0 | 4 hours | Not applicable | Second internet line over cellular; firewall configuration exported monthly |
| Cloud email, office apps and sign-in | 0 | Provider's | 24 hours | Third-party backup of mailboxes and cloud files, nightly |
| Design software license server | 1 | 4 hours | 24 hours | Nightly image to the local storage box, copied to the cloud |
| File server, 1.6 TB of project files | 1 | 8 hours | 1 hour | Hourly snapshots, nightly copy to the local box, nightly cloud backup, weekly offline drive |
| Cloud accounting | 2 | 3 days | Provider's | Monthly data export kept on the local box |
| Laptops (22) | 2 | 1 day per person | 24 hours | Files synced to cloud; standard image; two spare laptops |
The license server was the surprise. It is a modest virtual machine nobody thought about, but without it no one can open a drawing, so a restored file server is useless until the license server is back. It moved from tier 3 to tier 1 the day the office drew its dependency column. The file server's 1-hour RPO has a catch too: it holds only while the snapshots on the server itself survive. Restoring from the nightly copies, local or cloud, means losing up to a day of work.
Check the restore time before you trust the RTO
The file server's 8-hour RTO looked fine until the office ran the numbers in the backup and restore time calculator. Inputs: 1,600 GB of project files, 10 percent savings from compression and deduplication (so 1,440 GB actually moves), a 35 Mbps upload, a 300 Mbps download, 80 percent link efficiency and a 2 percent daily change rate.
- The first full cloud upload takes about 114 hours, or 4 d 18 h, so it has to start over a long weekend or be seeded on a shipped drive.
- Each night's changes, about 28.8 GB, upload in about 2 h 17 min.
- A full restore from the cloud takes about 13 h 20 min. That misses the 8-hour RTO by 5 h 20 min, before anyone has rebuilt a server or checked a file.
- To pull 1,440 GB back in 8 hours on transfer alone, the office would need a nominal download of about 500 Mbps.
Two cheaper fixes came out of the exercise. Restoring the active projects share first, about 400 GB or 360 GB after savings, takes about 3 h 20 min from the cloud and gets most of the office working. A local copy changes the picture entirely: the same 1,440 GB over gigabit Ethernet at 80 percent efficiency takes about 4 hours, provided the disks at both ends keep up.
Local copies
For a small office, the local part of a 3-2-1 setup (three copies, two kinds of media, one off site) is usually a two-bay network storage box with mirrored drives, plus a portable drive that is unplugged and taken off site on a rotation. The storage box gives you the fast restore. The portable drive is the copy that ransomware with network credentials cannot touch while it sits in a drawer. Mirroring protects against a failed drive, not against deletion or encryption, so snapshots on the box and the unplugged drive both earn their place.
Readiness kit
| Category | Pick | Why it is on the list | Link |
|---|---|---|---|
| Local backup (NAS) | Synology DS223 2-bay NAS | Mirrored local copies plus built-in cloud sync: the on-site leg of a 3-2-1 plan for a small office. | Shop on Amazon |
| Offline backup drive | SanDisk Extreme 2TB portable SSD | Fast, rugged drive for an offline copy; once unplugged, ransomware on the network cannot reach it. | Shop on Amazon |
We chose both from manufacturer specifications and published reviews and have not tested them ourselves. The storage box has two drive bays and ships without drives, and it can sync to a cloud account. The portable drive holds 2 TB over USB-C, enough for the example office's 1.6 TB of project files, though without much room to grow.
The simple version for very small offices
An office of one to ten people, running almost everything in SaaS, can keep the whole plan on two pages: every system and who administers it, where each one's data is backed up and how to restore it, the restore order, who to call (internet provider, IT support, bank), where the break-glass credentials are, and the date of the last test restore. Ready.gov's IT disaster recovery plan page covers the same ground in short public guidance.
Frequently asked questions
What are the main components of a disaster recovery plan?
A system inventory with tiers, recovery time and recovery point objectives per system, the backup and replication method, activation and escalation steps, recovery runbooks, a testing schedule and the steps back to normal. Scope and version control hold it together.
How often should a small business test its disaster recovery plan?
Restore a single file monthly and review backup alerts weekly. Do a full restore of each tier 1 system at least once a year, preferably twice, with a business user confirming it works. Retest after any major change to systems or providers.
Do cloud and SaaS services belong in the disaster recovery plan?
Yes. The provider recovers its platform, but your data, your sign-in access and your work during an outage are still yours to plan for. Record what each service holds, how to export or restore it, and what staff do meanwhile.
What is the difference between a disaster recovery plan and a backup policy?
A backup policy says what gets copied, how often and how long it is kept. A disaster recovery plan says how you get systems working again, in what order, by whom and within what time. Backups are one input to the plan, and a plan without tested restores is still a hope.
