Policy

To meet ISO 22301:2019 Clause 5.2, top management must formally establish a business continuity policy that fits your organization’s purpose and context, is communicated internally, and is available to interested parties as appropriate (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements). Operationalize this by drafting a short, decision-useful policy, approving it through executive governance, mapping it to BCMS objectives, and keeping clean evidence of approval, communication, and review.

Key takeaways:

• The “policy requirement” is an executive duty: top management must establish the BC policy, not delegate it as an informal procedure.
• Auditors look for fit-for-purpose content plus proof of approval, communication, availability, and periodic review.
• A strong policy is short and governs the BCMS: scope, commitments, roles, and how BC objectives and plans are set and maintained.

Clause 5.2 is the point in ISO 22301 where business continuity becomes a management commitment you can test. The standard is not asking for a thick binder. It is asking for a clear business continuity policy that top management establishes and that matches what your organization is and does. If you operate a regulated business, provide critical services, rely on third parties, or run complex technology, the policy is the place to set non-negotiables: what continuity means here, who owns it, and what the BCMS must achieve.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat the policy as an enforceable “charter” for the business continuity management system (BCMS). It should create alignment across operations, IT, security, facilities, product, and third-party management without duplicating playbooks and runbooks. Done well, it also reduces audit friction because it gives a single approved reference point that ties together BIA, risk assessment, continuity strategies, testing, corrective actions, and management review.

This page breaks the requirement into plain-English expectations, concrete steps, artifacts to retain, and audit questions you can prepare for.

Regulatory text

ISO requirement (excerpt): “Top management shall establish a business continuity policy appropriate to the purpose of the organization.” (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements)

Operator interpretation: You need a formally approved policy, issued under top management authority, that sets direction for business continuity in your organization. “Appropriate to purpose” means the policy fits your services, customers, obligations, risk profile, and operating model. It should be communicated internally and available to interested parties as appropriate, as reflected in the provided summary of Clause 5.2 (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

Plain-English interpretation (what auditors mean by “policy requirement”)

A compliant business continuity policy does four jobs:

1. States the organization’s commitment to business continuity as a managed system (not ad hoc recovery).
2. Defines what the BCMS covers (scope and applicability).
3. Assigns accountability (who owns the BCMS, who must follow it, who approves exceptions).
4. Connects to action by linking to BC objectives, continuity plans, exercises, and continual improvement.

If your policy reads like a generic mission statement, you will struggle in certification audits because it won’t govern real decisions.

Who it applies to

Entity scope

• Any organization implementing ISO 22301 or maintaining an ISO 22301-aligned BCMS (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

Operational context (where this shows up)

• Organizations with multiple business units: policy must cover how BCMS requirements apply across units and shared services.
• Heavily outsourced operations: policy must state expectations for continuity dependencies and third-party requirements (for example, continuity commitments in contracts and onboarding).
• Technology-dependent delivery: policy should make continuity responsibilities explicit across IT operations, cloud, and application owners.
• Regulated or contractual obligations: policy should reflect that continuity commitments must support customer, regulator, and contractual expectations.

What you actually need to do (step-by-step)

Step 1: Identify “top management” and how they will establish the policy

Decide what “establish” means in your governance reality: board resolution, CEO signature, executive committee approval, or a delegated executive sponsor with defined authority. Document the decision. Auditors will ask who top management is in your org structure and how they approved the policy (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

Practical tip: If you can’t get CEO signature, route through the body that controls enterprise policy, then capture evidence that the approving group meets your definition of top management.

Step 2: Draft a fit-for-purpose policy (keep it short, make it enforceable)

A workable structure:

1. Purpose and intent
   • Why the organization maintains a BCMS and what outcomes it must support.
2. Scope
   • Entities, locations, systems, and services in scope.
   • Clear statement on what is out of scope and how exclusions are handled.
3. Commitments
   • Commitment to meet applicable requirements and to continual improvement of the BCMS, consistent with the provided summary expectations for communication and availability (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).
4. Roles and responsibilities
   • Executive owner, BC manager/coordinator, business owners, IT, facilities, HR, communications, third-party management.
5. BCMS operating rules
   • Requirements to perform BIA and risk assessment.
   • Requirements to maintain plans and exercise them.
   • Requirements for issue tracking, corrective actions, and management review linkages.
6. Communication and availability
   • Where policy is published internally.
   • What version (or excerpt) is shared with customers/other interested parties, and through what channel.
7. Exceptions
   • Who can approve exceptions, time limits, and required compensating controls.

Decision test: If a business owner asks “Do I have to do a BIA?” or “Can I skip an exercise this year?” the policy should give the rule and point to the standard operating procedure.

Step 3: Map the policy to your BCMS objectives and lifecycle

The policy is not the plan. It is the authority layer above the plan. Create a simple crosswalk:

• Policy commitments → BCMS objectives → procedures/standards → evidence produced.

This is how you show the policy is operational, not ceremonial.

Step 4: Run a short stakeholder review focused on conflicts and feasibility

Do a targeted review with:

• Business continuity lead
• IT/technology operations
• Security
• Facilities
• HR
• Communications/PR
• Third-party risk management / procurement
• Legal (if you publish externally)

Ask two questions only:

1. What in this policy is inaccurate for how we operate?
2. What in this policy creates an obligation we cannot currently meet?

Then either adjust the policy or create an action plan to close the gap. Auditors prefer a realistic policy that is implemented over an ambitious one that is ignored.

Step 5: Obtain formal approval and publish as a controlled document

Control the policy like other enterprise policies:

• Document ID, version, owner, approver, effective date, review cadence (your choice), and distribution method.
• Store in a system of record with access controls and version history.

If you use Daydream for GRC document control and evidence collection, treat the policy as a “parent control” and link child evidence (BIA completion, exercise records, corrective actions) directly to it so audits become retrieval work, not archaeology.

Step 6: Communicate and train to the policy’s “need-to-know”

Communication does not require everyone to sit in a class. It requires proof that relevant personnel received and can access the policy. Common patterns:

• Attestation campaign for in-scope business owners and responders.
• New-hire or annual policy acknowledgment for broader staff, if appropriate.
• Targeted briefings for crisis management team and continuity coordinators.

Step 7: Make it available to interested parties “as appropriate”

Decide what you will share externally:

• A public excerpt on your website, a customer trust portal copy, or “available upon request.”
• A redacted version that avoids sensitive operational detail.

Document your decision and keep the published copy under version control (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

Required evidence and artifacts to retain

Keep these artifacts audit-ready:

• Business continuity policy (final, controlled version)
• Approval evidence (signed PDF, meeting minutes, governance tool approval record)
• Document control metadata (owner, version history, effective date, review history)
• Internal communication evidence
  • Intranet posting record, email distribution, learning system assignment, attestations
• External availability evidence (if applicable)
  • Published excerpt, trust portal screenshot/export, “available upon request” process
• Policy-to-BCMS crosswalk
  • Mapping table linking policy commitments to objectives and procedures
• Exception register (if you allow exceptions) and approvals

Common exam/audit questions and hangups

Auditors and certification bodies tend to probe these areas:

1. “Show me where top management established this.”
   • They will want approval evidence and clarity on who qualifies as top management.
2. “How is this policy appropriate to your purpose?”
   • Expect questions about your services, critical activities, customer obligations, and major dependencies.
3. “How do you communicate the policy?”
   • They will ask for proof, not a verbal description.
4. “Where is it available to interested parties?”
   • If you claim it’s available, show the channel and the exact version available.
5. “How does the policy drive action?”
   • They may sample a business unit and ask how the policy requirements are implemented through BIA, plans, and exercises.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Generic template language that doesn’t match the business.
  Fix: Add specifics: scope boundaries, governance model, and clear internal obligations.

• Mistake: Policy promises capabilities you do not have.
  Fix: Write commitments you can meet now, and create improvement actions for the rest. Keep the aspirational content in strategy documents, not policy.

• Mistake: No evidence of communication.
  Fix: Use attestations or tracked distribution for the roles that matter most, then retain records.

• Mistake: Policy exists, but nobody can find it.
  Fix: Publish in a single authoritative location, link it from BCMS procedures, and restrict editing to the document owner.

• Mistake: External sharing is ad hoc.
  Fix: Decide an official external version and an approval workflow for releasing it.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is indirect but real: without an executive-established policy, your BCMS governance is fragile. That shows up as inconsistent BIAs, uneven plan quality, skipped exercises, and unclear authority during incidents. Those gaps become customer escalations, contractual friction, and certification nonconformities under ISO 22301:2019 Clause 5.2 (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

Practical 30/60/90-day execution plan

First 30 days: Establish governance and draft the policy

• Confirm who “top management” is for policy approval in your org.
• Define BCMS scope boundaries at a high level.
• Draft the policy (one to three pages is common in practice; keep length driven by clarity, not volume).
• Build the evidence plan: what you will retain for approval, communication, and availability (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

By 60 days: Approve, publish, and prove communication

• Run stakeholder review focused on accuracy and feasibility.
• Obtain formal approval and publish as a controlled document.
• Execute internal communication to in-scope roles with tracked completion.
• Decide external availability approach and prepare the publishable copy (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

By 90 days: Connect policy to operations and close audit gaps

• Create and store the policy-to-BCMS crosswalk.
• Validate that procedures (BIA, risk assessment, plan maintenance, exercise management) reflect policy requirements.
• Stand up an exceptions workflow if needed and record decisions.
• Perform a quick internal audit-style check: sample a business unit and confirm they can find the policy, explain what it requires of them, and show evidence produced under it.

Frequently Asked Questions

Does the business continuity policy need to be signed by the CEO?

ISO 22301 requires “top management” to establish the policy (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements). If your governance model authorizes an executive committee or equivalent, use that route and retain clear approval evidence.

How detailed should the policy be versus procedures and plans?

Keep the policy directive and enforceable: commitments, scope, roles, and required BCMS activities. Put operational detail (steps, templates, checklists, technical recovery actions) into procedures and plans that the policy governs.

What does “available to interested parties as appropriate” mean in practice?

Decide what you will share externally and how. Many organizations publish a short statement or provide the policy upon request, but you should document the decision and control the externally shared version (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

We have a disaster recovery (DR) policy. Can that satisfy Clause 5.2?

Usually not by itself. DR typically focuses on IT recovery, while the ISO 22301 business continuity policy should cover the BCMS across people, processes, facilities, technology, and third-party dependencies (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

How do we show the policy is “appropriate to the purpose of the organization”?

Tie policy scope and commitments to what you deliver (products/services), where you operate, and what failure would mean for customers and obligations. A brief rationale section and a scope statement aligned to your BCMS scope is often enough, if it is accurate (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

What evidence is most likely to be missing during an audit?

Communication and availability records. Teams often have the policy and the approval, but no tracked proof that relevant roles received it or that the external version (if any) matches the controlled document (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).