A business continuity plan is the document that says how your organisation keeps its critical activities running through a disruption, who decides, and what everyone does while normal operations are unavailable. It is not a risk register and it is not a recovery runbook. It is the operational instruction set that turns agreed priorities into action on the day.
- Built on decisions already made elsewhere, not on a blank template.
- Structured so a stressed person finds the right page in seconds.
- Explicit about who has authority to activate it and to declare it over.
- Short enough to be read, with detail pushed into annexes and runbooks.
- Maintained against change triggers, not just an annual date.
What is a business continuity plan?
The plan is the operational layer of a wider capability. Above it sits the analysis that decided which activities matter and how quickly each must be back. Below it sit the specific workarounds and technical runbooks. The plan itself is the connective document: it names the activities, states the objectives, assigns the roles and sets out the sequence of escalation.
That position explains the most common weakness. A plan written from a template, before anyone established the priorities, ends up describing a generic emergency response rather than this organisation’s actual operating decisions. It reads well and it does not survive contact with an incident, because the hard choices about what to sacrifice were never made. How the surrounding capability is built is covered under business continuity.
It is also worth being clear about what the plan is not. It is not the same as a contingency plan, which addresses one named risk, and it is not a disaster recovery plan, which restores technology. The differences between continuity and recovery specifically are set out in business continuity versus disaster recovery.
What sections does a business continuity plan need?
Sections earn their place by being used. The test for each one is whether somebody would open the plan looking for it during a disruption. The third column below matters more than the first two: almost every section is populated from work done elsewhere, and a plan that invents its own content is a plan that disagrees with the rest of your system.
| Section | What it must answer | Where the content comes from |
|---|---|---|
| Scope and assumptions | Which parts of the organisation this plan covers, and what it takes for granted. | The management system scope, plus explicit assumptions agreed with the business. |
| Critical activities and objectives | What must keep running, and the timeframe committed to each. | The business impact analysis. Referenced, never re-derived here. |
| Roles and authority | Who activates, who leads, who deputises, and what each may decide alone. | Named individuals with deputies, approved by the executive sponsor. |
| Activation levels | The escalation states, their thresholds and who moves between them. | Agreed with operations, calibrated against real incident history. |
| Workarounds by activity | How each critical activity is delivered while normal systems are unavailable. | The contingency plans, summarised here and held in full as annexes. |
| Dependencies and resources | The people, systems, suppliers, premises and data each workaround needs. | The dependency mapping from the impact analysis and the supplier register. |
| Communications | Who is told what, by whom, in what order, and through which channel. | Prepared holding statements and contact routes that work when systems do not. |
| Recovery and reconciliation | How normal service resumes and how work done manually gets back into the systems. | The recovery plan for the technical side, plus the process owners for the backlog. |
| Review record | When this was last exercised, what was found, and what changed as a result. | The exercise log and corrective action records. |
Notice how much of the plan is a reference rather than original content. That is deliberate. Every figure duplicated into the plan is a figure that will eventually contradict its source.
There's a bigger picture behind this.
This page covers one part of business resilience. Real Resilience — IO’s framework for connecting security, privacy and AI governance — is where the full picture comes together.
How is the plan activated and stood down?
A plan with no defined activation is the most common failure mode there is. People hesitate, waiting for someone to declare that this is serious enough, and the hesitation costs more than the disruption. The remedy is a set of named escalation states with thresholds attached, so moving between them is a recognition rather than a judgement call.
Two of these levels are routinely missing. Standby is the one that buys time: warning people that a trigger is approaching costs nothing and means the workaround starts in minutes rather than hours. Stand down is the one that gets skipped in the relief of recovery, which is how organisations end up running a manual process for weeks after the system came back, and how the backlog quietly becomes the second incident.
Whoever holds the authority to invoke must also be reachable. Naming a single senior person with no deputy is a plan that depends on one diary. Where a situation exceeds what the plan anticipated, authority moves up to your crisis management arrangements, which is a separate decision rather than an extension of invocation.
How long should a business continuity plan be?
Shorter than most. The useful measure is not page count but time to the right instruction: someone opening the plan under pressure should reach what they need within a minute. In practice that means a core document of perhaps fifteen to thirty pages for a mid sized organisation, with everything else in annexes.
What belongs in the core: scope, activities and objectives, roles and authority, activation levels, communications and the summary of workarounds. What belongs in annexes: the detailed workaround for each activity, contact lists, technical runbooks, supplier details and templates. Annexes change far more often than the core, which is a practical reason to separate them. A hundred page plan is usually a sign that the analysis was skipped and comprehensiveness was used as a substitute for prioritisation.
Keep a current copy somewhere that does not depend on what might have failed. A plan stored only on the network share, or contact details held only in the email system, is a plan you cannot open during exactly the sort of incident it was written for.
Who writes it, and who signs it off?
Drafting is best done by whoever owns continuity, working with the people who run each critical activity. Plans written entirely by a consultant or entirely by one internal specialist share the same flaw: they describe how the work is imagined to happen rather than how it actually does, and the gap only appears when someone tries to follow them.
Approval has to come from an executive who can genuinely commit to the priorities, because the plan encodes decisions about what gets sacrificed. That is the part nobody wants to sign, and it is the part that makes the plan real. If every activity is critical and every timeframe is immediate, no prioritisation has occurred and the document will not help anyone choose under pressure.
Each workaround also needs a named owner in the business, not just the continuity lead. Ownership spread across a team tends to mean ownership by nobody once the plan is a year old.
Free download
The Proven Path to ISO 27001 Success
Download your free guide to everything you need to know about achieving ISO 27001 first time
How do you keep the plan current?
Plans decay quietly. Nothing announces that a plan has become wrong, and an annual review date is not enough on its own because most of what invalidates a plan happens between reviews. Tying maintenance to change events catches it earlier.
| Trigger | What to re-check | Who re-approves |
|---|---|---|
| New or replaced critical system | Dependencies, workaround feasibility and the recovery objectives for affected activities. | Activity owner and the recovery lead. |
| Supplier change or exit | Dependency entries, contractual continuity obligations and any workaround that assumed that supplier. | Supplier owner and continuity lead. |
| Reorganisation or key departure | Every named role, deputy and contact route in the plan and its annexes. | Executive sponsor. |
| New site or hosting arrangement | Location assumptions, alternative premises and where the plan copies are held. | Continuity lead and facilities or IT. |
| Exercise or real incident | Whatever the findings touched, plus the assumptions the event disproved. | Continuity lead, with findings recorded. |
| New regulatory or contractual obligation | Scope, notification timeframes and the evidence you are expected to hold. | Executive sponsor and compliance owner. |
The review record belongs in the plan itself. An undated plan tells a reader nothing about whether it describes the organisation they work in today.
How does the plan connect to business resilience?
A continuity plan handles disruption to activities you have identified. Resilience is the broader capability to absorb change of any kind, including disruptions nobody planned for and obligations that did not exist when the plan was written. The plan is a component of that capability, and what connects them is the controls underneath.
The Resilience Loop runs information security under ISO 27001, data privacy under ISO 27701 and AI governance under ISO 42001 as one connected system, with continuity as a further lens over the same controls. This is where the plan stops being a standalone document: the access management, backup, supplier assessment and incident response your workarounds depend on are maintained once and serve every framework. The wider structure is set out in the business resilience framework, and the certifiable management system that keeps the plan owned and exercised is specified in ISO 22301.
It also catches a consequence plans often miss. A manual workaround that moves customer data into a spreadsheet, or a restore that reinstates records someone asked you to erase, is a privacy matter created by your continuity response. Running continuity over the same control set as privacy is what surfaces that before it happens rather than afterwards.
How do you prove the plan works?
Possessing a plan is not the claim anyone tests. Customers, auditors and regulated clients ask whether it works and whether it is current, and both have to be shown rather than asserted.
What that takes: the approved plan with a version and date, the impact analysis its objectives come from, an exercise record with participants and findings, the corrective actions arising and their closure, and evidence that the review triggers above were actually applied. Generated as a by-product of the work, that evidence is always available. Assembled once a year for an audit, it is a scramble that convinces nobody. The approach is described in how to evidence resilience, and the Resilience Score gives you a starting baseline.
Why choose ISMS.online for business continuity planning?
A plan is only as good as its weakest reference. ISMS.online keeps the plan connected to everything it depends on.
- One source for the objectives: recovery timeframes live with the impact analysis and feed the plan, so the numbers cannot drift.
- Plans linked to risks and controls: each workaround connects to the dependencies and controls it relies on, so gaps are visible before an exercise finds them.
- Named ownership with review dates: owners, deputies and triggers tracked, with reminders that stop plans quietly going stale.
- Exercise records built in: schedule tests, capture findings and track corrective actions alongside the plan itself.
- One control set, every framework: map once and reuse across ISO 22301, ISO 27001, ISO 27701 and ISO 42001.
- Evidence on demand: produce a current plan with a version history and a test record, not a document and a promise.
- Informed by deep expertise: guided implementation from specialists who have run these systems in regulated environments.
See how it fits together on the business resilience platform, or book a demo.
FAQs
What is the difference between a business continuity plan and a disaster recovery plan?
The continuity plan covers how the business keeps its critical activities running during any disruption, including ones with no technical cause. The recovery plan covers restoring the technology those activities depend on, to targets the continuity work set. Continuity decides what matters and what the workaround is. Recovery rebuilds the systems underneath in dependency order.
Do we need a business continuity plan for each site or one for the organisation?
One organisational plan with site specific annexes usually works best. The core decisions about priorities, authority and communications should be consistent everywhere, while the practical detail of premises, local suppliers and alternative working arrangements differs by location. Separate standalone plans per site tend to diverge over time and duplicate the objectives, which is how contradictions get in.
How often should a business continuity plan be tested?
At least annually as a full exercise, with lighter walkthroughs more often, particularly after a change to roles or systems. What matters more than frequency is realism and record keeping. An exercise that confirms everyone can read the plan proves very little. One that requires people to actually operate the workaround, with the findings written down and acted on, is worth several of the first kind.
Is a business continuity plan a legal requirement?
There is no single law that requires every organisation to hold one. Obligations arise instead from sector regulation, from contracts and from framework requirements. Financial services, telecoms, healthcare and providers to those sectors typically face specific expectations, and customer contracts increasingly require continuity arrangements with evidence of testing. In practice the contractual driver arrives before the regulatory one for most organisations.
Can we write a business continuity plan from a template?
A template gives you a structure and saves time on layout, which is genuinely useful. What it cannot give you is the content, because the value of the plan is in the decisions: which activities are critical, how long each can be down, what the alternative way of working is and who has authority. Filling a template without doing the impact analysis first produces a document that looks complete and prioritises nothing.
