A business continuity plan describes how the organization keeps critical processes running, or restores them within an acceptable time, when a disruption occurs. It supports several controls at once: (continuity specifically for IT systems and services), (keeping an appropriate level of information security during the disruption itself, not just restoring availability), and, where the plan relies on duplicated infrastructure, . It also depends on, and should stay consistent with, and , since a continuity event is often first handled as a security or operational incident before continuity plans are formally activated.
When and why do I need this?
All organisations should consider preparing a BCM plan, despite how low you judge the probability of a disastrous event. Because when a disaster did strike, it can and often end fatal e.g. with bankruptcy.
TLDR
Our recommendation for everyone in a rush
Don't try to produce a complete, polished plan in one pass. Take the chapter outline below, fill in what you already know — most organizations already have informal knowledge of their most critical processes and who to call in an emergency — and treat the gaps as a tracked to-do list rather than a reason to delay publishing a first version. A short, imperfect plan that people have actually read and know where to find beats a comprehensive one that's still in draft when the next incident happens.
As the bare minimum: think about what information will you need in case of disaster, including access to the BCM plan. Keep an offsite-backup, a printed or offline-accessible copy etc., since the primary IT systems it describes recovering may be exactly what's unavailable when you need it. The same is true for things like names, phone numbers and mail addresses of anyone required to resolve the disruption or it might be very difficult to get hold of your key staff and suppliers when you CRM, mail or contact database is no longer available.
Recommended chapter outline
A business continuity plan typically covers three groups of chapters: the foundations it is built on, the continuity strategy and plans themselves, and how the plan is operated and kept current over time.
Foundations
Groundwork the rest of the plan builds on.
Purpose, scope and objectives — which parts of the organization, sites and services the plan covers, and what it is explicitly not meant to address.
Roles and responsibilities — who declares a continuity incident, who leads the response (crisis team / continuity manager), and who is authorized to invoke which plan.
Business impact analysis summary — the organization's critical processes, their maximum tolerable downtime, recovery time and recovery point objectives, and their dependencies on systems, suppliers and people.
Scenarios considered — the disruption scenarios the plan is designed against (loss of a site, loss of a key supplier, extended IT outage, loss of key personnel); see the Risk catalogue for a starting list.
Continuity strategy and plans
The operational core: what the organization actually does when a disruption hits.
Continuity strategies per critical process — the chosen approach for each critical process (alternate site, alternate supplier, manual workaround, temporarily reduced service level) and why it was chosen over the alternatives.
Activation and incident response procedure — how a disruption is first identified and escalated, who decides to formally activate the continuity plan, and the initial actions in the first hour; see also .
Recovery plans (playbooks) — step-by-step instructions per scenario or per critical process, detailed enough that someone other than the usual owner could follow them under stress.
ICT disaster recovery — backup and restore procedures, failover to alternate infrastructure, and dependencies on ; often maintained as a separate, more technical annex.
Communication plan — pre-drafted messaging and channels for staff, customers, authorities and, where relevant, media, including who is authorized to speak externally.
Operating the concept
What keeps the plan alive rather than a one-time exercise.
Testing and exercise schedule — tabletop walkthroughs, technical failover tests, and full exercises, at a cadence proportional to how critical the process is.
Maintenance and review cycle — a named owner, a minimum review interval, and trigger events (reorganizations, new critical systems, a real incident) that force an off-cycle review.
Appendices — current contact lists, supplier emergency contacts, and references to detailed technical runbooks kept elsewhere.
Guidance on how to create this plan
Practical points worth keeping in mind while writing the plan, independent of the exact outline used:
Base it on a business impact analysis, not intuition — the A practical guide to cyber risk management guide's asset and impact steps produce most of the input this plan needs; don't redo that analysis from scratch.
Assign a single accountable owner for the whole plan, and separate owners per individual playbook — a document with no owner drifts out of date.
Write plans for someone under stress, not for yourself — short, numbered steps, explicit trigger conditions, and no assumed context, since the person executing a plan during a real incident may not be its author.
Keep the plan and its detailed playbooks separately versioned and reviewed — the high-level plan changes rarely, technical runbooks change with every infrastructure change.
Store a copy outside the systems the plan protects — if it only exists on the file server it describes recovering, it is unavailable exactly when needed.
Test at least the activation and communication steps even if a full technical failover test isn't feasible yet — a tabletop exercise is cheap and reliably surfaces gaps in roles and contact information.
Treat the first version as a baseline to improve, not a final deliverable — publish it once it covers the critical processes adequately, then iterate.
Sources:
ISO 22301 (Business continuity management systems) and ISO/IEC 27031 (guidelines for ICT readiness for business continuity) informed the chapter groupings above; adapt them to the organization's actual size and risk profile rather than following either standard's full structure verbatim.
Frequently asked questions