Business Continuity Plan & Disaster Recovery Playbook

Business Continuity Plan & Disaster Recovery Playbook

A fire, a flood, a ransomware lockout, a power cut that lasts three days: the event is not the disaster. The disaster is the second week, when customers have gone elsewhere, staff have no instructions, and nobody can say what comes back first. A business continuity plan (BCP) answers those questions before the event. A disaster recovery plan (DRP) is the technical half: the steps that bring systems and data back. This playbook builds both, in that order — a recovery plan without a continuity plan restores servers for a business that has stopped answering the phone.

The Federal Emergency Management Agency reports that 40 percent of small businesses never reopen after a disaster — quoted here from the Small Business Administration's Office of Advocacy, which attributes it to FEMA, because FEMA's own business pages returned errors when opened for this article.

This playbook covers the continuity operation itself: the impact analysis, the recovery targets, the backup tiers, the alternate-site decision, the exercises, and the maintenance cadence. It is not the insurance product or breach response — the business-interruption-insurance-playbook covers the policy that pays for lost income, and the data-breach-response-playbook covers the first 72 hours after data is exposed.

Step 1: the business impact analysis

The business impact analysis (BIA) is the step that makes the rest of the plan honest. NIST SP 800-34 Rev. 1, section 3.2: the BIA correlates the system with the critical processes it supports, then characterizes the consequences of a disruption so the coordinator can set contingency requirements and priorities. It runs in three steps: determine the processes and their recovery criticality; identify the resources required to resume them; and set recovery priorities for the system resources.

For each process, record what breaks if it stops, who is affected, how long the business can tolerate it being down, and what it needs to restart. NIST's worked example, Figure 3-2, shows the shape of it, with notional times: Process Invoice: 1,000+ staff affected, 72 hours, 36-hour application server objective; Prepare Report: media announcing concerns, 30 hours, 24-hour web server objective; Create Budget: congressional insight, 36 hours, 12-hour database server objective; Respond to Inquiries: over 500 complaints, 36 hours, 30-hour desktop objective. The times are labeled notional — your numbers come from your process owners.

Two rules decide everything downstream: the recovery time objective must normally be shorter than the maximum tolerable downtime, because reprocessing the backlog takes time on top of the restore; and impacts must be expressed in units the business understands — staffing, overtime, fee-related costs. A BIA that ranks everything "high" has ranked nothing.

Step 2: the three numbers — MTD, RTO, RPO

NIST SP 800-34 Rev. 1, section 3.2.1, defines the three downtime terms that carry the whole plan. Maximum tolerable downtime (MTD) is the total time the system owner will accept for a process outage. Recovery time objective (RTO) is the maximum time a system resource can remain unavailable before unacceptable impact on other resources, supported processes, and the MTD. Recovery point objective (RPO) is the point in time, prior to a disruption, to which data can be recovered given the most recent backup copy — how much data loss the process can tolerate, not time down.

The RPO is a business decision about rework, not a technical decision about backup software.

Put a dollar figure on downtime before choosing any recovery method: the method is bought with the downtime it prevents. Take a stated example: an online retailer with 12,000,000 dollars of annual revenue, a 40 percent gross margin, 2,400,000 dollars of annual fixed costs, and 8,760 operating hours a year. Lost gross profit per hour is revenue times margin divided by operating hours; continuing fixed cost per hour is fixed costs divided by operating hours.

At 821.92 dollars per hour: an 8-hour outage costs 6,575.34 dollars; 24 hours costs 19,726.03 dollars; 48 hours costs 39,452.05 dollars; 72 hours costs 59,178.08 dollars. Price every recovery decision against that hourly figure.

Step 3: backup and recovery tiers

NIST SP 800-34 Rev. 1, section 3.4, ties the backup and recovery method to the impact level, and Table 3-2 gives the mapping.

The tier follows the BIA, not the budget: a cold-site strategy for a high-impact system accepts downtime the BIA already ruled unacceptable.

Backup policy is set by data criticality and by how often new information arrives, not by habit. NIST requires the policy to specify the minimum frequency and scope of backups — daily or weekly, incremental or full — the location of stored data, file-naming conventions, media rotation frequency, and the method for transporting data offsite. It is good business practice to store backed-up data offsite, and a commercial storage facility should be judged on five criteria: geographic area and the probability the same disaster hits it; accessibility and retrieval time; security of the shipping method, the facility, and the personnel; the environment; and cost. Backup tapes should be tested regularly to ensure data is stored correctly and files can be retrieved without errors — an untested backup is a rumor, not a recovery method.

Step 4: the alternate-site decision

For moderate- or high-impact systems, NIST requires a strategy to recover system operations at an alternate facility for an extended period; continuity functions must be sustained within 12 hours and for up to 30 days from an alternate site. Low-impact systems do not require an alternate site, though the organization may choose one. Three types: a dedicated site owned or operated by the organization; a reciprocal agreement with another entity; and a commercially leased facility. In operational readiness they rank as cold, warm, or hot. A cold site is space and infrastructure — power, telecommunications, environmental controls — with no equipment installed. A warm site is a partially equipped office space holding some or all of the system hardware, software, telecommunications, and power. A hot site is sized to the system requirements and configured with the necessary hardware, infrastructure, and support personnel. Two variations exist: mobile sites, transportable shells often delivered within 24 hours, and mirrored sites, fully redundant facilities with automated real-time mirroring, identical to the primary site.

Cost and ready-time run in opposite directions: the mirrored site is the most expensive but ensures virtually 100 percent availability; cold sites are the cheapest but may need substantial time to acquire and install equipment. Price the choice with the Step 2 downtime figure. Take a stated example: a hot site at 6,000 dollars a month against a cold site at 800 dollars a month, a cold-site RTO of 48 hours against a hot-site RTO of 1 hour, one disruption a year. The extra standby cost is 62,400 dollars a year. The avoided loss is the 48-hour cold-site downtime cost minus the 1-hour hot-site cost.

At one event a year the hot site loses 23,769.86 dollars against the cold site. The breakeven is 62,400 divided by 38,630.14, or 1.62 events a year: two disruptions a year, buy the hot site; one, buy the cold site and accept the 48-hour recovery. Re-run the numbers every year.

The RPO decision is priced the same way, on rework instead of downtime. Take a stated example: an order system taking 240 orders a day, or 10 an hour, at an average order value of 85 dollars. A backup every 4 hours leaves up to 40 orders to re-enter after recovery; a backup every hour leaves up to 10.

Tightening the RPO from 4 hours to 1 hour saves 2,550 dollars of rework per event. If hourly backups cost less than 2,550 dollars per expected event, they pay for themselves; if they cost more, the 4-hour RPO is the honest choice.

Step 5: test, train, exercise — the plan is not real until it runs

NIST SP 800-34 Rev. 1, section 3.5: a plan should be maintained in a state of readiness, with personnel trained to fulfill their roles, plans exercised to validate their content, and systems tested to ensure operability. Testing, training, and exercises run periodically, after organizational or system changes, after new guidance, or as otherwise needed. For each event, results go into an after-action report, and lessons learned feed back into the plan.

NIST SP 800-84 identifies two exercise types widely used in these programs. Tabletop exercises are discussion-based: personnel meet in a classroom or in breakout groups, a facilitator presents a scenario, and the discussion covers roles, responsibilities, coordination, and decision making. A tabletop deploys no equipment or other resources. Functional exercises validate operational readiness by having personnel perform their duties in a simulated operational environment — communications, notifications, equipment setup — up to full-scale exercises addressing all plan elements. Run the tabletop first: it finds the gaps in the document; the functional exercise finds the gaps in the people. Testing is a separate activity with quantifiable metrics — a call tree tested against its time limits, or power removed from a component — conducted as close to an operating environment as possible. Training runs at least annually; new appointees are trained shortly after appointment. NIST's standard: recovery personnel should be able to execute their roles without the plan document in hand.

Step 6: the maintenance cadence

A plan decays from the day it is signed. Systems, vendors, and staff change, and every change not reflected in the plan is a step the recovery team will take wrong. NIST SP 800-34 Rev. 1, section 3.6, requires review for accuracy and completeness at an organization-defined frequency or whenever significant changes occur, with contact lists reviewed more often and moderate- or high-impact systems reviewed more often still. Each review covers operational and security requirements, technical procedures, hardware and software, team and vendor contacts, facility requirements, and vital records.

Set the cadence in the plan itself: a full review every 12 months at minimum, a review within 30 days of any significant change, and a contact-list check every quarter. Changes are coordinated through the plan coordinator, recorded in a record of changes, and distributed under strict version control, with old pages returned in exchange for new ones. A copy of the plan is stored at the alternate site and with the backup media. ISO 22301, the international standard for business continuity management systems — second edition, October 2019, 21 pages, 155 Swiss francs, now under revision — requires the same discipline: plan, establish, implement, operate, monitor, review, maintain, and continually improve.

The build operation, start to finish

1. Name the plan coordinator and the continuity team, and give the coordinator authority to call the plan.
2. Run the BIA workshop with process owners; record each process, its impact, its maximum tolerable downtime, and its resource requirements.
3. Set MTD, RTO, and RPO per process and per system.
4. Price downtime per hour; use it to choose the backup tier and the alternate-site type.
5. Write the recovery strategies: backup method and frequency, offsite storage, alternate site, and the recovery sequence.
6. Write the plan document: activation criteria, call tree, notification and recovery procedures, reconstitution.
7. Run a tabletop exercise within 30 days; fix what it finds before the functional exercise.
8. Run a functional exercise within 90 days; fold the after-action lessons into the plan.
9. Train every person with a plan role at least annually; train new appointees shortly after appointment.
10. Set the maintenance cadence: full review every 12 months, review within 30 days of significant change, quarterly contact-list check, copy at the alternate site.

The key-person-insurance-buy-sell-agreement-funding-playbook covers the funding that keeps the business alive when a named person cannot work, the employee-handbook-policy-playbook carries the staff policies the continuity team enforces during a disruption, and the business-interruption-insurance-playbook prices the policy that pays for lost income while recovery runs. Run the finished numbers through the ROI calculator before signing the site contract.