Business Continuity Plan Template: Impact Analysis, Strategies and Plan Structure

Most business continuity plans fail at the first real outage because they describe IT recovery in detail and say almost nothing about how the business keeps serving customers while systems are down. This template is for the business side: it records which activities matter most, how long each can stop before the damage becomes unacceptable, what staff do instead when systems, sites, people or suppliers are unavailable, and who decides. It is structured around ISO 22301:2019 (business impact analysis, strategies, plans and exercising) and the NIST SP 800-34 Rev. 1 contingency planning process, with notes for EU financial entities under DORA Article 11. IT system recovery belongs in a separate document: use the companion Disaster Recovery Plan Template for restore order, runbooks and recovery testing. It is for continuity managers, operations leads and the executives who approve the plan.

How to use this template

• Replace text in square brackets, such as [Organisation], [Crisis Management Team lead] and [4 hours], with your own terms and values.
• Complete the business impact analysis (section 4.1) before writing strategies or plans. Strategies chosen without a BIA usually protect the wrong activities. A worksheet is in the Business Impact Analysis Template.
• Keep this document at plan level. Put team-level procedures (call trees, manual workaround instructions, site evacuation) in annexes that the owning teams maintain, so the plan itself changes rarely.
• Hand the recovery time objectives agreed here to IT. They become the input to the Disaster Recovery Plan Template, which covers restoring the systems that support each activity. Cyber incident handling (containment, forensics, eradication) sits in the Incident Response Plan Template.
• For background on how BC and DR fit together, see the Business Continuity and Disaster Recovery Guide; for certification against the standard, see the ISO 22301 Business Continuity Guide.

1. Purpose

This plan sets out how [Organisation] will continue to deliver its [products and services] at acceptable, predefined levels during and after a disruption, and how it will return to normal operation. It establishes the business impact analysis, the continuity strategies for each prioritised activity, the authority to invoke them, and the exercise programme that keeps them current. It supports [Organisation]'s obligations under [ISO 22301 certification scope / DORA / sector regulation / customer contracts].

2. Scope

This plan applies to:

• The following products, services and business units: [list]. Excluded: [list, with reason].
• The following sites: [head office, operations centres, warehouses, branches].
• Disruption scenarios causing loss or unavailability of: premises; people (illness, industrial action, key person loss); technology and data (including cyber attack such as ransomware); suppliers and outsourced services; utilities and transport.
• All employees, contractors and third parties who perform or support prioritised activities.

Plan on the impact, not the cause. Ransomware and a data centre fire both mean "core systems unavailable for [5 days]", so this plan is organised by loss of resource, not by threat.

3. Roles and responsibilities

No person may hold more than one CMT role during an invocation.

4. Policy statements

4.1 Business impact analysis

1. [Business continuity manager] must lead a BIA at least [annually] and after significant change to products, structure, sites or key suppliers.
2. For each activity the BIA must record the impact of disruption over time using the criteria in the table below, and set a maximum tolerable period of disruption (MTPD), a recovery time objective (RTO) shorter than the MTPD, and the minimum service level acceptable during disruption.
3. The BIA must identify each prioritised activity's dependencies: people and skills, premises, technology and data (with the data loss each activity can tolerate, its recovery point objective), suppliers, and other internal activities.
4. Results must be approved by [executive sponsor] before strategies are selected.

The MTPD is the first point at which any category reaches [4, severe]. Record results in the prioritised activity register:

4.2 Risk assessment

1. The risk of disruption to each prioritised activity must be assessed at least [annually], covering single points of failure in people, sites, technology and suppliers, and recorded in the Risk Register Template.

4.3 Continuity strategies

For each prioritised activity, [Organisation] must select and fund a strategy for each resource type that can deliver the minimum service level within the RTO.

1. Manual workarounds must be documented, tested and sized: state how many transactions per day staff can process by hand and how the backlog will be re-entered when systems return.
2. Where a prioritised activity depends on a single supplier, the contract must include continuity obligations, notification within [X hours] of a disruption, and a right to participate in exercises. The Change Healthcare breach showed the cost of having no alternative: when one clearinghouse disconnected its systems, pharmacies, hospitals and practices could not submit claims or check coverage for weeks.

4.4 Invocation and plan activation

1. Any [manager] who becomes aware of a disruption that could breach an RTO must alert [the duty manager on +XX XXX] immediately.
2. The CMT lead or deputy decides whether to invoke this plan, using these criteria: [any prioritised activity expected to exceed 50 per cent of its RTO; loss of a site; a cyber incident classified [Severity 1 or 2]]. Invoke early and stand down if not needed.
3. The CMT must convene within [1 hour] of invocation, at [primary location / bridge number], with [alternate location] as fallback. It must not depend on corporate email or chat alone: hold [an out-of-band channel and printed contact list].
4. The CMT must record decisions, times and rationale in [the decision log] from the moment of invocation.

4.5 Business recovery plans

Each business recovery team must maintain an annex for its activities containing, at minimum:

1. Activity priorities, minimum service levels, call tree and deputies.
2. Step-by-step workarounds for loss of each dependency, including manual forms, alternative contact routes and approval limits for emergency decisions.
3. Resources needed at the alternate location.
4. Backlog recovery and data re-entry procedure, and how to reconcile records once systems return.
5. Criteria and steps for returning to normal operation.

4.6 Communication

1. Messages must follow [the incident communication plan], with pre-approved holding statements; [Legal and compliance] must assess regulatory reporting within [X hours] of invocation.

4.7 Where identity fits

1. Workarounds and alternate sites must not depend on access that will not exist during the disruption. Each annex must state which accounts, roles and approval rights staff need at the alternate location, and these must be provisioned and tested in advance, not created under pressure.
2. Emergency access granted during invocation (temporary roles, shared mailboxes, supplier access) must be logged, time-limited to [72 hours or stand-down] and removed during return to normal.
3. Where the disruption is a cyber attack, the CMT must assume that identity services may be unavailable or untrusted until IT confirms otherwise, and plan workarounds accordingly. Identity recovery sequencing is set out in the Disaster Recovery Plan; see also the Identity Recovery Guide.

4.8 Exercising and testing

1. [Organisation] must run the exercise programme below, covering every prioritised activity at least [annually], and including at least one cyber attack scenario each year.

• Each exercise must have written objectives and a report within [20 working days] with actions and owners. See the Tabletop Exercise Guide.

4.9 Return to normal

1. The CMT stands down once prioritised activities run normally, backlogs are scheduled and temporary access is removed.
2. A post-incident review must be held within [10 working days] of stand-down.

5. Exceptions

1. A prioritised activity that cannot meet its RTO with current strategies must be recorded as an exception, with the gap, interim mitigations, a remediation date and the accountable owner.
2. Exceptions must be approved by [executive sponsor], expire after no more than [12 months] and be reported to [the risk committee].
3. An activity may be excluded from scope only with a documented reason approved by [executive sponsor].

6. Compliance and monitoring

1. [Business continuity manager] must report [quarterly] to [the risk committee] on:
   • Percentage of prioritised activities with a BIA reviewed in the last 12 months.
   • Percentage of prioritised activities exercised in the last 12 months, and whether the RTO was met.
   • Open exercise and incident actions past due date.
   • Prioritised activities where the IT recovery capability (from DR tests) is longer than the business RTO.
   • Critical suppliers without continuity terms or evidence of exercising.
2. This plan and its exercises are subject to [internal audit] at least [annually]. Records of invocations and exercises must be retained for [X years].

7. Review and approval

Implementation guidance

1. Start with three to five activities: pick the services whose failure the board would notice within a day, run the BIA for those, and expand later.
2. Reconcile the business RTO with IT reality: send the activity register to IT, ask for the demonstrated recovery time of each dependency from the last DR test, and list every gap in section 5. This is where BCP and DRP meet; the gap is usually larger than expected.
3. Test workarounds with real volumes: a paper process that works for ten orders may fail at 2,000. Time it during an exercise and size staffing from the result.
4. Exercise before you certify: run a tabletop on a ransomware scenario that takes all systems away for a week. The NCSC's free Exercise in a Box offers tabletop and micro exercises, including ransomware, for smaller organisations. The Tabletop Exercise Scenario Pack has further scenarios.
5. Roll back safely: if a revised plan fails an exercise, keep the previous approved version in force until the fix is re-tested.

• Standards: ISO 22301:2019 is the current edition (ISO/TC 292), with Amendment 1:2024 adding climate action changes; ISO lists the standard as due for revision, so check the ISO 22301 page before an audit. NIST SP 800-34 Rev. 1 sets out the seven-step process used above and supplies a BIA template; it defines the business continuity plan as sustaining business processes during and after disruption, and the disaster recovery plan as relocating information systems after major disruption.
• EU financial entities (DORA): Article 11 of Regulation (EU) 2022/2554 requires an ICT business continuity policy that forms part of the overall business continuity policy, a BIA covering functions, third-party dependencies and their interdependencies, testing at least yearly and after substantive changes (including cyber attack scenarios and switchovers for entities other than microenterprises), a crisis management function and records of activities during disruption. Check that your section 4.8 frequencies meet it. See the DORA Guide.

Related NHI Mgmt Group resources: Business Continuity and Disaster Recovery Guide · ISO 22301 Business Continuity Guide · Disaster Recovery Plan Template · Business Impact Analysis Template · Incident Response Plan Template