A small-business IT disaster recovery plan is a short document that says which systems matter most, how long each can be down (RTO), how much recent data you can afford to lose (RPO), how you will restore them and in what order, who does what, and how you will test it. This article gives you a method and a template you can fill in over an afternoon.
Who this is for
This is for owners and part-time IT administrators of small organizations with no dedicated continuity manager. By the end you will have a one-page system inventory with recovery targets, a backup and restore design that matches those targets, a recovery order, a contact list, and a test calendar.
It does not replace a full business continuity plan. Ready.gov, the US government's preparedness site, notes that the IT plan should be documented within the business continuity plan. If your business already has one, this becomes a section of it.
Key terms
Microsoft's Azure Well-Architected Framework defines the recovery metrics as follows:
| Term | Definition |
|---|---|
| Recovery time objective (RTO) | The maximum acceptable time that an application can be unavailable after an incident |
| Recovery point objective (RPO) | The maximum acceptable duration of data loss during an incident |
| Mean time to recover (MTTR) | The time taken to restore a component after a failure is detected |
Those definitions come from a cloud architecture guide, but they apply to any business system. An RTO of four hours means you must be working again within four hours. An RPO of one day means that, in the worst case, you can lose up to a day of changes, so you need a backup at least that often.
Microsoft's guide also says that flows or workloads that are not thoroughly tested for recovery metrics should not have guaranteed targets, and that recovery targets can change as workloads are updated. Treat your targets as a hypothesis until a test proves them.
Step 1: Inventory your assets
Ready.gov's IT disaster recovery guidance begins with an inventory of hardware (servers, desktops, laptops and wireless devices), software applications and data. Build a table with one row per system:
| System | Owner | Location | Data it holds | Dependencies |
|---|---|---|---|---|
| Email and calendar | Office manager | Cloud | Mail, contacts | Internet, DNS, identity |
| File storage | IT admin | Cloud or file server | Documents | Identity, network |
| Accounting package | Finance lead | Cloud or server | Ledgers | Database, network |
| Line-of-business app | Operations lead | Server | Orders, customers | Database, network |
| Identity and sign-in | IT admin | Cloud | Accounts, MFA | Internet |
| Network and Wi-Fi | IT admin | Office | Configuration | ISP, power |
Include the things people forget: your domain registrar login, DNS hosting, licence keys, firewall configuration and the password manager's emergency access.
Step 2: Rank systems and set RTO and RPO
Ready.gov says that IT recovery priorities should match the business function priorities from a business impact analysis, and that the recovery time of an IT resource should match the recovery time objective of the process that depends on it. In plain terms, ask the people who use each system: if this were unavailable, what stops, and from what point does it hurt?
Use tiers so you are not negotiating system by system. The values below are placeholders to show the structure. Replace them with numbers the business owner agrees.
| Tier | Meaning | RTO (example) | RPO (example) |
|---|---|---|---|
| 1 | Business stops without it | Set by owner, for example hours | Set by owner, for example under an hour |
| 2 | Work is slowed but possible | Set by owner, for example one day | Set by owner, for example one day |
| 3 | Inconvenient | Set by owner, for example several days | Set by owner, for example a week |
Write the target next to each system in your inventory and note who approved it. Be realistic about cost: shorter RTO and RPO values need more infrastructure and more money, so the owner should see the trade-off.
Step 3: Design backups to meet the targets
Backups are what let you meet the RPO, and restore speed is what decides the RTO.
Ready.gov's data backup guidance covers identifying what data to back up, selecting and implementing backup procedures, scheduling and conducting backups, and periodically validating that data has been accurately backed up. It also says the business impact analysis should evaluate the potential for lost data and define the recovery point objective, and that the recovery time of an IT resource should match the recovery time objective of the process that depends on it. In practice that means comparing restore times with your RTO, which is the check most often missed. If a backup takes ten hours to restore and your RTO is four, the backup does not meet the target.
CISA's ransomware guide adds the security side:
- Maintain offline, encrypted backups of critical data. Many ransomware variants attempt to find and then delete or encrypt accessible backups.
- For cloud environments, consider whether a multi-cloud arrangement helps if all accounts under one vendor are affected.
- Immutable storage can protect data without a separate environment, but CISA advises using it with caution because misconfiguration can be costly.
- Regularly test the availability and integrity of backups in a disaster recovery scenario.
Practical rules that follow from this:
- Each Tier 1 system has a backup at an interval no longer than its RPO.
- At least one copy of that backup is offline or otherwise out of reach of an attacker who controls your network accounts.
- Backups are encrypted, and the key is stored separately from the backup.
- Someone is responsible for checking that jobs succeeded.
Related guides: offsite backup from a Synology NAS, Azure Backup for virtual machines and PostgreSQL backup with pgBackRest.
Step 4: Plan the recovery order and the rebuild
CISA recommends keeping "golden images" of critical systems (a preconfigured operating system and applications) that can be quickly redeployed, keeping spare hardware for rebuilding systems, and setting restoration priorities in advance from a predefined critical asset list that includes systems critical to health and safety or revenue.
Write the order out as numbered steps. A typical small-office order is:
- Network, internet connection and power, since everything else depends on them.
- Identity and sign-in, so people can authenticate.
- Communication: email and chat, so you can coordinate.
- Tier 1 line-of-business systems and their data.
- File storage.
- Remaining systems by tier.
Ready.gov also advises standardising hardware, which makes replication and reimaging easier, and keeping copies of software so programs can be reinstalled on replacement equipment. Store installers and licence information somewhere you can reach during an outage.
Step 5: People, communication and access
A plan fails if nobody knows who is in charge or the contact list is on the dead file server. Document:
- Who declares an incident and who leads recovery, with a named deputy.
- Contacts for staff, key customers, suppliers, the internet provider, the software vendors and your insurer, as phone numbers that do not depend on your systems.
- A communication template for staff and customers describing what is affected and when the next update is due.
- Where the plan is stored. CISA advises keeping a hard copy and an offline version of the incident response plan.
- Emergency access accounts for your cloud services, with credentials stored securely and tested.
Step 6: Test on a schedule
Ready.gov advises testing the plan periodically to make sure that it works, and periodically confirming that data has been accurately backed up. It points to NIST Special Publication 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, for structured testing.
Set a schedule you can keep. One workable pattern:
| Test | What you do | Frequency (your choice) |
|---|---|---|
| Restore check | Restore a sample file, mailbox item or database copy to a test location | Regular, such as monthly |
| System restore | Rebuild one Tier 1 system from backup in an isolated environment and time it | At least once a year |
| Tabletop exercise | Walk through a scenario with the team, such as a ransomware infection or a failed server | At least once a year |
| Contact check | Call the people on the contact list | Twice a year |
Record the time each test took and compare it with the RTO. If a test shows the target is unrealistic, change either the design or the target and record the decision.
Template
Copy the following into a document and fill in every field.
IT DISASTER RECOVERY PLAN - [Business name]
Version / date / owner:
1. SCOPE
Locations and systems covered:
2. SYSTEM INVENTORY AND TARGETS
System | Owner | Tier | RTO | RPO | Backup method | Backup location | Restore time (tested)
3. RECOVERY ORDER
1.
2.
3.
4. ROLES
Incident lead / deputy:
Technical recovery:
Communications:
5. CONTACTS (phone numbers that work offline)
Staff:
Vendors and ISP:
Insurer:
6. BACKUP RULES
Frequency per tier:
Offline / encrypted copy location:
Who checks job results, and how often:
7. TEST LOG
Date | Test type | Result | Measured time | Fixes needed
8. PLAN STORAGE
Hard copy at:
Offline copy at:Troubleshooting a plan that does not work
- Restore takes longer than the RTO. Reduce the amount to restore at once, restore the highest-priority data first, change the backup design, or agree a longer RTO with the owner.
- Backups succeed but restores fail. Test restores more often, check encryption keys and keep installers for the backup software itself.
- Nobody can find the plan during an outage. Print it and store an offline copy.
- The inventory is out of date. Add updating it to your change process, for example when you add a system or leave a supplier.
Checklist
- Inventory complete, including logins, licences and DNS.
- Tier, RTO and RPO set and approved for every system.
- Backup interval at or below RPO for Tier 1 systems.
- One offline, encrypted copy of critical data.
- Restore time measured and compared with RTO.
- Recovery order written down.
- Roles and contacts recorded, with a hard copy of the plan.
- Test calendar set, and results logged.
References
- Azure Well-Architected Framework, define reliability targets: https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics
- Ready.gov, IT disaster recovery plan: https://www.ready.gov/it-disaster-recovery-plan
- CISA, StopRansomware guide: https://www.cisa.gov/stopransomware/ransomware-guide
Comments
Questions and tips are welcome. Comments are checked by the EpiFive team before they appear; please do not share passwords, phone numbers or other private details.