A BCM policy is the governing commitment for continuity, not a condensed business continuity plan. It establishes why the programme exists, who is accountable, which parts of the organisation are in scope, what minimum requirements apply, and how non-compliance is escalated.
What a defensible BCM policy contains
| Policy element | What to state | Evidence of implementation |
|---|---|---|
| Purpose and objectives | Protection of priority activities, people, obligations and stakeholders | Approved BCM objectives and programme |
| Scope | Entities, locations, services and exclusions | Scope statement mapped to organisation structure |
| Accountability | Executive sponsor, BCM function, business owners and support functions | RACI, appointments and committee terms |
| BIA and risk | Required review cycle and approval of impact tolerances | Current approved BIAs |
| Strategies and plans | Minimum recovery strategy and plan requirements | Approved strategies and plans |
| Exercises | Risk-based exercise and test expectations | Exercise calendar and after-action reports |
| Assurance | Monitoring, audit, corrective action and management review | Metrics, audits and action register |
Policy versus procedure versus plan
The policy says what is mandatory and who is accountable. Procedures describe how the BCM lifecycle is performed. Plans describe how teams respond and recover in a disruption. Keeping these layers separate makes governance clearer and prevents the policy from becoming an operational manual that quickly becomes obsolete.
Approval and exceptions
Assign an approval authority with enough seniority to enforce requirements across the defined scope. Define how exceptions are requested, risk-assessed, time-limited and accepted. An undocumented exception is not governance; it is an unknown exposure.
Example policy requirement
“Owners of priority services shall maintain approved continuity arrangements aligned to current BIA tolerances and shall provide exercise evidence at the frequency defined by the BCM programme.” This is testable. By contrast, “departments should have appropriate plans” is difficult to audit.
Review triggers
Review the policy on a defined cycle and after material organisational changes, significant incidents, major regulatory changes, acquisitions, operating-model changes or findings that expose a governance weakness. Do not change the policy merely because contact details changed; those belong in controlled procedures or plans.
Implementation checklist
- Confirm scope matches the real legal and operating structure.
- Name accountable roles rather than relying on a generic “management” reference.
- Define mandatory BIA, strategy, planning and exercising requirements.
- Define exception and risk-acceptance authority.
- Connect policy requirements to measurable BCM objectives.
- Publish through controlled document management and retain approval evidence.
- Train affected roles on their obligations, not just on the policy text.
FAQ
Does ISO 22301 provide a policy template?
The standard defines requirements but organisations should write a policy that reflects their own scope, governance, obligations and operating model rather than copying generic wording.
Should RTO values be written into the policy?
Normally no. Detailed tolerances change more often and belong in approved BIA or service records. The policy should require that such tolerances are established, approved and maintained.
Translate policy statements into measurable obligations
A policy becomes useful when each requirement can be tested. Instead of stating that “plans must be maintained,” define who owns the plan, the minimum review frequency, the events that trigger an out-of-cycle review, and the evidence retained after approval. Instead of saying that “critical suppliers must be resilient,” require a tiering method, minimum contractual expectations and periodic evidence of the supplier’s recovery capability.
Use a policy-to-control register so that every material statement has an implementing process, owner and evidence source. This allows internal audit and management review to verify whether the policy is operating rather than merely approved.
Handle exceptions without weakening accountability
Some recovery requirements cannot be met immediately because of cost, technology constraints or supplier limitations. The policy should define how an exception is raised, who can approve it, the maximum approval period, compensating controls and the point at which it must be reconsidered. An indefinite exception with no expiry date is effectively an unrecorded change to risk appetite.
For example, if a legacy application cannot meet the business RTO, the exception record should identify the service impact, current achievable recovery time, interim workaround, investment decision and approval authority. The next management review can then assess the exposure explicitly.
Policy lifecycle and evidence
Retain approval history, effective date, previous version, material changes and evidence that accountable roles were informed. Review should be triggered by major organizational change, significant incidents, new regulatory obligations, material outsourcing, acquisition, divestment or repeated exercise failure. This keeps the policy aligned with how the organization actually operates.
Communicate the policy to accountable roles
Approval is only the start. Identify the roles that must act differently because of the policy and provide them with concise responsibilities. Plan owners may need review deadlines; procurement teams may need continuity clauses; technology teams may need recovery-evidence obligations. Keep evidence that these responsibilities were communicated and include persistent non-compliance in governance reporting.
Make the policy establish non-negotiable management expectations
A BCM policy should state what the organization commits to govern, who is accountable and which minimum practices are mandatory. It can define scope, leadership responsibility, lifecycle expectations, exercise and maintenance requirements, exception handling, reporting and interfaces with risk, crisis, technology, security, facilities and supplier management. Detailed recovery procedures belong elsewhere; placing them in policy makes the governing document difficult to maintain.
Use language that can be evidenced. “Business continuity plans shall be maintained for critical activities and validated at a defined frequency” can be checked. “The organization will maintain excellent resilience” cannot. Where local business units may tailor the method, state which controls are mandatory and which may be adapted with approval.
Test policy effectiveness against actual governance
- Can every requirement be traced to an owner, process and evidence source?
- Are exceptions formally approved with a reason, compensating control, risk owner and expiry or review date?
- Do reporting and escalation mechanisms reveal non-compliance instead of hiding it inside overdue actions?
- Does the scope align with products, services, legal entities and dependencies that management actually considers important?
- Are policy changes communicated to the roles expected to implement them?
Policy review should consider changes in strategy, regulation, organization, technology, supplier dependence and incident experience. Approval alone does not demonstrate effectiveness; the stronger evidence is that the policy drives consistent BIAs, strategies, plans, exercises and corrective decisions across the organization.
Worked example: converting policy into accountable governance
A policy requirement such as “critical services shall maintain tested continuity plans” becomes useful only when the organization defines who determines criticality, who owns each plan, the minimum review and exercise frequency, what constitutes acceptable evidence, how overdue actions are escalated and which executive forum accepts residual risk. The policy should set those mandatory rules while procedures explain how teams comply. This keeps the policy stable enough for governance but specific enough that internal audit can determine whether the requirement is operating.