Clause 10 closes the “Act” loop of the PDCA cycle. Without it, the BCMS accumulates findings without improvement. With it, every disruption event and exercise becomes a source of systematic enhancement. The organisation identifies what is not working, conducts root cause analysis, implements corrections, verifies that corrections were effective, and feeds the lessons back into the BCMS.
Improvement occurs through two mechanisms: corrective action, which addresses specific nonconformities or findings, and continual improvement, which is the ongoing process of enhancing BCMS capability. The distinction matters: a corrective action fixes a specific problem; continual improvement is the culture and mechanisms through which the BCMS gradually becomes stronger, more robust, and more capable.
Nonconformity and Corrective Action (10.1)
A nonconformity is a failure to meet a requirement. Examples include: a Business Continuity Plan that has not been reviewed within the required cycle, an exercise finding that shows the RTO was not achieved, an internal audit finding that a competence record is missing, a management review finding that a previous corrective action was not implemented. When a nonconformity is identified, the organisation must determine its cause and implement action to address both the immediate issue and the root cause.
The corrective action process is: (1) React and contain — if the nonconformity affects operations, take immediate action to minimise impact; (2) Evaluate — determine whether the nonconformity is minor (isolated, does not indicate systemic non-compliance) or major (indicates systemic problems); (3) Determine root cause — why did the nonconformity occur; (4) Implement corrective action — what will be changed to prevent recurrence; (5) Verify effectiveness — confirm that the action actually prevents the nonconformity from recurring.
Root cause analysis is critical. A corrective action that addresses the symptom (the plan was not reviewed) without addressing the root cause (there is no owner assigned for plan review, or the owner is unaware of the requirement) will produce the same nonconformity at the next audit. True corrective actions address the systemic reason why the requirement was not met. In audits, auditors distinguish between symptom-level corrections and genuine corrective actions. A finding that is closed without root cause analysis will often reappear.
| Nonconformity Type | Example | Corrective Action Approach |
|---|---|---|
| BCP not reviewed within cycle | BCP last reviewed 14 months ago; review cycle is 12 months | Root cause: No owner assigned for plan review; no calendar reminder. Action: Assign owner, establish review schedule, implement reminder system, verify next review completed on time |
| RTO not achieved in exercise | Exercise showed recovery took 6 hours; RTO is 4 hours | Root cause: Actual recovery process is slower than assumed; resource constraints during recovery not accounted for. Action: Review and redesign recovery procedure, test recovery steps with actual staff, revise RTO or invest in faster recovery capability |
| Exercise finding not implemented | Exercise finding identified need for updated contact list 8 months ago; contact list has not been updated | Root cause: No owner assigned, no deadline set, no tracking mechanism. Action: Assign specific owner, set deadline, track in action register, verify completion, implement mechanism to update list quarterly |
| Internal audit finding not closed | Audit finding issued 6 months ago, corrective action not yet implemented | Root cause: Priority unclear, resource constraints, owner did not prioritise the action. Action: Escalate to management review, assign executive sponsor, allocate resources, track weekly until closure |
| Management review not conducted | No management review conducted in 16 months; policy requires annual review | Root cause: No scheduled meeting, no owner responsible for scheduling, business pressure. Action: Establish management review schedule, assign owner, secure calendar time with top management, make non-cancellable |
| BIA not updated following organisational change | Organisation has added new critical supplier; BIA has not been updated to reflect dependency | Root cause: Change management process does not trigger BIA updates; BIA ownership unclear. Action: Establish change management process that flags BCMS impacts, assign BIA owner, establish update schedule when significant changes occur |
| Competence record missing | Staff member assigned to BCM role has no training record; cannot demonstrate competence | Root cause: Competence requirements not defined for the role; training not tracked. Action: Define competence requirements for all BCMS roles, implement training tracking, assess current staff competence, provide training where needed |
| Supplier BCM assessment not completed | Critical supplier has not been assessed for BCM capability; supplier agreement does not reference BCM requirements | Root cause: Supplier assessment process not established; responsibility not assigned. Action: Define critical suppliers, establish assessment criteria, assign ownership, schedule assessments, revise supplier agreements to include BCM requirements |
| IMPORTANT | Root cause analysis is not optional for major nonconformities. ISO 22301 requires the organisation to determine the cause of the nonconformity, implement actions to address the root cause (not just the symptom), and verify that the actions were effective. A corrective action that changes a procedure without addressing why the procedure was not followed in the first place will produce the same nonconformity at the next audit. Auditors distinguish clearly between symptom-level corrections (“we reminded people”) and genuine corrective actions (“we redesigned the process so it cannot fail” or “we assigned clear ownership so accountability is obvious”). |
Continual Improvement (10.2)
Continual improvement is the ongoing process of enhancing BCMS capability. It is not event-driven (only improving when nonconformities are found); it is a cultural commitment to making the BCMS stronger over time. Continual improvement occurs through multiple sources: exercises reveal gaps that should be addressed; audits identify compliance issues and operational improvements; actual disruption events provide the most valuable learning; management review highlights areas where capability is insufficient; and staff suggestions identify process improvements.
Effective continual improvement requires: a mechanism to capture improvement ideas (exercise findings, audit observations, incident post-mortems, staff suggestions); a process to evaluate proposed improvements and decide which to pursue; assigned ownership and timelines; tracking to completion; and communication of improvements once implemented. An improvement log that tracks all proposed improvements, their status, and their completion demonstrates that the organisation is systematically enhancing capability.
The improvement culture is strongest in organisations where employees see that their input leads to action. If exercise findings are documented but never acted upon, staff stop engaging. If audit findings are closed without real change, the BCMS becomes compliance theatre. Organisations with strong improvement cultures communicate how findings are being addressed, involve employees in implementation, and celebrate improvements once they are complete.
Lessons Learned: From Disruption Events to BCMS Enhancement
The most valuable improvement data comes from actual disruption events. When an event occurs — a power outage, a cyber incident, a supplier failure, a building access issue — the organisation experiences real business continuity in action, not a simulation. The response reveals what works in practice and what does not. Post-incident review is the mechanism for capturing this learning and translating it into improvements.
A structured lessons-learned process includes: a post-incident review conducted as soon as operationally feasible after the event; interviews with key people involved in the response; analysis of what worked and what did not; identification of gaps between plan and reality; root cause analysis of why gaps existed; recommendations for improvement; and tracking of implementation until completion. The lessons-learned session is documented and becomes part of the BCMS improvement record.
The most common error is treating an incident that was managed successfully as “no review needed.” Actually, successful incidents are incredibly valuable learning events. What assumptions in the BCP were validated? What staff actions were effective? What decisions had to be made on the fly? Understanding what works is as important as understanding what failed.
| Lessons Learned Source | Typical Findings | BCMS Improvement Action |
|---|---|---|
| Tabletop exercise | Activation criteria ambiguous, key contact list out of date, decision authority unclear | Revise BCP activation criteria; update contact directory; clarify decision-making authority; retest in next exercise |
| Functional exercise | Alternate site access procedures unclear; insufficient equipment pre-positioned; recovery procedures do not match actual system configuration | Update site access procedures and test with security; procure and pre-position equipment; update recovery procedures to match current systems |
| Technical recovery test | RPO not achieved — backup restore takes 6 hours vs. 2-hour target; data consistency issues after restore | Review backup architecture and frequency; increase backup frequency or invest in alternative recovery method; revise RTO if faster recovery is not feasible |
| Actual disruption event | BCP did not account for regulatory reporting obligation occurring during disruption; customer contact email addresses in BCP were outdated | Add regulatory deadline management procedures to BCP; implement process to keep contact directories current; involve regulatory team in BCP development |
| Post-incident review | Staff did not know their BCP roles; communication during the event was chaotic; recovery took longer than planned | Conduct BCP awareness workshop; revise communication procedures and test; analyse recovery timing and revise procedures or adjust RTO |
| Internal audit | Document control procedures not followed for BCP updates; multiple versions of same plan in circulation | Retrain document controllers on version control; strengthen centralised document management; implement process to retire obsolete versions |
| Management review | BCMS resources insufficient for planned exercise frequency; budget allocation has not kept pace with scope expansion | Increase budget allocation for continuity activities; adjust exercise frequency to match available resources, or reduce BCMS scope |
| KEY IDEA | The organisations with the strongest BCMSs treat every disruption event — whether it triggered BCP activation or not — as a mandatory input to BCMS improvement. An organisation that experiences a 4-hour power outage and says “we managed, no formal review needed” is leaving one of the most valuable improvement inputs unused. What actually happened? Did the BCP get activated? Were the procedures followed? Were the contacts reachable? Did the backup generator work? Did recovery timing match the RTO? Systematic post-incident review extracts value from events that were managed successfully as well as those that were not. |
Integrating Improvement Across the BCMS
Improvement is not isolated to Clause 10; it is integrated throughout the BCMS. Clause 9 (Performance Evaluation) identifies where the BCMS is not meeting objectives through KPIs and audit findings. Clause 10 (Improvement) responds to those findings through corrective action and continual improvement. The improvement actions then feed back into Clause 6 (Planning) where the strategy and plans are revised based on what has been learned, and Clause 8 (Operations) where the improved processes are implemented.
This is the PDCA cycle in practice: Plan (Clauses 4–7), Do (Clause 8), Check (Clause 9), Act (Clause 10), and then cycle back to Plan with the improvements made. Organisations that complete this cycle regularly — with management review at least annually and exercises feeding findings into improvements that are tracked and closed — have BCMSs that improve steadily over time. Organisations that do not close the loop — finding problems but not implementing improvements — stall in capability development.
| BITLION INSIGHT | Indonesian organisations that have been through a genuine disruption event — flooding, power failure, a significant cyber incident — and conducted a rigorous post-incident review report that the review produced more valuable BCMS improvements than all their formal exercises combined. The pressure of an actual event reveals assumptions in BCPs, gaps in contact directories, resource constraints that exercises masked, and communication challenges that tabletop scenarios never surface. Building a systematic lessons-learned process into the BCMS operational calendar is the highest-return BCM investment available. When disruption happens, treat it as a learning opportunity. |