· Guide · 7 min read
Business Continuity Policy: Governance for ISO 27001 and ISO 22301
Write a continuity policy that sets executive direction, scope and authority, then prove it governs objectives, plans, exercises and improvement.
A business continuity policy is top management’s direction for how the organisation will prepare for, respond to and recover from disruption. It should establish purpose, scope, principles, authority and commitment. It should not become a detailed recovery plan or a collection of procedures that executives cannot realistically govern.
ISO 22301 requires a policy within the business continuity management system. ISO/IEC 27001 has its own information-security policy requirements and continuity-related controls. An organisation may align the two management systems, but it should keep their scopes and claims clear.
Direct answer: Keep the policy concise and decision-oriented. State what the continuity system covers, the outcomes leadership expects, who has authority, which commitments apply and how performance will be reviewed. Put operational steps, contact details and recovery sequences in controlled plans and procedures.
Understand what the policy is for
The policy should help people make consistent decisions when detailed instructions do not answer the situation. It provides a stable governance layer above business impact analysis, strategies, plans, exercises and improvement.
A useful policy can answer:
- Why is continuity important to the organisation’s purpose and stakeholders?
- Which activities, products, services, locations and dependencies are in scope?
- What principles guide priority, safety, information protection and recovery?
- Who is accountable for the system and who can activate response arrangements?
- What legal, regulatory, contractual and internal commitments shape the system?
- How will objectives, exercises, incidents and improvements be governed?
The ISO 22301 and ISO 27001 continuity guide explains where the standards reinforce one another and where their management-system scopes remain distinct.
Keep policy separate from plans
Policy changes when leadership direction, context or scope changes. Plans change more often as services, contacts, suppliers and recovery procedures evolve.
| Document | Primary purpose | Typical owner | Change pattern |
|---|---|---|---|
| Policy | Set direction, commitments and governance | Top management or delegated executive | Relatively stable |
| Programme and objectives | Translate direction into planned outcomes | Continuity leadership and owners | Periodic and risk-driven |
| Strategy | Select how continuity requirements will be achieved | Accountable business and service owners | Changes with risk and design |
| Plan | Coordinate response and recovery | Named plan owner | Changes with operations and dependencies |
| Procedure | Describe specific actions | Process or technical owner | Changes frequently with implementation |
If the policy contains phone numbers, failover commands or step-by-step recovery actions, it is likely carrying the wrong information. If it merely says “the organisation supports continuity,” it is too weak to direct decisions.
The business continuity plan guide provides a separate structure for executable response and recovery information.
Define scope without hiding dependencies
State the policy’s scope in language that business owners can apply. Reference the formal BCMS scope where detail is maintained. Explain exclusions and interfaces, particularly shared services, outsourced processes, cloud platforms, key suppliers and corporate functions.
Scope should reflect products and services as well as legal entities and sites. A narrow location-based statement can miss remote teams, shared identity, data centres or external providers that determine whether an activity can continue.
When the BCMS and ISMS scopes differ, record the boundary explicitly. For example, the BCMS may cover selected customer services while the ISMS includes the full company. Shared controls and evidence can still be coordinated without implying identical certification scope.
Express commitments that can be governed
Policy commitments should be meaningful enough to influence objectives and reviews. Depending on context, they can address:
- meeting applicable legal, regulatory and contractual duties;
- protecting life, safety, information and stakeholder interests;
- maintaining prioritised activities at approved levels;
- establishing and reviewing continuity objectives;
- providing appropriate people, technology, information and funding;
- exercising arrangements and learning from incidents;
- controlling supplier and dependency risk;
- communicating with interested parties; and
- continually improving the management system.
Avoid promises such as “zero downtime” unless the organisation has deliberately accepted and engineered that obligation. Policy language should not create commitments that contradict approved recovery objectives or contracts.
ISO’s ISO 22301 overview describes the standard as a framework for planning, establishing, implementing, operating, monitoring, reviewing, maintaining and improving a documented management system for disruptive incidents. Use the licensed standard for normative text; the wording here is practical guidance.
Assign authority and accountability
Identify the executive accountable for the continuity management system and the governance forum that reviews it. Define responsibilities for business owners, continuity coordinators, plan owners, service owners and supporting functions.
The policy should establish, directly or by reference:
- authority to declare and activate continuity arrangements;
- authority to prioritise scarce resources;
- responsibility for approving recovery requirements and residual risk;
- escalation when an objective cannot be met;
- expectations for supplier participation;
- reporting to top management; and
- responsibility for post-event learning and corrective action.
Authority must be usable outside normal hours and when senior personnel are unavailable. Named alternates and delegation belong in controlled governance or plan records rather than relying on informal knowledge.
The executive support guide can help connect policy commitments to funded decisions and accountable owners.
Connect policy to measurable operation
Auditors should be able to trace policy commitments down into evidence. For example:
| Policy commitment | Operating evidence |
|---|---|
| Prioritise critical activities | Approved business impact analysis and recovery sequence |
| Provide resources | Budget, assigned roles, supplier capability and training |
| Exercise arrangements | Risk-based programme, results and verified actions |
| Meet obligations | Requirements register, plan criteria and communication records |
| Improve capability | Incident lessons, corrective action and management review decisions |
The business continuity exercise guide shows how policy direction becomes a programme of observable assurance.
Use the free ISO 27001 Clause Explainer to explore policy and leadership concepts in the ISMS. Confirm all formal requirements against the licensed editions and the organisation’s actual certification scope.
Approve, communicate and keep it available
Top management should approve the policy at the level implied by the organisation’s governance. Record approval, version, effective date and owner. Make it available to people whose work it directs, and provide relevant content to external parties where appropriate.
Communication is more than publishing a file. Interview role holders to confirm they understand what the policy means for priority, escalation and reporting. Contractors and suppliers may need tailored obligations through contracts, operating procedures or joint exercises.
Protect sensitive supporting information. The policy may be suitable for broad distribution, while detailed plans and dependency data require restricted access.
Review based on change and evidence
Set a regular review cycle, but do not wait for the calendar after a significant event. Trigger review when there is:
- a change in strategy, products or scope;
- a major supplier, technology or location change;
- new legal or contractual obligations;
- an incident or exercise that challenges policy assumptions;
- a change in governance or executive accountability; or
- evidence that objectives repeatedly cannot be met.
Record the review outcome even when no wording changes. The evidence should show that suitability and alignment were considered, not merely that a document date was advanced.
Audit the policy through decisions
An effective audit starts with the policy and samples downward. Select two or three commitments, trace them into objectives and plans, and then examine operating evidence. Also work upward from a recent exercise or incident to see whether leadership decisions matched the policy.
Sample audit questions
- Which business and stakeholder needs shaped the policy?
- How are differences between BCMS and ISMS scope explained?
- Who can activate arrangements when primary leaders are unavailable?
- Which objective demonstrates each material commitment?
- When did the policy last influence a resource or risk decision?
- How was understanding confirmed beyond file publication?
- What evidence triggered the most recent review?
Judge pass, partial and fail conditions
Pass: The policy is approved, relevant to context, clear on scope and authority, linked to measurable objectives, understood by role holders and supported by operating evidence and management decisions.
Partial: A current policy exists, but it is generic, scope interfaces are unclear, commitments do not trace to objectives, or communication is evidenced only by publication.
Fail: The policy contradicts actual priorities, contains commitments management cannot support, assigns no usable authority, or has no connection to plans, exercises and improvement.
A good business continuity policy is short enough to guide and strong enough to govern. Its value appears not in its page count, but in the consistent priorities, authorities and investment decisions it produces before and during disruption.