Business continuity plan template: what goes in it, and what to leave out

Continuity plans fail for a consistent reason: they are written to be reviewed rather than used. The test is not whether the document is thorough. It is whether someone woken at 3am, possibly not the usual person, can open it and know what to do in the first thirty minutes.

1. Scope and objectives

What the plan covers - which entities, sites and activities - and what it deliberately does not. Reference the business impact analysis rather than repeating it. State the recovery objectives the plan is designed to meet, so anyone reading knows the standard being aimed at.

2. Invocation criteria and authority

The most important section, and the one most often vague. It must answer three questions without interpretation:

• What triggers invocation - stated in observable terms. "A critical service unavailable for more than two hours with no confirmed fix" is actionable; "a significant disruption" is not.
• Who can invoke - named roles, with at least two deputies. Plans that require one person's authorisation fail on the day that person is unreachable, which is disproportionately often.
• How invocation is communicated, including what happens when the primary channel is the thing that is down.

Give people explicit authority to act before the plan is formally invoked. Waiting for authorisation is a common cause of avoidable delay, and the cost of a cautious early response is almost always lower than the cost of a slow one.

3. Roles and the team

Roles rather than names in the body, with a separate contact annex holding names, deputies and multiple contact methods - because that annex changes constantly and the plan should not need reissuing each time. Cover incident lead, operations, communications, IT recovery, HR and a scribe. The scribe matters: nobody remembers the timeline afterwards, and you will need it for regulators, insurers and the post-incident review.

4. Immediate actions - the first hour

A short, ordered checklist. Assess safety, establish the incident team, open a communication bridge, begin the log, make an initial impact assessment, decide on invocation, and issue a first internal notification. This section should fit on one page and be printable.

5. Scenario responses

Do not write a plan per threat - there are too many and they converge. Write responses by loss type, because the recovery is the same regardless of cause:

• Loss of premises - fire, flood, denied access.
• Loss of technology - outage, cyber incident, provider failure.
• Loss of people - illness, industrial action, a key-person event.
• Loss of a supplier - critical third-party failure.
• Loss of data integrity - the ransomware case, which is distinct because you cannot trust what you have.

Five responses cover almost everything, and they stay current far longer than threat-specific plans.

6. Recovery priorities and dependencies

The ordered list of what gets recovered first, drawn from the BIA, with each activity's dependencies - systems, data, people, suppliers, facilities. Include the workaround: how the activity runs manually or at reduced capacity while systems are down. Manual workarounds are the part most often missing and most often needed, because recovery rarely completes inside the objective.

7. Communications

Internal, customer, supplier, regulator and public. Pre-approved holding statements save an hour when an hour matters, and the approval path for external statements should be settled in advance. Include regulatory notification deadlines explicitly - continuity events frequently carry reporting obligations under sector rules or data protection law, and those clocks run whether or not you have restored service.

8. Return to normal

Criteria for standing down, the sequence for returning to primary systems, data reconciliation for anything captured manually during the disruption, and the post-incident review. The reconciliation step is routinely forgotten and routinely painful.

9. Exercises and maintenance

Schedule, exercise types, who participates, and how findings are tracked to closure. State the review cycle - annually and after any invocation, significant change or acquisition.

What to leave out

• Background on business continuity as a discipline. Nobody reads it during an incident.
• The full BIA. Reference it; do not embed it.
• Detailed technical recovery runbooks. They belong with the technical teams and change too fast for a governance document - link to them.
• Names throughout the body. They date the whole plan.
• Anything you cannot actually do. An aspirational plan is worse than an honest limited one, because people rely on it.

Practical format point: keep the actionable core short, hold contacts in an annex, and ensure the plan is available offline. A continuity plan stored only in the system that is down is a recurring and entirely predictable failure.

Key takeaways

• Invocation criteria and authority - with deputies - are the sections that decide whether the plan works.
• Write responses by loss type, not by threat; five cover almost everything.
• Include manual workarounds and the data reconciliation that follows them.
• Keep names in an annex and the plan available offline.