business_continuity_planning v1.0.0

name: business_continuity_planning description: "Build a business continuity plan end to end: run a business impact analysis, set MTD, RTO, RPO and minimum operating levels, choose recovery strategies that can actually meet those targets, write the plan, and prove it with exercises. Use when someone asks for a business continuity plan, a BIA, recovery objectives, continuity strategies, plan activation criteria, a tabletop or functional exercise, or a plan review after a disruption, a reorg, a new system, or a supplier change."

Business Continuity Planning

Purpose

A continuity plan answers four questions before a disruption forces them: what must keep running, how long can it be down, how will we run it another way, and who decides. This skill builds that plan in the order the standards use, from impact analysis to a tested, maintained document.

The frame follows ISO 22301 for the management system and NIST SP 800-34 for contingency planning steps. Ready.gov and FEMA guidance supply the practical plan contents: impact analysis, strategies, manual workarounds, incident management, training and exercises, and scheduled maintenance.

Scope note: this skill covers business continuity for whole functions and processes. An IT disaster recovery plan for one system, an emergency response plan for life safety, and a crisis communications plan are separate documents. The continuity plan references them and states where each one starts.

Workflow

1. Set scope, sponsor, and the decision rule

• Name an executive sponsor and a plan owner. The owner maintains the plan. The sponsor approves objectives and spends money on strategies.
• Write the scope in one paragraph: sites, functions, products or services, and systems in scope, plus what is explicitly out.
• List interested parties whose needs set limits: customers under contract, regulators, insurers, key suppliers. Record any contractual or regulatory recovery requirement verbatim, with its source.
• Agree the decision rule now: recovery targets come from impact evidence, not from what the current backup tool happens to do.

2. Run the business impact analysis

Work function by function, not system by system. Full method in references/bia-method.md, worksheet in assets/bia-worksheet.md.

For each function, record:

• What it delivers, who receives it, and what stops if it stops.
• Impact over time at set points (for example 4 hours, 24 hours, 72 hours, 1 week, 2 weeks) across four kinds: financial, operational, legal or regulatory, and reputational or customer harm. Use the owner's own figures and mark estimates as estimates.
• Dependencies: people and single-person knowledge, systems and data, facilities, equipment, suppliers and their sub-suppliers, and other internal functions.
• Peak periods when impact is worse, such as payroll day, month end, or a shipping deadline.

Interview the function owner, then cross-check with finance and with the teams that supply its dependencies. An owner who rates everything critical has not finished the analysis.

3. Set recovery objectives from the impact curve

For each function, set four numbers and write the reasoning next to each one:

• MTD, maximum tolerable downtime: the total time the function can be unavailable before the harm becomes unacceptable. Read it off the impact curve at the point where impact crosses the agreed threshold.
• WRT, work recovery time: time after systems return to verify data, clear the backlog, and resume normal work.
• RTO, recovery time objective: time allowed to restore the supporting service. It must satisfy RTO + WRT must be less than or equal to MTD. Setting RTO equal to MTD leaves no time to verify or catch up, and the plan fails on paper before it fails in practice.
• RPO, recovery point objective: the most data loss the function can accept, measured in time. RPO sets the backup or replication interval: the interval must be shorter than the RPO, with margin for a failed backup.
• MBCO, minimum business continuity objective: the reduced level of service the function will deliver during recovery, stated in units the owner recognises, such as orders processed per day or calls answered.

Run bin/bia_check.py on the finished table. It flags any function where RTO + WRT exceeds MTD, where the backup interval exceeds RPO, and where a dependency has a longer RTO than the function it supports.

4. Do the risk assessment separately

The BIA says how bad a disruption is. The risk assessment says what could cause one and how likely it is. Keep them as separate outputs, as ISO 22301 clause 8.2 requires a documented process for both.

• List threats per dependency: facility loss, system failure, supplier failure, staff unavailability, cyber incident, utility loss, severe weather where relevant.
• Rate likelihood and impact using one consistent scale, record existing controls, and note where a single point of failure sits.
• Feed the output into strategy choice. Do not let a low likelihood rating erase a function with a short MTD. Low likelihood and short MTD together argue for a cheap workaround, not for nothing.

5. Choose a strategy per function, then cost it

Pick from real options and reject any option that cannot meet the RTO and MBCO from step 3:

• Alternate way of working: manual workaround with printed or offline forms, a reduced service, deferring non-critical work, or splitting the function so the critical part runs first.
• Alternate place: work from another site, work from home, a contracted work-area recovery site, or a reciprocal arrangement with another organisation.
• Alternate people: cross-training, documented procedures a deputy can follow, succession for key roles, contingent staff agreed in advance.
• Alternate technology: redundant systems, cloud failover, spare hardware, a second network connection, backup power.
• Alternate supply: a qualified second supplier, buffer stock sized to cover the supplier recovery time, substitute inputs approved in advance.
• Transfer: insurance or a contract that shifts cost. Transfer pays bills. It does not restore service, so it never counts as the whole strategy.

For each chosen strategy record: what it delivers against the MBCO, how long activation takes, what it costs to keep ready and what it costs to use, what it depends on, and the gap if activation time plus WRT exceeds MTD. A strategy with an unclosed gap goes back for a different choice or a sponsor decision to accept the risk in writing.

6. Write the plan so a deputy can run it

Use assets/bcp-template.md. A usable plan has:

• Activation criteria and who can activate, including a passive trigger: predetermined conditions under which the team acts when the named decision maker cannot be reached.
• The team: roles, named people, deputies, and current contact details held in a separate controlled list.
• First-hour actions in order, then recovery steps per function in priority order (shortest MTD first).
• Communication steps: who tells staff, customers, suppliers, and regulators, with draft wording prepared in advance and a rule that only approved wording goes out.
• Manual workarounds with the forms and supplies they need, and where those are stored.
• Return to normal: criteria for standing down, backlog clearance, and reconciliation of work done by workaround.
• Appendices: dependency map, supplier and vendor contacts, related plans, revision history, distribution list.

Store copies where they survive the disruption the plan is about: an accessible copy outside the primary systems, and a printed copy at the alternate location. A plan that lives only on the server it is meant to recover is not a plan.

7. Test on a ladder, cheapest proof first

Full scripts and scoring in references/exercise-guide.md.

1. Desk check: owners review their sections for accuracy. Catches stale contacts and dead procedures. Proves nothing about execution.
2. Tabletop: a facilitator walks the team through a scenario with timed injects. Tests decisions, roles, and activation judgement.
3. Functional test: one component runs for real, such as restoring a backup, sending the notification cascade, or processing work by the manual workaround for an hour.
4. Simulation: several components together under simulated conditions.
5. Full-scale exercise: full activation and mobilisation. Highest proof, highest cost and disruption, so earn your way up the ladder first.

Record every exercise in assets/after-action-template.md: objective, what was timed, measured recovery time against RTO, gaps found, owner and date for each fix. An exercise with no gaps recorded was not looking hard enough or was too easy.

8. Maintain on triggers, not just on a calendar

Review at least annually, and immediately when any of these change: a function, a system, a supplier, a site, key staff, a contract, or a regulation. Also review after every real activation and every exercise. The owner updates the plan, reissues it under version control, recalls old copies, and logs the change in the revision history. Re-run the BIA when the business changes shape, not on the same annual tick by habit.

Worked Example

A small distributor, order fulfilment function. Impact interview: at 4 hours, delayed shipments and overtime. At 24 hours, contractual penalties start and two large customers can cancel. At 72 hours, cancellations are likely and cash flow is hit.

• MTD set at 24 hours, where penalties and cancellation risk start.
• WRT estimated at 6 hours to reconcile paper picking records and clear the backlog.
• RTO therefore must be 18 hours or less. The warehouse system restore was quoted at 24 hours, which fails the check.
• Strategy chosen instead: manual picking from a printed stock report produced each morning, at an MBCO of 60 percent of normal order volume, plus next-day restore of the system in parallel. Activation time 2 hours, inside the RTO.
• RPO set at 24 hours for order data because the printed report is daily, and the owner accepted losing same-day order edits with a phone confirmation workaround.
• Functional test: the team picked real orders from the printed report for one hour. Measured rate matched the MBCO. One gap found: the report did not show bin locations added that week. Fix: add bin location to the report layout, owner named, retested the next month.

Every number above is an example with stated assumptions, not a benchmark for other organisations.

Output Contract

Every engagement produces:

1. BIA table using assets/bia-worksheet.md: function, impact over time, dependencies, MTD, RTO, RPO, WRT, MBCO, priority order.
2. Strategy sheet per critical function: chosen option, activation time, readiness cost, use cost, remaining gap or written risk acceptance.
3. The plan using assets/bcp-template.md, completable by a deputy without the author in the room.
4. Exercise record using assets/after-action-template.md, with measured times against targets.
5. Maintenance log entry: review date, triggers checked, version issued, old copies recalled.

Operating Rules

1. Objectives come from impact evidence. Never set an RTO by copying what a vendor brochure promises.
2. RTO plus WRT must fit inside MTD. If it does not, change the strategy or get the sponsor to accept the gap in writing. Do not quietly edit the numbers to fit.
3. Every critical role has a named deputy, and every single-person dependency appears in the BIA as a risk.
4. A strategy that has never been tested is recorded as untested in the plan. Do not describe it as proven.
5. Insurance is cost transfer, not recovery. It never appears as the sole strategy for a critical function.
6. Keep personal contact details in a separate controlled list referenced by the plan, not pasted into every copy.
7. During a real activation, life safety comes before continuity. The emergency response plan runs first where people are at risk.
8. No invented figures. Impact numbers come from the owner or finance, downtime costs are labelled as estimates with their basis, and any figure that cannot be sourced is left out.
9. Write in plain language a tired deputy can follow at 3 a.m. Short steps, in order, with names and locations filled in.