Business Continuity Plan Table of Contents: An Annotated Sample Outline

A business continuity plan gets read properly about twice. Once by the person who approves it, and once by someone standing in a parking lot at 7 a.m. trying to work out who is supposed to call the landlord. The table of contents decides whether that second reader finds the answer in thirty seconds or gives up and starts improvising.

The outline below keeps a five-part skeleton that has circulated since the late 1990s, when FEMA's Project Impact (1997 to 2001) pushed communities to build disaster-resistant local economies and sample plan outlines were handed to small businesses by the stack: introduction, emergency response, continuity, restoration, maintenance. The skeleton has aged well. The contents have not. Those older versions assumed a fire or flood, backup tapes in someone's car trunk, and one building. A plan written now has to cover ransomware, a workforce that is already remote, systems owned by cloud providers, and a news cycle that starts before the evacuation ends.

Why the five parts still work

Each part answers a different question, for a different reader, at a different moment.

A section that helps none of those readers belongs in an appendix.

The annotated outline

Part 1: Introduction and planning basis

1.1 Purpose and scope. Name what is in and what is out: legal entities, sites, business lines, systems. Exclusions matter as much as inclusions: "excludes the Secaucus warehouse, which has its own plan" saves an argument at the worst possible time.

1.2 Objectives and priorities. List the prioritized functions and how long each can go unperformed before the damage becomes serious, with recovery time and recovery point objectives. These figures come from the business impact analysis. If yours stalled halfway (most do), see the guide to running a business impact analysis people actually finish.

1.3 Assumptions. Write down the assumptions that would sink the plan if they were wrong, and what happens if they are. Typical ones: staff can work remotely for ten business days; the primary cloud region stays up; key suppliers can deliver within 48 hours. A plan with no stated assumptions still has them, just hidden.

1.4 Recovery strategies at a glance. One paragraph each for remote work, a secondary office or work-area recovery seats, cloud failover, immutable and offline backups, manual workarounds, and alternate suppliers. Detail lives in Part 3.

1.5 Authority and version. Who approved the plan, when, the version number, and where the controlled copy lives.

Part 2: Emergency response

2.1 Evacuation and shelter-in-place. Routes, assembly areas (a primary and an alternate a block further away), floor wardens, and assistance for people with disabilities. Employers covered by OSHA's emergency action plan rule (29 CFR 1910.38) already need much of this in writing, so reference that plan instead of duplicating it.

2.2 Accounting for people. Headcount at the assembly point is the easy part. The hard part is everyone at home, on a train, or at a client's office. State how each group is accounted for and who reports the result.

2.3 Notification and escalation. Who is told, by whom, through which channel, how fast. Include thresholds: what a site manager decides alone and what goes to the crisis team.

2.4 Cyber incident first actions. Ransomware arrives without smoke. Say who decides to isolate systems, how the incident response retainer and outside counsel get engaged, and that nothing is wiped before evidence is preserved. Then hand off to the security incident response plan.

Part 3: Continuity operations

3.1 Teams and roles. Every role gets a primary and two alternates, because the first alternate is usually on vacation. Larger organizations borrow the Incident Command System's structure (command, operations, planning, logistics, finance) so roles make sense to first responders.

3.2 Invocation. Criteria for declaring a disruption, who can declare, and what declaration sets in motion: alternate sites, vital records recall, insurer notification. The working rule is "declare early, stand down cheaply." A false alarm costs an afternoon. A late declaration costs the first day.

3.3 Workplace and technology strategies. Activation steps and capacity for each strategy. Remote work is now the primary workplace strategy for most office functions, so cover the case where remote access itself is the casualty: VPN, identity provider, collaboration tools.

3.4 Vital records and data. Where records are, who can retrieve them, and how. Twenty-five years ago that meant a vault and a courier. Now it means knowing which SaaS platforms hold the data, whether you can export it, and who has break-glass administrator access independent of the corporate identity system.

3.5 Resource requirements by time band. What each function needs at four hours, 24 hours, 72 hours, and one week: people, seats, devices, applications, vendors.

3.6 Function-level procedures. One short section per critical function, owned by that function. Include the manual workaround: how invoices go out, how orders are taken, how payroll runs if its system is down.

3.7 Third parties and cloud services. Critical vendors, what they provide, contractual recovery commitments, escalation contacts. Add a procedure for when the vendor is the outage. The CrowdStrike Falcon update of 19 July 2024 left Windows machines unable to boot inside healthy data centers; plans that coped had a step for "our own tooling broke us."

3.8 Crisis communications. Audiences (staff, customers, regulators, media, investors), spokespeople, approval paths, and pre-drafted holding statements. The full playbook gets its own document; see writing a crisis communications plan before the cameras arrive.

Part 4: Restoration

4.1 Roles. Restoration shifts work toward facilities, IT infrastructure, finance, and insurance. Name those people; the team that ran the first 72 hours will need relief.

4.2 Triggers. When the organization moves from continuity mode to restoration mode, and who decides.

4.3 Damage assessment and salvage. Document damage before cleanup (photos, inventories, timestamps), coordinate salvage with restoration contractors, and work with the insurer's adjuster and the landlord on access, repairs, and the claim. Open a cost code on day one. For cyber events, the equivalent is forensic clearance: no system returns to production until rebuilt or verified clean.

4.4 Migration back. Sequence the return, reconcile data captured during manual operations, deactivate the alternate site, and close with an after-action review that feeds Part 5.

Part 5: Maintenance

5.1 Review cycle and triggers. An annual review at minimum, plus event triggers: reorganizations, new critical systems, new vendors, office moves, and every exercise or real incident.

5.2 Distribution and version control. Who holds copies, how changes reach them, how old versions are withdrawn. Keep an offline copy that does not depend on the network.

5.3 Exercises. Separate the exercise program (a multi-year schedule escalating from walkthroughs to tabletops to functional tests, covering every critical function) from the individual exercise plan (objectives, scenario, participants, and evaluation criteria for one event). Auditors ask for both.

5.4 Training and awareness. Who needs which training, how often, and how completion is recorded.

Appendices

• A. Contact directories: staff, emergency services, utilities, insurers, regulators, landlords
• B. Team structure and call tree (or the mass notification groups that replaced it)
• C. 24-hour emergency services and restoration vendors
• D. Key customers and vendors, with contract references and recovery commitments
• E. Critical systems inventory with RTO and RPO
• F. Forms: incident log, decision log, damage assessment checklist, expense tracking

Mapping the outline to ISO 22301 and NFPA 1660

Neither standard prescribes a table of contents, but a mapping makes evidence easy to find and exposes gaps. ISO references are to ISO 22301:2019. NFPA 1600's program elements now sit within NFPA 1660, so the right-hand column uses element names rather than paragraph numbers.

Facing a certification audit or regulatory exam? The briefing on surviving a BCM audit or examination covers what reviewers ask to see behind each row.

The one-page version for a small business

A 15-person firm needs one printed sheet, kept in at least two cars, that answers eight questions.

1. Safety. Where do we meet if we leave the building, and who calls 911?
2. In charge. Who decides, and who decides if that person cannot be reached?
3. Priorities. Our top three to five activities, and how many days each can stop.
4. Without the building. Where we keep working: home, another site, a partner's office.
5. Without the systems. Where our data lives, how we get it back, and what we do by hand in the meantime.
6. Who to call. Insurer and policy number, landlord, IT provider, bank, top customers, top suppliers.
7. What we say. Who tells staff and customers, and how.
8. When we check this. A date on the calendar, at least once a year.

Ready.gov's business continuity planning guidance includes free templates that fit this format.

Common mistakes

1. The plan is the BIA. Pages of impact ratings, no instructions. The plan says what to do.
2. Building loss is the only scenario. Also plan for losing people, systems, or a supplier.
3. No invocation criteria. Nobody feels entitled to declare, and the first hours go to debate.
4. The IT disaster recovery plan stands in for the business plan. Restoring servers does not tell accounts payable what to do for three days.
5. The only copy is on the file share. Which is now encrypted.
6. Alternates exist on paper. If they have never exercised, they are names, not alternates.
7. Contact lists go stale. Give them an owner and a quarterly check.
8. Written by someone who will not run it. A plan drafted without the function owners gets ignored by the people it depends on.

Frequently asked questions

How long should a business continuity plan be?

As short as it can be while still telling people what to do. A small business can work from a single page; a large firm usually has a short corporate plan plus function-level plans of a few pages each. Length is not a quality signal.

Should the IT disaster recovery plan be part of the business continuity plan?

Keep it separate but linked. The DR plan is technical and owned by IT; the business continuity plan references it, states the recovery targets it must meet, and covers what the business does while IT works. NIST SP 800-34 treats these as distinct plans that must be coordinated.

Does ISO 22301 require a specific plan structure?

No. ISO 22301 sets requirements for what plans and procedures must address (response structure, warning and communication, continuity, recovery), not how the document is organized. A mapping table like the one above helps auditors find evidence.

How often should the table of contents change?

The structure should stay stable so people know where to look. The contents should change whenever the business does, and after every exercise or real incident. Review the whole plan at least once a year.