A business continuity plan answers one question: when something important stops working, how does the organization keep delivering what matters most until it is fixed? Security teams often inherit this document because of ISO 27001 or SOC 2, but the answers come from the business. Recovery targets set by IT without input from the people who feel the impact tend to be either impossible or irrelevant. This template gives you a starting structure; the business impact analysis is what makes it yours.
Run the business impact analysis first
The business impact analysis (BIA) identifies critical activities, what they depend on, and how quickly harm accumulates when they stop. Interview process owners, not just system owners, and ask about impact over time: what happens after an hour, a day, a week? Financial loss, contractual penalties, regulatory exposure, customer harm, and reputational damage rarely grow at the same rate.
Terms your BIA should set for each critical activity
Dependencies are where plans usually break. A payroll process might have a four-hour RTO on paper while depending on a SaaS provider whose contract promises nothing about recovery. Cross-check suppliers against your vendor inventory and tiering model, and feed continuity risks into the risk register.
Choose recovery strategies that match the targets
What the plan itself should contain
- Activation criteria: who can invoke the plan and on what evidence, so it is not delayed waiting for certainty.
- Command structure: a crisis or continuity team with deputies for every role.
- Communication: staff, customers, suppliers, regulators, and media, with pre-approved message outlines.
- Recovery procedures: per critical activity, in priority order derived from the BIA.
- Information security during disruption: how access control, logging, and data protection are maintained when working in degraded mode.
- Return to normal: criteria for standing down and reconciling any data or transactions handled by workaround.
- Contact and resource lists: stored where they remain reachable if primary systems are down.
Framework requirements
ISO 27001 does not require certification to ISO 22301, but the continuity controls are much easier to evidence when the plan follows its structure. For how these requirements fit a wider certification effort, see the ISO 27001 complete guide.
Exercising the plan
Plan a mix across the year rather than repeating the same tabletop. Each exercise should produce a short report: objectives, participants, what worked, what failed, measured recovery times against targets, and actions with owners. Auditors weigh measured restore results far more heavily than attendance lists.
Review cadence and evidence
- BIA refreshed at least annually or after significant business change
- Plan approved by senior management with owner and review date recorded
- At least one exercise report per year with actions tracked to closure
- Backup restore test results showing achieved recovery time and data point
- Contact lists verified within the last review cycle
- Supplier continuity commitments checked for critical dependencies
Common pitfalls
- Setting RTOs by asking IT what is achievable instead of asking the business what is tolerable, then reconciling the two.
- Confusing backups with recovery: backups that have never been restored under time pressure prove little.
- Treating the IR plan and the BCP as the same document; they overlap at a major incident but serve different purposes, so link them. The incident response plan template covers the security side.
- Plans that assume the people named will be available.