Disaster Recovery (DR) is the smallest, most operational sibling of the four emergency plans. Where the Emergency Action Plan covers the first ten minutes (evacuate), and the Business Continuity Plan covers the first week (keep serving customers), the DR Plan covers the technical recovery of the systems that make any of it work. For most small businesses this is a one-to-three-page document — vendor contacts, RTO/RPO targets, and the ten-step runbook a sysadmin or contractor follows on a Sunday afternoon to bring a critical line-of-business system back. Skip the binder; skip the diagrams; skip the annual post-mortem slide deck.
Pick your Tier 1 systems — and only your Tier 1 systems
A disaster recovery plan that covers every internal application is a plan nobody has time to maintain. Restrict the plan to the systems on the Tier 1 row of the Business Impact Analysis — the ones whose recovery-time objective is <4 hours, where customers hit them directly. For a typical small business that is one or two systems, not twenty. If you cannot name your Tier 1 systems in five minutes, the BIA is the document that needs work, not the DR plan.
Realistic RTO and RPO targets
RTO is how fast you need the system back; RPO is how much data you can afford to lose. For a Tier 1 customer-facing system, common-sense defaults for a small business are RTO: 4 to 8 hours and RPO: 15 to 60 minutes. That is achievable with offsite backups and a documented restore procedure. Targets tighter than that — sub-hour RPO, sub-30-minute RTO — usually require redundant hot-standby infrastructure that is outside a small-business budget. A DR plan with ambitious targets and no budget is a wish, not a plan.
The workbook the plan is built around
- System name and owner (one human, not a team).
- Tier (1/2/3) and the RTO/RPO target.
- Recovery strategy (warm standby, cold rebuild, manual workaround).
- Vendor contacts with after-hours numbers — host, MSP, ISP, software vendor.
- Runbook steps in order, with screenshots of key admin screens.
- Last-tested date; re-test every six months.
Backups that actually restore
Most small businesses have backups that have never been restored. The DR Plan changes that: for each Tier 1 system, the runbook ends with a quarterly restore drill to a sandbox machine, with a logged pass/fail. A backup is not a backup until you have recovered from it on a system other than the production host. Offsite is not optional — at least one copy of every backup lives at a geographically separate location from the production system (cloud object storage with versioning counts).
Vendor redundancy on the cheap
Redundancy does not require two of everything. For most small businesses, the right moves are: an out-of-band communication channel (everyone can be reached if the office internet is down), a documented alternate vendor for each Tier 1 dependency (a second MSP, a second ISP, a hosted alternative to the line-of-business app), and a hard-copy roster of who to call after hours. None of these are expensive; all of them are absent from most first-draft DR plans.
The two things to skip
- Skip a hot site. A functional cold-rebuild runbook documented in the plan is the small-business equivalent. You are not a bank; you are not running real-time trading systems.
- Skip a multi-page risk-matrix diagram for the DR plan. The risk register lives in the Business Continuity Plan; DR is execution, not analysis.
Testing the plan
Run an annual restoration drill against each Tier 1 system. For the systems that take longer to restore than the RTO target, the gap is real — feed it into the next quarter's work. A DR plan in a binder that has never been tested is a DR plan you do not have. The Business Toolkit's BIA worksheet and Contact Directory are useful scaffolds for the recovery workbook; combined with the Emergency Plan Bundle's DR Plan chapter, a small team can ship a usable plan in two afternoons.