Planning of changes

ISO 22301 Clause 6.3 requires you to plan and control any change to your Business Continuity Management System (BCMS) so the BCMS stays effective during and after the change. To operationalize it, run BCMS changes through a defined change process that documents the purpose, assesses consequences, protects BCMS integrity, confirms resources, and assigns accountable owners ¹.

Key takeaways:

• Treat BCMS changes like controlled changes: defined scope, impact assessment, approvals, and verification ¹.
• Prove “planned manner” with evidence: change records, impact/risk notes, decision log, and updated BCMS documents ¹.
• Make operational teams part of BCMS change planning, or you will miss downstream impacts to capabilities, suppliers, and recovery objectives ¹.

“Planning of changes” is a small clause with a large audit footprint because it shows whether your BCMS is managed as a system or as a set of documents. ISO 22301 expects that once you decide a BCMS change is needed, you execute it in a planned manner ¹. For a Compliance Officer, CCO, or GRC lead, that translates into a repeatable change mechanism that keeps business continuity controls current while preventing accidental degradation of resilience.

In practice, BCMS changes are triggered by reorganizations, new products, new critical third parties, technology migrations, lessons learned from incidents, or shifts in risk appetite. Auditors tend to focus less on whether change is happening (it always is) and more on whether you can show disciplined decision-making: why you changed something, what you considered, who approved it, and how you confirmed the BCMS remained coherent afterward ¹.

This page gives you requirement-level implementation guidance: applicability, a step-by-step workflow you can adopt quickly, evidence to retain, common audit questions, and the most frequent failure modes.

Regulatory text

ISO 22301:2019 Clause 6.3 states: “When the organization determines the need for changes to the BCMS, the changes shall be carried out in a planned manner.” ¹

Operator meaning: You must not make ad hoc edits to continuity governance, strategies, plans, roles, objectives, or supporting processes once you decide change is needed. The standard expects controlled execution that accounts for the purpose of the change, potential consequences, the integrity of the BCMS, resource availability, and clear responsibility assignment ¹.

Plain-English interpretation (what “planned manner” means)

A BCMS change is “planned” when you can show, for each change:

• Why you are changing the BCMS (trigger, problem statement, objective).
• What could break because of the change (impacts to continuity capabilities, dependencies, communications, and recovery arrangements).
• How you keep the system coherent (updates don’t conflict with policy, scope, objectives, roles, or upstream/downstream documents).
• Whether you have the means (people, time, tooling, budget authority) to implement and sustain it.
• Who owns each part (accountable approver and implementers) ¹.

Who it applies to

In-scope entities

• Any organization operating a BCMS aligned to ISO 22301, regardless of size or sector ¹.
• Business continuity practitioners and control owners responsible for maintaining BCMS components ¹.

Operational contexts where this clause shows up

This requirement becomes real when you change:

• BCMS scope, policy, or continuity objectives.
• Business Impact Analysis (BIA) methods, outputs, or critical activity definitions.
• Continuity strategies, recovery solutions, or crisis management model.
• Exercise/testing approach or criteria for effectiveness.
• Roles, responsibilities, escalation paths, or communication templates.
• Third-party continuity requirements for critical suppliers and other third parties.
• Documentation structure, tooling, or repositories that hold BCMS content ¹.

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

The goal is a lightweight but defensible BCMS change workflow. You can run it standalone or map it to your enterprise change management process, as long as the BCMS-specific considerations are captured ¹.

1) Define what counts as a “BCMS change”

Create a short definition and examples so teams don’t argue later. Include:

• Changes to BC policy, scope, objectives, governance.
• Material changes to BIA, risk assessment approach, recovery strategies.
• Changes to incident/crisis roles or call trees.
• Changes that affect critical dependencies or recovery capability ¹.

Practical tip: If you already have IT change management, don’t assume it covers BCMS. IT change tickets rarely capture continuity integrity, communications, or cross-functional dependency impacts.

2) Intake and log each change request

Use a BCMS Change Request log (a spreadsheet is acceptable if controlled). Minimum fields:

• Requestor, date, description.
• Trigger (audit finding, incident lesson learned, org change).
• BCMS components affected (policy/BIA/plan/exercise/third party requirement).
• Proposed effective date and urgency ¹.

3) Perform a targeted impact and consequence assessment

Document the consequences you considered. Keep it scoped to BCMS integrity:

• Does it change recovery assumptions, dependencies, or roles?
• Does it affect third-party arrangements or contact paths?
• Does it create conflicts with current BC policy/scope/objectives?
• Does it require retraining, communications, or an updated exercise plan?
• What is the risk of implementing it incorrectly, or not implementing it? ¹

Decision matrix you can use

• Low-impact change: editorial plan updates, formatting, minor contact updates.
• Medium-impact change: process changes, role changes, plan structure changes.
• High-impact change: scope change, strategy change, BIA approach change, major third-party dependency change.
  For medium/high-impact, require explicit BCMS owner approval and a post-change validation step ¹.

4) Confirm BCMS integrity (system coherence check)

Before approving, confirm the change will not break linkages across BCMS elements:

• Policy and objectives still align with updated plans/strategies.
• Scope statement matches what is actually covered.
• Roles/responsibilities align with org charts and on-call models.
• Exercise schedule and acceptance criteria still test the right capabilities.
• External commitments (to customers, regulators, and third parties) remain accurate ¹.

5) Resource and responsibility assignment

For each approved change, assign:

• Accountable owner (BCMS manager or control owner).
• Implementers (process/IT/Facilities/Security/HR/Procurement).
• Required inputs (SMEs, third-party confirmations, training support).
• Operational readiness tasks (communications, training, updates to tooling) ¹.

6) Approve, implement, and communicate

• Record approval (email approval can work if retained and linked).
• Implement changes in controlled repositories (versioning).
• Communicate changes to affected stakeholders, including third-party relationship owners when continuity obligations shift ¹.

7) Validate effectiveness after the change

Validation should be proportional:

• For low-impact changes, do a peer review and confirm documents are published.
• For higher-impact changes, run a tabletop, targeted walkthrough, or control test focused on what changed.
• Update lessons learned back into the change log ¹.

8) Keep the audit trail

Close the change with a completion note and links to updated artifacts. “Planned manner” is proven by traceability ¹.

Required evidence and artifacts to retain

Auditors want a chain from “need identified” to “change controlled”:

• BCMS Change Request log with unique identifiers.
• Impact/consequence assessment notes (even brief).
• Approval record and assigned responsibilities.
• Updated BCMS documents with version history (policy, scope, BIA method, plans, playbooks).
• Communication and training records where roles/processes changed.
• Validation evidence: peer review, exercise results, test outputs, meeting minutes ¹.

Daydream fit (earned mention): If you struggle with linking approvals, documents, and evidence, Daydream can act as the system of record for BCMS change tickets, approvals, and evidence mapping, so each change closes with a defensible audit package rather than scattered files.

Common exam/audit questions and hangups

Expect questions like:

• “How do you decide whether a change affects the BCMS?”
• “Show me the last time you changed your BIA methodology or recovery strategy and how it was approved.”
• “How do you ensure updated plans are distributed and old versions are controlled?”
• “How do you validate that the BCMS still works after a material change?”
• “Who can approve BCMS changes, and how do you prevent unauthorized edits?” ¹

Hangup: Teams present IT change tickets as evidence, but those tickets often omit BCMS-specific integrity checks, continuity impacts, and communications.

Frequent implementation mistakes (and how to avoid them)

1. Treating BCMS as static documentation.
   Fix: run a formal change log even for “small” updates; categorize impact ¹.

2. No consequence assessment.
   Fix: require a short checklist for impacts to roles, dependencies, third parties, and exercises ¹.

3. Breaking BCMS integrity through inconsistent edits.
   Fix: add a coherence review step that checks policy/scope/objectives/roles/plan alignment ¹.

4. Approvals are informal and not retained.
   Fix: define approval authorities and store the approval record with the change ticket ¹.

5. No operational rollout.
   Fix: include comms/training requirements in the change plan whenever behavior or responsibilities change ¹.

Enforcement context and risk implications

ISO 22301 is a standard, not a regulator. Your risk is indirect but real: poor change planning leads to stale plans, unowned recovery steps, and broken dependency assumptions, which tend to surface during incidents, customer due diligence, internal audit, and certification audits ¹. In regulated environments, BCMS weaknesses can also create knock-on issues with operational resilience expectations and contractual commitments, especially where you must demonstrate continuity capability to customers and critical third parties.

Practical 30/60/90-day execution plan

Because timeboxed timelines are not source-backed, treat this as phased execution.

First 30 days (Immediate)

• Define “BCMS change” and approval authorities in one page.
• Stand up the BCMS Change Request log and a simple impact checklist.
• Inventory recent BCMS changes and backfill missing approvals/evidence where feasible ¹.

Next 60 days (Near-term)

• Integrate BCMS change checks into existing enterprise change governance (IT, facilities, org design, procurement).
• Establish version control rules for BCMS documents and publishing/distribution steps.
• Pilot the workflow on a real change (for example, a plan refresh or role update) and capture validation evidence ¹.

Next 90 days (Stabilize and scale)

• Train control owners and business unit continuity coordinators on the workflow.
• Add a “BCMS change review” agenda item to the BCM steering committee or equivalent governance forum.
• Track themes in change requests (common triggers, recurring gaps) and feed them into management review inputs ¹.

Frequently Asked Questions

What counts as a change to the BCMS versus a normal operational change?

A BCMS change is any change that alters BCMS scope, policy, objectives, roles, methods (like BIA), strategies, plans, or validation approach. If it affects recovery assumptions, dependencies, or who does what during disruption, treat it as a BCMS change ¹.

Can we rely on ITIL/IT change management to meet Clause 6.3?

You can map to IT change management, but you still need BCMS-specific checks: consequences to recovery capability, BCMS integrity, and communications/training. If those fields are not captured, you will fail the “planned manner” expectation ¹.

Do small document edits need formal approvals?

Minor edits should still be logged and version-controlled, but approval can be lighter (for example, peer review by the BCMS owner). Auditors mainly want traceability and control over what changed and when ¹.

How do we show “BCMS integrity” in evidence?

Keep a short coherence checklist showing you checked alignment across policy, scope, objectives, roles, and the affected plans. Link it to the change ticket and the updated document versions ¹.

What if a critical third party changes their service or recovery commitments?

Open a BCMS change request tied to the third party event, assess consequences to your continuity strategy and dependencies, and update plans/requirements as needed. Retain the third party communication and your internal decision record as evidence ¹.

What’s the minimum viable set of artifacts for auditors?

A change log entry, documented impact/consequence assessment, approval record, updated controlled documents, and a completion/validation note are usually enough to demonstrate planned change. The depth should match the change impact ¹.

Footnotes

1. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements