Continual improvement

ISO 22301 Clause 10.2 requires you to run an ongoing, evidence-backed improvement cycle for your Business Continuity Management System (BCMS) so it stays suitable, adequate, and effective as your business, threats, and dependencies change ¹. Operationalize it by defining improvement inputs, decision forums, action tracking, and verification, then retaining proof that changes were prioritized, implemented, and validated.

Key takeaways:

• Continual improvement is a system requirement, not a one-time “BCP refresh” ¹.
• You need defined inputs (tests, incidents, audits, metrics, reviews), a decision process, and closed-loop corrective actions ¹.
• Auditors will look for traceability from findings to fixes to effectiveness checks, with clear ownership and records.

Continual improvement is the mechanism that keeps a BCMS from becoming shelfware. ISO 22301 Clause 10.2 is short, but the operational expectation is not: your BCMS must consistently adapt based on what you learn from exercising, incidents, monitoring, audits, management review, and corrective actions ¹. For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat improvement as a managed workflow with defined triggers, governance, and evidence.

This requirement also shows up indirectly in how customers and regulators assess resilience. Even if you are pursuing ISO certification (or aligning without certification), you need a repeatable way to: (1) detect BCMS weaknesses, (2) decide what to change, (3) implement changes under control, and (4) confirm the changes worked. If you already run risk management, internal audit, or issue management, you can often extend those mechanisms to cover BCMS improvement rather than inventing a separate process.

Regulatory text

Text (verbatim): “The organization shall continually improve the suitability, adequacy and effectiveness of the BCMS.” ¹

What the operator must do: Establish and operate a continual improvement process for the BCMS that uses real inputs (monitoring and measurement results, audit findings, management review outputs, corrective actions, and other relevant inputs) to drive documented changes, then verify those changes improved the BCMS ¹.

Plain-English interpretation (requirement-level)

“Continual improvement” means you can show, with records, that your BCMS gets better over time based on evidence. Auditors are not looking for perfection; they are looking for a living system that:

• Detects gaps in continuity capabilities and BCMS governance,
• Turns those gaps into tracked actions with owners and due dates,
• Implements changes in a controlled way (including document updates and training as needed),
• Checks whether the changes fixed the problem and improved outcomes ¹.

Three words matter because they drive how you scope improvement:

• Suitable: aligned to your organization’s purpose, services, operating model, and risk profile.
• Adequate: sufficient design and coverage; not missing key processes, sites, roles, third parties, or technologies.
• Effective: works in practice during exercises and disruptions, not only on paper ¹.

Who it applies to (entity and operational context)

Entity scope: Any organization that has implemented or claims alignment with ISO 22301’s BCMS requirements ¹.

Operational scope: This touches more than the BC/DR team. Expect involvement from:

• Business unit continuity coordinators (process owners and recovery strategies)
• IT and security (DR capabilities, technology dependencies)
• Facilities and workplace (site access, physical constraints)
• Procurement and third-party risk (critical third parties and outsourcers)
• Internal audit / compliance (assurance, issue management)
• Executive leadership (management review decisions and resourcing)

If your continuity posture relies on critical third parties, continual improvement must include how you identify and correct third-party continuity gaps (for example, missing dependency mapping, weak recovery commitments, or untested failover arrangements). The requirement does not mandate a specific third-party method, but it does require your BCMS to improve based on relevant inputs ¹.

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

1) Define the improvement “engine” (inputs → decisions → actions → verification)

Create a simple BCMS Continual Improvement Procedure that answers:

• Inputs: What sources create improvement items?
• Triage: How do you log, classify, and prioritize them?
• Governance: Who approves changes and assigns resources?
• Closure: What evidence is required to close an action?
• Effectiveness check: How do you confirm improvement worked? ¹

Practical input sources to list explicitly (aligned to ISO’s summary language) include:

• Monitoring and measurement results (BCMS KPIs/KRIs, control performance)
• Exercise/test outcomes (findings, after-action reviews)
• Incident and disruption lessons learned
• Internal audit / assurance findings
• Management review outputs (decisions, priorities)
• Corrective actions and nonconformities
• Material business changes (new services, sites, systems, third parties) ¹

2) Stand up a single place to track BCMS improvements

Use an issue/action register (spreadsheet, GRC tool, ticketing system) that supports traceability. Minimum fields:

• Unique ID
• Source (exercise, incident, audit, metric, management review)
• Description of the gap and impact (service/process affected)
• Root cause notes (as appropriate)
• Risk/severity rating and prioritization rationale
• Owner and stakeholders
• Target completion date and dependencies
• Required artifacts for closure
• Effectiveness check method and date
• Closure approval ¹

If you use Daydream for third-party risk and resilience governance, map BCMS improvement items that involve third parties (for example, continuity attestations, recovery commitments, test participation) into the same action workflow so procurement and the business can execute and prove closure without parallel tracking.

3) Put governance around prioritization and acceptance

Define who can:

• Approve remediation work,
• Accept residual risk when an item cannot be fixed quickly,
• Defer an item with a documented rationale ¹

Auditors will challenge “parked” findings. If you defer, document the decision, the compensating controls, and the trigger that will force reconsideration (for example, next exercise cycle, contract renewal, or architectural change).

4) Control the change (don’t treat improvement as informal edits)

When an improvement item requires change, ensure:

• BCMS documents are updated under document control (plans, procedures, call trees, dependency maps)
• Training/awareness is updated for affected roles
• Technical or operational changes follow your change management process
• Third-party changes are reflected in contracts, SLAs, or due diligence records where relevant ¹

5) Verify effectiveness before you close

Closure should require proof that the fix works. Examples:

• Re-test a recovery step that previously failed
• Run a tabletop focused on the corrected process
• Confirm monitoring/metrics now show expected performance
• Validate a third party provided updated recovery evidence and it matches your dependency assumptions ¹

6) Feed management review with improvement themes

Summarize trends for leadership:

• Recurring failure points (communications, dependencies, staffing, third parties)
• Capacity constraints and resourcing needs
• Decisions required (risk acceptance, investment, strategy changes)
• Systemic issues vs. one-off fixes ¹

Required evidence and artifacts to retain

Auditors typically expect to see a complete chain from input to verified improvement. Retain:

• BCMS Continual Improvement Procedure (or equivalent documented process)
• BCMS improvement register with status history
• Exercise/test plans and after-action reports with findings
• Incident post-mortems and lessons learned (where continuity-relevant)
• Internal audit reports related to BCMS scope
• Management review minutes/outputs showing decisions and assigned actions
• Corrective action records (including root cause and verification)
• Document control records for updated BCMS materials
• Evidence of effectiveness checks (re-test results, tabletop notes, metric snapshots)
• Third-party continuity evidence when dependencies are material (attestations, reports, contractual updates, joint test participation records) ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me how you continually improve the BCMS, end-to-end.” They want the workflow, not a policy statement ¹.
• “Pick one exercise finding and trace it to closure.” If you can’t show ownership, decisions, and verification, you will struggle.
• “How do you ensure improvements stay aligned with changes in the business?” You need a defined trigger from change management, risk assessment, or service onboarding.
• “How do management review outputs become actions?” Meeting notes must translate into tracked items.
• “How do you confirm effectiveness?” Closure without verification reads as administrative, not operational.

Frequent implementation mistakes (and how to avoid them)

1. Treating plan updates as “improvement.” Updating a document without changing capability does not prove effectiveness. Require an effectiveness check artifact before closure.

2. Scattered action tracking. Findings live in email, spreadsheets, and tool tickets with no reconciliation. Fix: one register, one owner, defined intake from every source ¹.

3. No prioritization logic. Everything is “high,” or nothing has a rationale. Add a simple severity approach tied to critical services and recovery assumptions.

4. Closing actions based on intent. “Will be addressed next quarter” is not closure. Close only when implemented and verified.

5. Ignoring third-party dependencies. If a third party failure would break recovery, improvements must cover contracting, testing, and evidence collection. Track these items alongside internal fixes.

Enforcement context and risk implications

No public enforcement cases were provided for this specific ISO clause in the source catalog. Operationally, the risk is straightforward: a stagnant BCMS fails under real disruption, and an audit-ready but untested program creates false assurance. Continual improvement reduces that risk by forcing you to learn from audits, tests, incidents, and measurement and convert those lessons into validated changes ¹.

Practical 30/60/90-day execution plan

Because you cannot cite exact time expectations from ISO 22301 Clause 10.2, treat the phases below as an implementation sequence, not a mandated timeline ¹.

First 30 days (set the mechanism)

• Assign an executive owner for BCMS continual improvement and an operational owner for the register.
• Draft and approve the Continual Improvement Procedure (inputs, governance, closure, effectiveness checks).
• Create the improvement register and migrate existing open findings (exercises, audits, incidents).
• Define what “closure” requires (evidence checklist).

Days 31–60 (run it on real inputs)

• Hold an improvement triage session; prioritize items tied to critical services and key dependencies.
• For top items, document corrective actions, owners, and expected effectiveness checks.
• Update document control and change management touchpoints so material business changes create BCMS review items.
• For critical third parties, identify continuity evidence gaps and open actions to close them.

Days 61–90 (prove effectiveness and stabilize)

• Complete effectiveness checks for early closed actions (re-tests, targeted tabletops, metric validation).
• Produce a management review pack that includes improvement trends, decisions, and resourcing asks.
• Audit your own process: sample a few items from each input source and confirm they enter the register and close with evidence.
• Establish steady-state cadence (regular triage, leadership reporting, and periodic verification sampling).

Frequently Asked Questions

Do we need a separate continual improvement process just for BCMS?

No, but you must be able to demonstrate a complete improvement loop for BCMS scope, including inputs, tracked actions, and effectiveness checks ¹. Many teams extend enterprise issue management and document control if they can show BCMS traceability.

What counts as acceptable “inputs” for continual improvement?

Use monitoring and measurement results, audit findings, management review outputs, corrective actions, and other relevant inputs such as exercise results and incident lessons learned ¹. The key is that inputs are defined and consistently captured.

How do we prove “effectiveness” without running large exercises every time?

Match the verification method to the change: a targeted tabletop, a re-test of the failed step, or evidence that a metric moved in the expected direction can be enough ¹. Require some form of verification before closure.

Can we close actions if we accepted the risk instead of fixing it?

You can close an action as “risk accepted” if the decision is documented, approved by the right authority, and tied to a rationale and any compensating controls ¹. Keep it traceable and revisit when conditions change.

How should we handle continual improvement items that involve third parties?

Track them the same way as internal items, with clear owners across procurement, the business, and BCMS leadership. Closure evidence often includes updated continuity commitments, due diligence artifacts, or proof of coordinated testing ¹.

What’s the fastest way to fail an ISO 22301 audit on this clause?

Having findings with no ownership, no closure criteria, or no proof that changes were implemented and verified. Auditors typically sample from exercises, audits, and management review outputs and expect to see end-to-end traceability ¹.

Footnotes

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