What goes in a business continuity plan: a practical outline

A business continuity plan says which functions must keep running, how long you can tolerate losing them, who does what, and how work continues and returns to normal after a disruption. It starts with a short list of critical functions, not a long document.

Use CP-2 as an outline

NIST SP 800-53 CP-2 describes a contingency plan that, in paraphrase:

1. Identifies essential mission and business functions and their contingency needs.
2. Sets recovery targets, restoration priorities and success metrics.
3. Defines roles and responsibilities and names the people, with contact details.
4. Explains how essential functions continue during a disruption, compromise or failure.
5. Describes returning to full operation without weakening the controls originally planned.
6. Addresses how contingency information is shared.
7. Is reviewed and approved by defined roles.

It also requires distribution to key personnel, coordination with incident handling, review on a schedule, updating after changes or test findings, and protection of the plan from unauthorised disclosure and change.

NIST SP 800-34 Rev. 1, the contingency planning guide for federal information systems, covers the purpose, process and format of such plans and how they relate to other security and emergency plans. It is a federal guide, but its structure is useful for anyone.

Step 1: list critical functions

Ask: if this stopped for a day, a week, a month, what happens? Typical answers for a software company: customer-facing product, authentication, payments, support, engineering delivery, payroll. Rank them.

Step 2: set recovery targets

For each function pick a recovery time objective, the time you can be down, and a recovery point objective, the data you can afford to lose. Write them down even if they are guesses. A guess you can test is more useful than a blank.

Step 3: list dependencies

For each function, list what it needs: cloud region, identity provider, DNS, payment processor, key staff, a particular laptop or credential. Single points of failure show up fast. Do not forget third-party suppliers.

Step 4: write the workarounds

How do you operate if the product is down, if the office is unavailable, if your chat tool is down, if a key person is absent? A paper list of phone numbers and a second communication channel beat a long narrative.

Step 5: roles and activation

Name who can declare a continuity event, who leads, who communicates. Give backups. Define triggers, such as "outage longer than 30 minutes".

Step 6: recovery and return to normal

CP-10 describes returning a system to a known state within times that fit recovery objectives, then reconstitution: removing temporary workarounds, testing restored capabilities and resuming monitoring. Plan that stage, since teams often forget it.

Step 7: test and maintain

An untested plan is a draft. See how to test continuity plans for a discussion format that works equally here, and backup checks for the data side.

Safeguard's asset discovery can help build the dependency list, and its compliance and evidence automation can hold test records.

Quick check

Sources

• CP-2 Contingency Plan, NIST SP 800-53 Rev. 5
• CP-10 System Recovery and Reconstitution, NIST SP 800-53 Rev. 5
• SP 800-34 Rev. 1, NIST CSRC publication page

Last reviewed: 19 October 2026.