ISO 22301 Clause 10.1: Nonconformity and Corrective Action

Quick Reference (60 Seconds)

The one-line summary: Clause 10.1 is the closed loop that turns every "we found a gap" moment, from an audit, an exercise, a real disruption, a near-miss, a regulator, or a complaint, into evidence that the gap was understood at its root, fixed, verified to stay fixed, and folded back into the BCMS so the next audit finds a different gap, not the same one.

What the Standard Actually Requires

Figure · Process

What Clause 10.1 asks you to do

What the clause requires in substance

ISO 22301 Clause 10.1 asks organizations to react to nonconformities, deal with their consequences, and correct root causes so they don't recur. The clause lives inside Clause 10 (Improvement) as the reactive improvement mechanism, paired with Clause 10.2 (Continual Improvement), which is the proactive mechanism. The two together complete the BCMS PDCA "Act" loop.

Practically, the clause decomposes into a six-step loop that an auditor will trace end-to-end:

1. React. When a nonconformity is detected, by audit, exercise, incident, near-miss, surveillance, monitoring, regulator, customer, supplier, or employee, the organisation has to react to it. Reacting does not mean "fix it on the spot"; it means acknowledging the finding, controlling it, and starting the formal loop.
2. Control and correct; deal with consequences. Take immediate action to (a) control the nonconformity (stop the bleeding) and (b) correct it (restore conformity), and (c) deal with the consequences (whatever harm or potential harm the nonconformity caused or could have caused). In BCM terms, this is your containment and correction step, the equivalent of an incident-response action for the management system itself.
3. Evaluate the need to eliminate root causes. Not every nonconformity needs a corrective action. The organisation must evaluate whether action is needed to eliminate the root cause(s) so the nonconformity does not recur or occur elsewhere. This is a deliberate decision step, "evaluate the need", and the decision (whether yes or no) must be defensible and recorded.
4. Implement corrective action. Where the evaluation says action is needed, implement it. Corrective action is by definition aimed at root cause(s), not symptoms.
5. Review the effectiveness of corrective action. This is the step most organisations omit and most auditors probe. After implementing the action, the organisation must verify whether it actually worked, did the nonconformity stay closed? Did the root cause disappear? Did the change have unintended side effects on other BCMS processes?
6. Update risks and opportunities; make changes to the BCMS if needed. Corrective action often changes the risk picture (a previously unidentified risk is now on the register; a control gap is now closed; a new opportunity to improve emerges). The organisation must feed those updates back into Clause 6.1 (Actions to Address Risks and Opportunities) and, where necessary, into the formal BCMS, the documented information, the scope, the policy, the objectives.

The clause also requires documented information retained as evidence, records that capture, for every nonconformity: (a) what went wrong and what was done about it, the character of the nonconformity itself plus every action that followed from it; and (b) whether the fix worked, the outcome of each corrective action. The documented information is the auditable proof that the loop ran.

What the clause does NOT require

This demarcation matters because certifiers test it:

• 10.1 is reactive; 10.2 is proactive. 10.1 is triggered by a detected nonconformity (something already went wrong or was found to be nonconforming). 10.2 is the ongoing raising of the suitability, adequacy, and effectiveness of the BCMS, improving what already works. The same output (a plan change, a control improvement) can come from either, but the trigger differs.
• 10.1 is not "fix every finding immediately." The clause explicitly says "evaluate the need", meaning a risk-based decision is allowed. A minor NC in a low-criticality plan reviewed annually may legitimately be deferred or accepted; a major NC in a Tier-1 recovery procedure cannot. The decision must be defensible, documented, and risk-based.
• 10.1 is not "corrective action = retraining or rewriting the document." If every NC in your register has the action "retrained staff" or "updated procedure," an auditor will conclude your RCA is shallow. Retraining and rewriting are sometimes the right answer, but only after a real root-cause analysis points there.
• 10.1 is not the same as incident response (Clause 8.4.2). Incident response is the operational reaction to a disruption. 10.1 is the management-system reaction to a nonconformity, which may include "the disruption revealed that our plan was wrong." An incident can produce many nonconformities; 10.1 is the layer that closes them.
• 10.1 is not internal audit (Clause 9.2). Internal audit is the independent detection mechanism. 10.1 is the response mechanism that consumes audit findings as inputs. The two must remain independent: internal audit should not own the corrective action it recommended, or it loses its independence for the next cycle (ISO/IEC 17021-1, the certification audit rule-set, is strict on this).
• 10.1 is not the same as the corrective action in ISO 27001 Annex A or ISO 9001. The wording is parallel (and deliberately so, ISO's Harmonised Structure), but the subject is the BCMS. A BCMS nonconformity is not "a control failed"; it is "the BCMS does not conform to a requirement", which could be a procedural gap, a missing record, an unmet objective, an unaddressed risk, or an unexercised plan.

The four-stage NCR→CAPA→effectiveness-check loop

For audit-traceability, organisations should think of 10.1 as a four-stage pipeline that produces evidence at each stage:

A certifier tracing one or two sample NCRs end-to-end through this table is the single most common Clause 10.1 audit technique.

The "evaluate the need" trap

The phrase "evaluate the need for action to eliminate the root causes" is the most misunderstood element of 10.1. Organisations often treat it as a checkbox ("yes, we need action") and jump to implementation. The actual requirement is to make a defensible, risk-based decision:

• Is the root cause likely to recur elsewhere? (e.g., a flawed plan template is used across 12 plans, fixing one without fixing the template guarantees 11 future NCRs.)
• What is the risk of recurrence against the cost/impact of the corrective action?
• Is there a more fundamental BCMS change needed (a policy change, a scope change, an objective change)?
• Or is the right decision "no action beyond containment", because the NC was a one-off, the risk is negligible, and the cost of corrective action is disproportionate?

All four answers are legitimate; the requirement is to have asked the question and to have an evidence trail for the answer.

What auditors actually check (certification & surveillance)

Across BSI Group, DNV, SGS, TÜV, Bureau Veritas, Intertek and NQA engagements, the following checks recur:

1. A live NC register (spreadsheet, GRC tool, or database) covering NCs from all sources, not just audit.
2. Sampled end-to-end traces of 2–5 NCRs, from the trigger to the closure evidence, looking for the four stages above.
3. The effectiveness check, the single most-failed element. Auditors expect a defined interval (commonly 30/60/90 days post-implementation) and a documented review of whether the NC stayed closed.
4. Management-review visibility (Clause 9.3) of open NCs, aging NCs, recurring NC themes, and the effectiveness of past corrective actions.
5. RCA quality, they will read the RCA worksheet and check whether the method was applied correctly (e.g., did 5-Why actually go five layers deep, or did it stop at layer two?).
6. Recurrence, if the same NC appears twice within a cycle, the corrective action was ineffective by definition. This becomes a major NC against Clause 10.1 itself.
7. Risk-and-opportunity update, for major NCs, the auditor will check whether the Clause 6.1 risk register or the BCMS documentation was updated as a result.

Why This Control Matters

The "open loop" failure pattern

Most BCMS failures that reach the public record are not detection failures, the problem was seen, escalated, and documented, they are closure failures. The organisation detected the gap, contained it, declared victory, and never closed the root-cause loop. Three to twelve months later, the same gap resurfaces in a different team, a different system, or a different incident. Regulators and certifiers treat recurrence as the single most damning evidence that the management system is not actually a system.

The pattern is so reliable across Indian and global incidents that it has its own shorthand in audit culture: "the DBS / MAS-action recurrence pattern", named after the Singapore regulator's recurring action against a bank whose digital-banking outages kept happening despite earlier corrective commitments. The same pattern recurs in the Indian record:

• HDFC Bank's repeated digital outages (Nov 2018, Dec 2019, Nov 2020) led the RBI to take a Clause 10.1-grade enforcement action on 2 December 2020, barring HDFC from new digital products and fresh credit cards, and asked its board to examine the lapses and fix accountability. The banking regulator's framing was precisely that the bank's own corrective action loop had not closed; otherwise the third outage in two years would not have happened. The credit-card ban was partially lifted only around August 2021 (~8 months) and the full digital-initiatives ban around March 2022 (~15 months), a corrective-action window measured in years, not the days that the BCMS expects.
• AIIMS Delhi's ransomware (23 November 2022) shows why corrective action has to reach the root cause: the government cited improper network segmentation, which is a design weakness that restoring service does not remove. The post-incident review's most cited corrective action was offline, air-gapped backups and tested clinical failover; that this was news in 2022 tells you the prior loop was open.

The pattern is identical in the global record: the DBS/MAS recurrence in Singapore (multiple digital-banking disruptions across 2021 and 2023, each followed by corrective commitments that did not prevent the next event), and the SpiceJet/DGCA enhanced surveillance (in-flight snags in 2022 leading to a 50%-of-schedule cap, extended, then resumed in 2023, then again in 2024, chronic recurrence of the same findings).

The Indian regulatory context, why 10.1 is now a board-level duty

Clause 10.1 looks like a procedural, internal-audit-grade requirement, but the Indian regulatory environment has progressively made the closure of findings a board-level and a regulator-facing duty:

• RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (issued 7 November 2023, effective 1 April 2024) makes the board and senior management accountable for the closure of supervisory findings. A bank whose RBI inspection raises deficiencies and does not close them within the agreed timeline faces supervisory action, including restrictions on the digital products it can launch. HDFC (2020) is the precedent.
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) (circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, dated 20 August 2024) structures the regime around six cybersecurity functions: Governance, Identify, Protect, Detect, Respond, Recover. The "Evolve" goal is the regulatory restatement of Clause 10.1: a SEBI-regulated entity must turn incidents, exercises, and audit findings into documented corrective actions, tracked to closure, and reported back to the regulator.
• SEBI BCP/DR for MIIs (circular SEBI/HO/MRD1/DTCS/CIR/P/2021/33, dated 22 March 2021) requires MIIs (stock exchanges, clearing corporations, depositories) to report not just incidents but the corrective actions taken to prevent recurrence, a direct 10.1-grade obligation.
• RBI Cyber Security Framework in Banks (2 June 2016) requires periodic cyber drills, board-reviewed CCMP (Cyber Crisis Management Plan), and reporting of cyber incidents within 2–6 hours. Each reported incident becomes a potential NC; the closure of those NCs is examinable.
• IRDAI Information and Cyber Security Guidelines, 2023 (24 April 2023) requires insurers to submit annual compliance reports within 90 days of financial year-end, including the status of corrective actions from prior-year findings.
• CERT-In Directions (No. 20(3)/2022-CERT-In, dated 28 April 2022), the six-hour incident-reporting clock creates a stream of incidents that flow into the 10.1 pipeline. A reportable incident is, by definition, a candidate NC.
• DPDP Act 2023 (Act 22 of 2023) and the DPDP Rules 2025, Section 8(5) requires reasonable security safeguards against a personal data breach, which includes loss of availability; Section 8(6) makes breach notification mandatory. A breach is a nonconformity against the DPDP security-safeguards duty; the corrective action that follows is now a statutory expectation, with penalties up to ₹250 crore for inadequate safeguards and ₹200 crore for breach-notification failure.
• Companies Act 2013, Section 134(3)(n) requires the Board's Report to include a statement on the development and implementation of a risk-management policy, including risks that may threaten the existence of the company. The Audit Committee, under Section 177(4)(vii), must evaluate internal financial controls and risk-management systems, and that evaluation includes whether prior findings were closed. Un-closed findings across cycles are a board-reportable risk.
• SEBI LODR Regulation 21 requires the top 1,000 listed entities by market capitalisation to constitute a Risk Management Committee, whose role covers cyber-security risk and business continuity planning. The RMC is the natural forum for reviewing recurring NC themes, the 10.1 trend signal that boards now expect to see.

The strategic implication for a growing Indian company: Clause 10.1 is no longer an internal-management-system nicety; it is the regulatory and statutory expectation for how you handle findings. Whether or not you pursue ISO 22301 certification, the Indian regulatory matrix (RBI/SEBI/IRDAI/CERT-In/DPDP/Companies Act) now expects the same closed loop that 10.1 codifies.

The cost of an open loop, by sector

The cost of a single un-closed NC

For a growing Indian company, a single un-closed major NC against an IT DR plan, traced to a real digital outage, costs the organisation in five ways:

• Containment and correction (the day-of): overtime, customer SLA credits, incident-response cost.
• Lost revenue during disruption, which for a digital-first business accrues by the hour.
• Regulatory engagement (RBI/SEBI/IRDAI response, mandated audit).
• Customer churn after a public incident, typically heavier for a B2B SaaS firm than for a BFSI entity.
• Brand recovery (comms, PR, customer outreach).
• Certification impact: a major NC at surveillance becomes a recommendation for continued certification with conditions; a recurrence is a major Clause 10.1 NC that can suspend certification.

Together these dwarf the annual cost of running a credible Clause 10.1 programme.

Scope and Applicability

Applicability by organisation size

Clause 10.1 applies identically to every organisation in scope of ISO 22301, there is no small-organisation exemption. What changes by size is the machinery:

Applicability by sector (India)

What is in scope for Clause 10.1 vs out of scope

In scope (Clause 10.1 applies):

• Any nonconformity against any ISO 22301 clause (4.1 through 10.2).
• Nonconformities from any source: internal audit, external/supervisory audit, management review, exercise (8.5), real disruption (8.4 activation), post-disruption review (8.6), monitoring/measurement (9.1), customer complaint, supplier issue, near-miss, employee report, regulatory inspection.
• BCMS process nonconformities (e.g., BIA not updated within cadence; plan not exercised within target interval; RTO/RPO targets consistently missed in tests; documented information missing or out of version).
• Subcontractor / outsourced-process nonconformities that touch the BCMS (Clause 8.1).

Out of scope (or different clause):

• Operational incident response to a disruption (Clause 8.4.2), that is the live response; 10.1 is what happens after the response is over.
• Proactive improvement (Clause 10.2), improvements you make before any NC is detected.
• Risk treatment actions (Clause 6.1), those address risks, not nonconformities. (But 10.1 updates 6.1.)
• Internal audit findings that are recommendations (not nonconformities). Recommendations can be handled as opportunities under Clause 10.2; nonconformities must go through 10.1.

Key Definitions and Terminology

These definitions are paraphrased for this guide from the ISO 22300:2021 vocabulary and BCM practitioner usage. They are working definitions, not verbatim standard text.

• Nonconformity (NC). The non-fulfilment of a requirement. In the BCMS, an NC is any gap between what ISO 22301 (or your own BCMS documentation) requires and what is actually happening, a missing record, an unmet objective, an outdated plan, an unexercised scenario, an RTO missed in a test, a regulatory finding left unaddressed.
• Major nonconformity. An NC that shows a significant breakdown of the BCMS, total absence of a required process, systemic failure across multiple areas, or a recurrence of a previously closed NC. Major NCs at certification audits result in conditions, suspension, or non-recommendation.
• Minor nonconformity. A single or isolated lapse that does not (yet) indicate systemic failure. Minor NCs typically need a corrective-action plan within a defined window (often 60–90 days) and verification at the next surveillance.
• Observation / opportunity for improvement (OFI). Not a nonconformity. A suggestion that the organisation could improve. OFIs feed Clause 10.2, not 10.1, and do not require closure.
• Conformity. Fulfilment of a requirement. The default state the BCMS is supposed to be in.
• Corrective action. Action to eliminate the cause of a detected nonconformity and prevent recurrence. Corrective action is by definition root-cause oriented; "I fixed it" without root-cause work is correction, not corrective action.
• Correction. Immediate action to fix the symptom, restore the affected process, repair the missing record, restore the failed system. Correction is what you do on the day; corrective action is what you do to make sure it doesn't happen again.
• Preventive action. Action to eliminate the cause of a potential nonconformity (one that has not yet happened). Note: ISO 22301:2019 (following the Harmonised Structure) folds prevention into Clause 6.1 (risks and opportunities) and 10.2 (continual improvement), the term "preventive action" is no longer a standalone requirement as it was in ISO 22301:2012. The CAPA acronym (corrective and preventive action) persists in industry usage, but in 22301:2019 the "P" is handled elsewhere.
• Containment. Action to limit the spread or impact of the nonconformity while root cause is being investigated. The Clause 10.1 equivalent of incident containment.
• Root cause. The fundamental reason a nonconformity occurred, the factor that, if removed or changed, would prevent recurrence. Identifying the root cause is the central job of Clause 10.1.
• Root-cause analysis (RCA). A structured method for identifying root causes. Common methods (covered in Section 7): 5-Why, the Ishikawa / fishbone diagram, Fault Tree Analysis (FTA), the IS / IS-NOT matrix, the bow-tie analysis, and Failure Mode and Effects Analysis (FMEA).
• Effectiveness check / verification of effectiveness. The post-implementation review that confirms the corrective action actually eliminated the root cause and the NC has not recurred. The required sixth step of the 10.1 loop.
• Closure. The formal state where the NC is closed in the register after the effectiveness check confirms success.
• Recurrence. The reappearance of the same (or substantially similar) NC after closure. Recurrence is the definitive evidence that the prior corrective action was ineffective, and itself becomes a new, more serious NC against Clause 10.1.
• NCR (Nonconformity Report). The documented record of a single nonconformity and its lifecycle through the loop.
• CAPA (Corrective and Preventive Action). The industry term for the formal action plan arising from RCA. In ISO 22301:2019, "CAPA" usually means "corrective action plan" only; the preventive side is in Clause 6.1.
• NC register / CAPA log. The single source of truth listing all open and closed NCs, with their lifecycle states. Required as documented information under Clause 10.1.
• Loop closure. The completed end-to-end run of detect → contain/correct → RCA → corrective action → effectiveness check → close.
• Lesson learned. The generalised insight from a closed NC that, when fed back into the BCMS (Clause 6.1 / 7.5 / 8.x), prevents the same class of NC elsewhere, the multiplier effect that turns one closed NC into a system-wide improvement.
• Trend / recurring NC theme. A pattern across multiple NCRs pointing to a deeper systemic cause, e.g., "every Q4 we miss our DR-test schedule" or "every ransomware near-miss traces back to a backup not tested." Trends are the most important Clause 9.3 management-review input from the 10.1 process.

Relationship to Other Clauses

Clause 10.1 is the consumer and closer of the BCMS's findings pipeline. It receives inputs from most other clauses and feeds outputs back into them.

The evidence flow into 10.1 (inputs)

The decision flow out of 10.1 (outputs)

The 10.1 ↔ 9.2 ↔ 9.3 triangle (most-tested relationship)

The three clauses that most often appear together in audit questions are 9.2 (internal audit), 9.3 (management review), and 10.1 (corrective action). The relationship is:

• 9.2 generates NCs (independently).
• 10.1 closes NCs (with documented effectiveness checks).
• 9.3 reviews the open-NC list, the aging, the trends, and the effectiveness of past corrective actions, and may raise new actions or close-out decisions.

A frequent audit failure: the same person owns all three. Internal audit independence (ISO/IEC 17021-1 principle) is broken if the internal auditor owns the corrective action they recommended; the management review loses teeth if the reviewer is also the implementer. RACI discipline (see Section 7 and Toolkit Doc 13) is essential.

The 10.1 vs 10.2 demarcation (the second most-tested)

In practice, the same output (e.g., a plan rewrite) can flow from either clause. The demarcation matters for audit traceability, the trigger determines which clause it sits under.

Relationship to other ISO standards

• ISO 27001:2022 has an identical Clause 10.1 (nonconformity and corrective action) and Clause 10.2 (continual improvement). If you run ISMS and BCMS together, you can share the NCR register and the CAPA procedure across both management systems.
• ISO 9001:2015 has the identical Clause 10.2. The QMS corrective-action machinery is the same, a single QMS+BCMS+ISMS CAPA procedure is common in mature organisations.
• ISO/IEC 17021-1:2015 (the rule-set governing certification audits) defines what constitutes a nonconformity at the certification audit and how certifiers report and track them. The IAF Mandatory Documents add sector-specific rules; note: there is no BCMS-specific IAF MD (IAF MD 6 is for GHG validation), so 17021-1 + the auditor's own method govern.
• ISO 22313:2020 (the companion guidance) offers a §10 commentary on how to read Clause 10.1 in practice.

Detailed Implementation Guidance

This section walks through the eight steps of building a defensible Clause 10.1 programme, tiered for growing companies.

Step 1, Establish the NCR/CAPA procedure (the documented information)

The single most important artefact is a written NCR/CAPA procedure. Without it, every nonconformity is handled ad hoc, and ad-hoc handling is what produces the recurrence pattern. The procedure should specify:

• Sources of NCs, the list from Section 6.1 above.
• NC classification, major / minor / observation, plus a severity rating tied to the BIA criticality of the affected prioritised activity.
• Logging requirements, the fields each NCR must capture (see Toolkit Doc 02 for a full template).
• Roles, who raises, who owns, who verifies, who closes.
• Timelines, target turnaround for each stage (containment, RCA, corrective action, effectiveness check) by severity.
• RCA toolkit, which methods the organisation uses, when each applies, and who is trained on them.
• Effectiveness check, defined interval (e.g., 30/60/90 days post-implementation) and criteria.
• Escalation, aging thresholds that escalate to the BCM Forum, the management review, and the board committee.
• Closure, the formal closure criteria and the authority that signs off.
• Trend analysis, how recurring themes are detected and reported.
• Documentation, the register, the RCA worksheets, the effectiveness-check records, the management-review pack.

A 4–8 page procedure is sufficient for most growing companies (250–2,000 employees). The toolkit (Doc 01, 02) provides a ready-to-customise skeleton.

Step 2, Stand up the NC register (single source of truth)

The register is the auditable artefact. Required fields, at minimum:

• NCR ID (unique, sequential, never reused).
• Date raised, raised by, source (audit / exercise / incident / regulator / customer / employee / monitoring).
• BCMS clause reference (which ISO 22301 clause is nonconforming).
• Description (factual, non-judgemental; what was found, where, when, against what requirement).
• Classification, major / minor / observation; severity; BIA criticality of affected activity.
• Containment / correction, what was done immediately; what consequences were dealt with; evidence.
• Root-cause analysis, method used; the analysis itself (5-Why chain, fishbone, FTA, etc.); verified root cause(s).
• Decision on action, whether corrective action was needed; rationale if "no."
• Corrective action plan, actions, owners, target dates, dependencies.
• Implementation evidence, what was done, when, by whom; link to changed documents.
• Effectiveness check, method, interval, result; evidence.
• Closure, date closed, closed by, authority sign-off.
• Cross-references, link to risk register (6.1), to changed docs (7.5), to exercises (8.5), to management review (9.3), to regulator reporting.

The register can be a structured spreadsheet for small / growing companies or a module in an enterprise GRC/IRM suite for larger firms. The auditors do not care about the tool; they care that the fields exist and are populated.

Step 3, Build the RCA toolkit

The heart of Clause 10.1 is root-cause analysis. A mature BCMS uses several methods, each suited to a different kind of NC. Train at least 2–4 internal RCA facilitators.

Method 1: 5-Why. The simplest and most widely applicable method. Ask "why" iteratively (typically five times) until you reach a cause that, if addressed, would prevent recurrence.

Worked BCM example, missed DR-test RTO:

1. Why did we miss the RTO? → The recovery script failed at step 7.
2. Why did step 7 fail? → It tried to connect to a hostname that did not resolve.
3. Why did the hostname not resolve? → The DNS record was changed last month and the script was not updated.
4. Why was the script not updated? → There is no link between the DNS change process and the DR script owner.
5. Why is there no link? → The change-management process does not classify DR-dependencies as a category requiring DR-script review.

Root cause: Change management does not flag DR-dependent assets. Corrective action: Add a "DR-impact" attribute to every change record; auto-route DR-dependent changes to the DR script owner for review. Effectiveness check: After 90 days, audit a sample of DR-dependent changes to confirm the DR script owner was notified and the scripts were updated; rerun the DR test and confirm RTO is met.

The most common 5-Why failure is stopping at layer 2 or 3 (which gives a symptom, not a root cause). The second most common failure is "human error" as a layer, "the operator made a mistake" is rarely a root cause; the next why is "why was it possible for the operator to make that mistake?"

Method 2: Ishikawa / fishbone diagram. A categorised brainstorming method. For BCM, the typical categories are: People, Process, Technology, Suppliers, Premises, Information, External. The team brainstorms causes in each category, builds the diagram, then prioritises the most likely root causes for verification.

Use it when: The NC has multiple possible causes or the team is diverse and needs a structured brainstorming method. Particularly suited to mid-complexity NCs (e.g., "the exercise exposed widespread confusion about activation authority").

Method 3: Fault Tree Analysis (FTA). A top-down, deductive method using Boolean logic (AND/OR gates) to map how a failure (the top event) could result from combinations of lower-level failures.

Use it when: The NC is high-severity, low-frequency, and you need to understand how multiple failures combined (e.g., "how did the ransomware reach the primary and the backup?"). FTA is the most rigorous of the methods and the best for complex, multi-cause NCs.

Method 4: IS / IS-NOT matrix. A differential-diagnosis method. List what the problem is and where/when/extent; then list what it is not. The contrasts narrow the field of possible causes.

Use it when: The problem is poorly defined and needs framing before RCA proper begins.

Method 5: Bow-tie analysis. A visual method that places the NC (the "top event") in the middle, with threats on the left, consequences on the right, preventive barriers between threats and the top event, and reactive/recovery barriers between the top event and consequences. Particularly suited to BCM because it integrates preventive and recovery thinking.

Use it when: The NC is high-consequence and you want to design a complete preventive + recovery barrier set, not just identify the root cause.

Method 6: Failure Mode and Effects Analysis (FMEA). A systematic method that scores each potential failure mode by severity × occurrence × detectability to compute a Risk Priority Number (RPN).

Use it when: You have a complex system (a recovery procedure, a supply chain, a multi-step plan) and you want to prioritise which failure modes to invest in fixing.

Method 7: Timeline / sequence reconstruction. Used heavily in incident-driven RCA: build a minute-by-minute timeline of what happened, then identify the decision points and the failures.

Use it when: The NC arose from a real disruption or exercise and you have logs to reconstruct.

The procedural rule is: pick the method to fit the NC, not the NC to fit the method. Most BCMSs standardise on 5-Why for the majority of NCs, fishbone for cross-functional NCs, FTA for high-severity NCs, and timeline for incident-driven NCs.

Step 4, Define containment, correction, and consequence-handling

The second step of the 10.1 loop (control and correct, deal with consequences) is often confused with corrective action. They are different:

• Containment is what you do immediately to stop the bleeding, isolate the affected system, switch to manual mode, roll back the change, invoke the alternate site, freeze the affected plan, suspend the affected supplier.
• Correction is what you do to restore conformity, fix the missing record, restore the failed service, repair the broken script, re-run the failed backup.
• Consequence handling is what you do about the impact, notify the customer, report to the regulator, pay the SLA credit, compensate the affected patient, mitigate the reputational damage.

These three together are the "day-of" response to the NC. Corrective action, the root-cause work, comes after containment/correction/consequence-handling. The procedural rule: every NCR must have a documented containment/correction/consequence-handling step before the RCA begins. An auditor will look for this distinction.

Step 5, Implement the corrective action plan

A corrective action plan is more than a list of to-dos. It should specify, per action:

• Action description, what will be done, concretely.
• Owner, single name, accountable.
• Supporting resources, who/what else is needed.
• Target date, with a rationale (a date without a rationale is a wish).
• Dependencies, what must happen first; what could block.
• Implementation evidence, what artefact will prove the action was taken (a new document version, a training record, a test report, a configuration change record).
• BCMS impact, which documented information, risks, BIA elements, or scope/policy/objectives change as a result.
• Cost, the budget required; this matters for management-review prioritisation.

Step 6, Run the effectiveness check (the most-skipped step)

The effectiveness check is the step that distinguishes a closed loop from a declared loop. The check is a post-implementation verification at a defined interval, typically:

• 30 days for minor NCs.
• 60 days for moderate NCs.
• 90 days for major NCs.
• Next exercise / next audit cycle for any NC where the only way to confirm effectiveness is to test under load.

The check answers three questions:

1. Did the root cause disappear? (Not "did the symptom go away", the root cause.)
2. Has the NC recurred in any form anywhere?
3. Did the corrective action cause any unintended side effects on other BCMS processes?

The check must produce a documented record, a short report by the verifier (typically the BCM Manager or an independent reviewer, not the action owner), and either confirms closure or reopens the NC. Reopening is a legitimate and important outcome; an effectiveness check that never reopens anything is a red flag (it means either you are closing too early or the check is perfunctory).

Step 7, Update risk, BIA, documentation, scope, policy, objectives

The "make changes to the BCMS if necessary" step is where corrective action compounds. Examples:

• An NC reveals an unidentified risk → Clause 6.1 risk register gets a new entry.
• An NC reveals that a BIA RTO is unachievable → Clause 8.2 BIA is updated; the Clause 8.3 strategy is reviewed.
• An NC reveals a plan template flaw used across 12 plans → Clause 7.5 documented information is updated centrally; all 12 plans are reissued.
• An NC reveals that an objective was wrong → Clause 6.2 BC objectives are revised.
• An NC reveals that a critical activity was outside scope → Clause 4.3 scope is reviewed.
• An NC reveals a policy gap → Clause 5.2 BC policy is updated.

The procedural rule: every corrective action must explicitly consider whether it triggers any of these updates. The NCR form should have a checklist for this.

Step 8, Trend analysis and feedback to Clause 9.3

The 10.1 process generates a strategic asset: the trend signal. Patterns to look for monthly/quarterly:

• Recurring NCs by clause, if Clause 8.5 (exercises) is the top NC source every quarter, the exercise programme has a systemic issue.
• Recurring NCs by department, if the same business unit keeps generating NCs, the issue is cultural or competence-related there.
• Recurring root causes, if "change management did not flag the BC impact" recurs across many NCs, the change-management process is the systemic root cause.
• Effectiveness-check failures, if more than ~10% of effectiveness checks result in reopens, the RCA quality is too low.
• NC aging, open NCs older than the target timeline by severity are escalations.

These trends are the highest-value input from Clause 10.1 to Clause 9.3 management review. They move the conversation from "we closed 23 NCs this year" (operational) to "our change-management process is the systemic cause of 41% of our NCs" (strategic).

Federation, how to structure 10.1 across the governance calendar

For growing companies (250–2,000 employees) and larger organisations, map the 10.1 cadence to the governance calendar:

• Weekly: NC coordinator reviews new NCRs, assigns owners, escalates aging items.
• Monthly: BCM Forum (operational) reviews open NCs, aging, blocking issues, recent closures.
• Quarterly: Extended BCM Forum reviews trends, effectiveness-check results, recurring themes, escalations to senior management.
• Half-yearly: Management review (Clause 9.3) receives the 10.1 dashboard and decides on systemic actions, scope changes, objective revisions.
• Annually: Board committee (Audit / Risk Management Committee under Companies Act §177 / SEBI LODR Reg. 21) receives the BCMS performance summary including the 10.1 trend signal.

This federation turns 10.1 from a register-filling exercise into a governance discipline.

Tools, Technologies, and Solutions

The tool stack by function

Category-level tool landscape (genericised)

The landscape, by category (vendor-neutral):

• Enterprise IRM suites (broad GRC + risk + audit + BCM), suite-priced, multi-year implementations, suited to 5,000+ employees. Typical modules include audit, risk, incident, BCM, policy, and CAPA. Strength: integration; weakness: implementation cost and rigidity.
• Growing GRC SaaS, subscription-priced, faster to deploy, suited to 250–5,000 employees. Typical modules cover audit, policy, incident, and CAPA. BCM-specific modules vary; some mid-tier tools are ISMS/quality-focused and treat BCM as a custom module.
• BCM-specialist SaaS, narrower focus, deeper BCM functionality (BIA tools, plan builders, exercise management, NC/CAPA). Suited to organisations running BCM as a primary discipline.
• DR-replication tech / backup suites, generate technical NCs (failed backups, missed RPO, replication lag) that flow into the BCMS register via integration or manual entry.
• Service-management / ITSM suites, ITIL-style incident and problem management (the IT equivalent of NC/CAPA); a frequent source of BCMS NCs and a candidate for integration with the BCM register.
• Audit-management tools, used by internal audit (Clause 9.2) to manage findings; the BCMS NC register should consume audit findings as input.
• Safety / EHS tools, used in manufacturing / pharma / healthcare for EHS incidents (a Clause 8.4/10.1 source).

Tool selection criteria (category-level)

The collaboration layer

For most growing companies, the most important "tool" is the collaboration discipline: a single BCM workspace (in SharePoint, Google Workspace, or Confluence) holding:

• The NC register (or its mirror).
• The RCA worksheets.
• The CAPA plans.
• The effectiveness-check reports.
• The trend dashboards for management review.
• The procedural documents.

This workspace becomes the audit's primary evidence location. A certifier will ask for access; the easier it is to navigate, the smoother the audit.

Policy and Procedure Templates

This section gives structural skeletons; the full ready-to-customise templates are in the toolkit. Sample policy and contract "shall" clauses are our own drafting (only the standard's own clause text is off-limits).

Nonconformity and Corrective Action Policy (structural skeleton)

[ORGANISATION NAME]
Business Continuity Management System — Nonconformity and Corrective Action Policy
Policy ID: BCMS-POL-010       Version: 1.0       Effective: [DATE]       Owner: BCM Manager

1. Purpose
This policy establishes how [Organisation] identifies, records, investigates, corrects, and learns
from nonconformities in its BCMS, in accordance with ISO 22301:2019 Clause 10.1.

2. Scope
Applies to all BCMS nonconformities from any source — internal audit, external/supervisory audit,
management review, exercises, real disruptions, monitoring, regulator inspections, customer
complaints, supplier issues, and employee reports — across all in-scope locations, functions,
and outsourced BCMS processes.

3. Definitions
[Adopt the definitions in Section 5 of the guide, paraphrased.]

4. Principles
4.1 Every detected nonconformity shall be logged in the NC register within [2] working days.
4.2 Containment, correction, and consequence-handling shall be carried out before corrective action.
4.3 Root-cause analysis shall be performed using a defined method (5-Why / Ishikawa / FTA / IS-IS NOT /
    bow-tie / FMEA / timeline) appropriate to the NC.
4.4 The need for corrective action shall be evaluated and the decision (action / no action / defer)
    recorded with rationale.
4.5 Corrective action shall be implemented with named owners and target dates.
4.6 The effectiveness of corrective action shall be reviewed at [30/60/90] days post-implementation.
4.7 Closed loops shall update the BCMS — risk register (Clause 6.1), documented information (7.5),
    BIA (8.2), strategy (8.3), plans (8.4), exercise programme (8.5), and scope/policy/objectives
    where required.
4.8 Recurrence shall be treated as a major nonconformity against this clause.
4.9 Trends and recurring themes shall be reported to management review (Clause 9.3) and to the
    [Board Risk Management Committee / Audit Committee].

5. Roles
5.1 BCM Manager — owns this policy and the NC register.
5.2 NC Coordinator — daily/weekly register administration.
5.3 NC Owners — topic-specific (CISO, IT Head, BCP Lead, Department Heads).
5.4 RCA Facilitators — trained internal facilitators (minimum [2]).
5.5 Internal Audit — independent NC source; does not own corrective actions it recommends.
5.6 BCM Forum — monthly review of open NCs.
5.7 Top Management — quarterly review via management review (Clause 9.3).
5.8 [Board Risk Management Committee] — half-yearly review of trend signal.

6. Document Control
[List the related procedures, forms, and records; version-control rule; retention rule.]

7. Review
This policy shall be reviewed at least annually and after any major NC or significant BCMS change.

[Approved by: Top Management, Date]

NCR/CAPA Procedure (structural skeleton)

A 4–8 page procedure expanding Section 7's eight steps into specific, repeatable operating instructions, with the NC register fields, RCA worksheet templates, CAPA plan template, and effectiveness-check template attached as forms. (Full skeleton in Toolkit Doc 02.)

Sample vendor / contract "shall" clauses (our drafting)

These are our own drafting for inclusion in supplier / outsourcing contracts, not standard text:

• "The Supplier shall maintain a nonconformity and corrective-action process aligned to ISO 22301:2019 Clause 10.1 and shall, upon request, provide the Customer with summary reports of nonconformities affecting the Customer's continuity arrangements."
• "The Supplier shall notify the Customer of any continuity-impacting nonconformity within [24 hours] of detection and shall provide a corrective-action plan within [10 working days]."
• "The Supplier shall permit the Customer (or its appointed auditor) to review the Supplier's NC register entries affecting the Customer's services, not less than [annually]."
• "Where a nonconformity recurs, the Supplier shall treat the recurrence as a material breach and shall, at the Customer's option, provide a senior-management-led corrective action plan within [5 working days]."
• "The Supplier shall cascade equivalent Clause 10.1 obligations to its sub-suppliers handling the Customer's prioritised activities."

Document control

Every artefact in the 10.1 process, policy, procedure, NC register, RCA worksheets, CAPA plans, effectiveness-check reports, management-review packs, is itself BCMS documented information and must follow the document-control rules of Clause 7.5.1 (version, approval, date, unique ID) and 7.5.3 (control of documented information: distribution, access, retrieval, storage, preservation, change control, retention, disposition).

Risk Assessment and Treatment

What can go wrong with the 10.1 process itself

The 10.1 process is itself a process; treating it with the Clause 6.1 risk lens:

How 10.1 treats BCMS risks identified elsewhere

A BCMS risk identified in Clause 6.1 that materialises (an incident occurs) is, by definition, the source of a candidate NC. The 6.1 → 8.4 → 10.1 flow is:

• 6.1: Risk identified, treatment plan defined, residual risk accepted.
• 8.4 (if disruption occurs): Plan activated; disruption managed; after-action report.
• 10.1: After-action findings become NCs; closed loop feeds back into 6.1 (risk register updated with new information; risk rating adjusted; treatment plan revised).

The "review theatre" risk

A specific failure mode worth naming: the BCMS produces beautiful management-review packs with dashboards, trends, and closure rates, but the underlying NCs are shallow, the RCA is perfunctory, and the effectiveness checks always pass. This is review theatre, the appearance of a closed loop without the substance. It is the hardest failure mode to detect because it looks like success. Internal audit (Clause 9.2) is the primary defence: audit should sample closed NCs independently and verify the closure was substantive.

Audit and Compliance Checklist

The following 28 questions cover the typical surveillance and recertification audit probes for Clause 10.1. Each lists the expected evidence and the red flag.

Establishment and procedure

1. Is there a documented NCR/CAPA procedure? Expected evidence: a controlled procedure document (Clause 7.5.1). Red flag: no separate procedure; NCs handled ad hoc.
2. Does the procedure specify the NC sources it covers? Evidence: source list matches Section 6.1. Red flag: only "audit" listed.
3. Does the procedure define NC classification (major/minor/observation) and severity? Evidence: classification rules. Red flag: no classification; all NCs treated the same.
4. Are roles and authorities defined (RACI)? Evidence: RACI matrix. Red flag: same person owns audit, RCA, action, and effectiveness check.
5. Is the procedure approved by top management and communicated? Evidence: approval signature; communication record. Red flag: procedure exists but unknown to NC owners.

NC register and logging

6. Is there a single NC register covering all sources? Evidence: the register itself. Red flag: multiple registers per source; gaps in source coverage.
7. Does each NCR have a unique ID and is it never reused? Evidence: register IDs. Red flag: reused IDs after closure.
8. Are required fields populated (source, date, clause ref, description, classification, owner)? Evidence: sample NCRs. Red flag: sparse records, missing fields.
9. Are NCRs logged within the target window of detection? Evidence: logging dates vs. detection dates. Red flag: long lag between detection and logging.
10. Are external-source NCRs (regulator, customer, supplier, employee) included? Evidence: register entries. Red flag: only audit and exercise NCs present.

Containment, correction, consequence-handling

11. Does each NCR record containment/correction/consequence-handling? Evidence: containment fields populated. Red flag: jump straight to "corrective action" without containment.
12. Is the timing of containment appropriate to severity? Evidence: timestamps. Red flag: serious NCs contained slowly, minor NCs over-contained.

Root-cause analysis

13. Is RCA done using a defined method? Evidence: RCA worksheets with method named. Red flag: "root cause" listed without method.
14. Is the method appropriate to the NC? Evidence: method-to-NC mapping. Red flag: 5-Why used for a complex multi-cause NC where FTA was needed.
15. Is the RCA quality adequate (depth, evidence, logic)? Evidence: review of worksheets. Red flag: 5-Why stops at layer 2; "human error" as terminal cause.
16. Is the "evaluate the need" decision documented with rationale? Evidence: decision field. Red flag: every NC has corrective action; none considered "no action needed."

Corrective action implementation

17. Does each corrective action plan have a named owner and target date? Evidence: plan fields. Red flag: owner = "BCM team"; no target date.
18. Is implementation evidence attached? Evidence: linked documents, change records, training records. Red flag: action declared done without artefact.
19. Are dependencies and blockers tracked? Evidence: dependency fields. Red flag: no escalation when blocked.

Effectiveness check

20. Is an effectiveness check scheduled at a defined interval? Evidence: dated effectiveness-check entry. Red flag: closure without effectiveness check.
21. Is the effectiveness check substantive (root cause gone, no recurrence, no side effects)? Evidence: effectiveness-check report. Red flag: single-line "checked, OK."
22. Is the effectiveness check done by someone other than the action owner? Evidence: verifier field. Red flag: owner self-verifies.
23. Is reopen an accepted outcome? Evidence: reopens in the register. Red flag: zero reopens across years (closure bias).

BCMS updates and feedback

24. Does each closed NC trigger consideration of risk-register, BIA, plan, scope, policy, objective updates? Evidence: checklist field. Red flag: NC closed without BCMS update considered.
25. Are trends and recurring themes reported to management review? Evidence: management-review pack. Red flag: only individual-NC status reported.
26. Are recurrence incidents escalated as major NCs? Evidence: escalation record. Red flag: recurrence treated as a new routine NC.

Independence, oversight, integration

27. Does internal audit independently verify a sample of closed NCs? Evidence: audit programme; audit findings on 10.1. Red flag: 10.1 never audited because "the team does it well."
28. Does top management review the 10.1 dashboard at planned intervals? Evidence: management-review minutes. Red flag: top management has never seen the trend signal.

Metrics and KPIs

The 10.1 process generates a rich KPI set. The following 14 KPIs cover process, outcome, and quality dimensions.

Process KPIs

Outcome KPIs

Quality and behaviour KPIs

Sample management-review dashboard

A typical 9.3 management-review 10.1 dashboard (one slide):

NC PROGRAMME — [QUARTER]
=========================
Open NCs at start:        18    New NCs this Q:    24    Closed this Q:    22    Open at end:    20
Closure rate:             78%   Avg aging (days):  47    >SLA:             4
Source mix:               Audit 38% | Exercise 22% | Incident 15% | Monitoring 12% | Other 13%
Effectiveness checks due: 21    Done: 20 (95%)    Reopened: 3 (15%)
Recurrences this Q:       1    [Escalated as major NC — see NCR-2026-047]
Top recurring themes:     (1) Change-Mgmt did not flag BC impact (5 NCs)
                          (2) Plan contact data stale (4 NCs)
                          (3) Backup test gap (3 NCs)
Open actions on Board RMC:2    [Action-2026-014, Action-2026-021]

Common Pitfalls / Audit Failures

The following anti-patterns recur across BCM audits. Each is named for memorability.

The "retrain and rewrite" loop

Pattern: Every NC has the action "retrained staff" and "updated procedure." Why it fails: No RCA was done; the root cause is rarely "people didn't know the procedure." Audit signal: RCA worksheets missing or shallow; uniformity of action across unrelated NCs. Fix: Mandate RCA with method named; ban "retrain" as a default action without RCA justification.

The "human error" dead-end

Pattern: RCA terminates at "human error" / "operator mistake" / "the vendor did not follow the procedure." Why it fails: Human error is a symptom, not a root cause; the next why is "why was it possible to make that mistake?" Audit signal: RCA worksheet stops at "human error." Fix: Ban "human error" as a terminal root cause; require the next-why.

The "effectiveness check that never reopens"

Pattern: Effectiveness checks have a 100% pass rate; nothing is ever reopened. Why it fails: Either closures are too conservative (you only close NCs you are sure about, leaving the risky ones open) or the check is perfunctory. Audit signal: Zero reopens across years. Fix: Set a healthy reopen-rate target (5–15%); audit closed NCs independently.

The "NC as audit-only" pattern

Pattern: The register only contains NCs from the certification audit and internal audit; exercise, incident, regulator, customer, and employee NCs are absent. Why it fails: Single-source NC programmes miss the bulk of the BCMS's actual nonconformities. Audit signal: Source distribution dominated by audit. Fix: Build the multi-source intake channels; train NC coordinators to log from each source.

The "audit owns the fix" independence breach

Pattern: Internal audit raised the NC; internal audit also leads the corrective action. Why it fails: Breaks ISO/IEC 17021-1 independence; future audits lose credibility. Audit signal: Same name in "raised by" and "action owner" fields. Fix: RACI discipline; audit recommends, does not implement.

The "single-RCA-method" trap

Pattern: 5-Why used for every NC, including complex multi-cause ones that needed FTA or bow-tie. Why it fails: Complex NCs get shallow analysis. Audit signal: RCA method field is "5-Why" for >90% of NCs. Fix: Train facilitators in multiple methods; method-to-NC mapping rules.

The "closed without BCMS update"

Pattern: NC closed but the risk register, BIA, plan, or policy is unchanged, no learning has been fed back. Why it fails: The closed loop is not actually closed; the systemic improvement does not happen. Audit signal: Major NCs with zero BCMS artefacts updated. Fix: Mandatory BCMS-update checklist on every NCR.

The "open forever" pattern

Pattern: Some NCs sit open for 18+ months with no escalation. Why it fails: The 10.1 process has no teeth. Audit signal: Aging distribution skewed; NCs >1 year old. Fix: Aging escalation thresholds; auto-escalate to top management.

The "review theatre"

Pattern: Beautiful dashboards, all-green, every quarter, but the underlying NCs are shallow. Why it fails: The process looks healthy but is not. Audit signal: High closure rate, low reopen rate, low recurrence rate, but internal audit has never audited 10.1. Fix: Independent internal-audit sampling of closed NCs.

The "recurrence tolerated"

Pattern: Same NC closes and re-opens and closes again; treated as routine. Why it fails: The systemic root cause was never addressed. Audit signal: NCs with similar descriptions across cycles. Fix: Recurrence = major NC against 10.1, escalated to top management and board committee.

The "five-whys stopping at three"

Pattern: 5-Why worksheets stop at why-3 or why-4 with a symptom. Why it fails: Root cause not reached; corrective action addresses symptom. Audit signal: Review worksheets. Fix: Train facilitators; peer-review RCA before action planning.

The "no psychological safety"

Pattern: NCs are treated punitively; staff stop reporting. Why it fails: Detection rate collapses; the BCMS loses its primary signal. Audit signal: NC detection rate falling year-on-year. Fix: Cultural reset; reward NC detection; separate performance management from NC reporting.

Illustrative Scenario 1: Failure, The Recurrence That Cost a Growing Bank Three Years

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative scenario. The following composite is drawn from the public record on Indian banking outages and supervisory actions (HDFC 2018–2022; SBI YONO recurring outages). It is illustrative; numbers and names are anonymised but the regulatory pattern is factual.

The organisation

A growing Indian private bank ("the Bank"), approximately 1,800 employees, ₹18,000 cr in deposits, growing digital-banking share. The Bank held an ISO 22301 certification for its core banking and digital channels. The BCM Manager, reporting to the CIO, ran a small BCM team of three.

The first nonconformity (Year 1)

At the Year-1 surveillance audit, the certifier raised a minor NC against Clause 8.5: the annual DR failover test for the digital channels had missed its RTO of 2 hours by 40 minutes, actual recovery took 2 hours 40 minutes. The containment/correction was a documented commitment to retest within 90 days. The corrective action plan listed: (a) retrain the DR team on the recovery runbook; (b) update the runbook; (c) retest at the next quarterly DR test.

The 90-day retest passed narrowly (RTO of 2 hours 5 minutes). The effectiveness check confirmed closure. The certifier closed the NC at the next surveillance.

The recurrence (Year 2)

In Year 2, the digital channels went down for 4 hours during a peak transaction window. The after-action review (Clause 8.4 / 8.6) found that the recovery script had failed at the same step as the prior year, the DNS hostname for a critical middleware service had been changed and the script not updated. The RCA revealed that:

• The Year-1 corrective action had updated the runbook but had not changed the change-management process.
• The change that broke the script in Year 2 had been through change management but was not classified as DR-impacting.
• The Year-1 effectiveness check (the 90-day retest) had not exercised a DNS-change scenario, so it could not detect the underlying gap.

The Year-2 incident produced a major NC against Clause 10.1 (recurrence) and Clause 8.5 (DR-test design). The corrective action this time was more substantive: a "DR-impact" attribute added to every change record, auto-routing DR-impacting changes to the DR team; a redesigned DR test that includes DNS-change scenarios; and a Capex plan to migrate the digital channels to an active-active dual-data-centre architecture.

The supervisory action (Year 3)

In Year 3, a third outage, this time during a peak festival-season window, affected digital banking for 6 hours, with widespread customer impact. The banking regulator initiated supervisory action modelled on the RBI's 2 December 2020 action against HDFC: restrictions on the Bank's ability to launch new digital products and to issue fresh credit cards, and asked its board to examine the lapses and fix accountability. The supervisory letter explicitly cited the recurring nature of the digital-channel recovery failures as evidence that the Bank's Clause 10.1 process was ineffective.

Root cause of the 10.1 failure

The post-supervisory review found that the Bank's 10.1 process was structurally sound on paper, a procedure, a register, an RCA toolkit, an effectiveness check. The failures were:

1. The Year-1 RCA was shallow. It reached "the runbook was wrong" and "the DR team needs retraining" but not "the change-management process does not flag DR-impact." The 5-Why analysis stopped at why-3.
2. The effectiveness check was a single-point retest, not a strong verification. It tested the symptom (RTO) in a narrow scenario, not the systemic gap (change-management classification).
3. Recurrence was tolerated. The Year-2 recurrence was processed as a routine new NC rather than escalated as a major Clause 10.1 NC.
4. The trend signal was missed. Across both years, multiple minor NCs traced to the same change-management gap, but the trend was not detected or reported to the management review.
5. Top management was disengaged. The 10.1 dashboard went to the CIO, not to the board's Risk Management Committee.

Impact

• Direct cost: customer SLA credits, refund processing, comms recovery, and the external IT audit mandated by the regulator, across the three years.
• Supervisory action cost: the digital-product restriction held for ~9 months, deferring digital-revenue growth.
• Certification impact: The certifier issued a major NC at Year-3 surveillance; the certification was maintained with conditions, but a further recurrence would have triggered suspension.
• Reputational impact: Media coverage of the supervisory action led to measurable deposit-base stagnation for two quarters.
• Governance cost: The CIO left; the BCM Manager was reassigned; a Chief Operational Resilience Officer was hired reporting to the CEO; the Board RMC now reviews the 10.1 trend signal half-yearly.

Lessons (Clause 10.1 specific)

• Shallow RCA is the single biggest 10.1 failure mode. A 5-Why that stops at why-3 will not find systemic causes.
• Effectiveness checks must test the systemic gap, not the symptom. A single-point retest of RTO is not an effectiveness check of a change-management process.
• Recurrence must be escalated. A recurrence is the definitive evidence that prior corrective action failed; treating it as routine is the most damaging 10.1 anti-pattern.
• Trends matter more than individual NCs. The trend signal, multiple NCs from the same change-management gap, was the strategic intelligence that the Bank missed.
• Top-management engagement is non-negotiable. A 10.1 process delegated to the CIO without board-committee visibility has no teeth.

Illustrative Scenario 2: Success, How a Growing SaaS Firm Closed the Loop

Illustrative scenario. Composite drawn from public SaaS / IT-services incident patterns (Cognizant Maze 2020 SEC disclosure; Infosys McCamish 2023; Wipro 2019 phishing pivot) and standard corrective-action ROI patterns. Illustrative; anonymised.

The organisation

A growing Indian B2B SaaS company ("the Company"), ~650 employees, ₹220 cr ARR, serving Indian BFSI and global enterprise customers. The Company held ISO 22301 and ISO 27001 certifications; the BCM Manager also held the ISMS lead role. The Company ran a single integrated NC/CAPA register across both management systems.

The trigger (Year 1, Q2)

A real disruption: the Company's primary cloud-provider region suffered a 5-hour outage. The Company's BCP was activated; the failover to the secondary region took 2 hours 45 minutes against a documented RTO of 1 hour. Several customer SLAs were breached; one enterprise customer invoked a contractual right to a security and continuity audit.

The containment / correction / consequence-handling

Within the first hour of detection: customer-comms team notified all affected customers per the BCP; the failover was attempted and partially completed; the engineering team worked the secondary-region synchronisation issues in parallel. Within 24 hours: SLA-credit calculations done; affected customers individually contacted by account managers; the contractual audit right was scoped with the enterprise customer. Within 7 days: a formal after-action review (Clause 8.6) was completed.

The RCA

The BCM Manager commissioned a fault-tree analysis (not 5-Why, the team explicitly chose FTA because the failure was multi-causal). The FTA identified four contributing failures:

1. The failover runbook had a step that depended on a database-cache warm-up that took 45 minutes longer in the secondary region due to a smaller instance size.
2. The failover had been tested 8 months earlier but only with a "fresh start" scenario, not a "mid-transaction with hot cache" scenario.
3. The cloud-provider's own health-check tooling had reported the primary region as "degraded but recovering" for 23 minutes before declaring it unavailable, delaying the failover trigger.
4. The customer-communication tree had stale on-call numbers for two account managers; alerts were not delivered for 18 minutes.

The verified root causes were:

• (R1) DR-test design did not include "mid-transaction with hot cache" scenarios.
• (R2) Secondary-region instance sizing was below the primary region (cost-driven decision) without a documented RTO impact analysis.
• (R3) Failover-trigger decision criteria depended on the cloud provider's declared status rather than the Company's own SLO monitoring.
• (R4) The customer-communication tree did not have an automated on-call-number refresh from HR systems.

The corrective action plan

A single corrective action plan, four parallel tracks, with named owners and target dates:

The effectiveness check

At 30 days, 60 days, and 90 days post-implementation, the BCM Manager ran effectiveness checks:

• 30 days: CA-4 verified by testing the on-call refresh; CA-1 in design (on track).
• 60 days: CA-1 verified by running the first redesigned DR test, recovery achieved in 58 minutes (well within the 1-hour RTO); CA-3 verified by simulating a cloud-provider-tooling failure.
• 90 days: CA-2 verified by a full failover test on the right-sized secondary region, recovery in 47 minutes; CA-3 verified end-to-end.

No recurrence in any form across the year following. Effectiveness checks closed all four CAs.

The BCMS updates (the closed loop)

Each CA triggered explicit BCMS updates:

• The BIA (Clause 8.2) was updated to record the now-achievable RTO of 50 minutes and to note the dependency on secondary-region sizing.
• The risk register (Clause 6.1) was updated to record the now-mitigated risk of "cloud-provider-tooling-delayed failover" and the residual risk accepted.
• The DR plan set (Clause 8.4 / 7.5) was reissued with the new trigger criteria and the redesigned test portfolio.
• The exercise programme (Clause 8.5) was updated to include the new scenarios on a quarterly rotation.
• The supplier-management process (Clause 8.1) was updated to require the cloud provider's tooling-status notifications as a contractual SLA item.
• The customer-contract template was updated to clarify the customer's audit rights and the Company's notification timelines (avoiding the contractual-audit friction).

The trend signal

The BCM Manager noticed that across the prior 18 months, three other NCs (all minor) had touched aspects of the DR-test design and the cloud-provider dependency. The trend was reported to the half-yearly management review (Clause 9.3) as: "DR-test design and cloud-provider dependency are systemic 10.1 themes; recommend a strategic workstream to review multi-cloud strategy and test-portfolio breadth." Top management approved a strategic workstream, a Clause 10.2 continual-improvement project, but directly traceable to 10.1 trend analysis.

The outcome

The four corrective actions closed the loop on the recurrence, and the Company also won a renewal with the enterprise customer that had invoked the audit right, and used the closed-loop documentation as a sales asset in two subsequent BFSI RFPs, a tangible commercial return on the 10.1 investment.

Lessons (Clause 10.1 specific)

• Choose the RCA method to fit the NC. FTA, not 5-Why, was right for a multi-cause technical failure.
• Effectiveness checks must test under realistic load. The Company's 90-day effectiveness check ran a full failover test, not a paper review.
• The closed loop updates the BCMS. Each CA had explicit BCMS updates, BIA, risk register, plans, exercise programme, supplier process, customer contract.
• The trend signal drives continual improvement. 10.1 trend analysis feeds 10.2 strategic workstreams.
• 10.1 has commercial ROI. Closed-loop evidence is a sales asset in B2B SaaS.

Multi-Framework Mapping

The following table maps ISO 22301:2019 Clause 10.1 to the directly analogous requirements in other frameworks. Cells with clause/article/paragraph numbers are direct cross-references; named items are methodological analogues.

How to use this mapping

• For an Indian BFSI: the same NCR/CAPA register satisfies ISO 22301 10.1, ISO 27001 10.1, RBI MD assurance, SEBI CSCRF Evolve goal, and (for listed parents) the LODR RMC's oversight duty. Build one register, mapped to all.
• For an Indian MII: add SEBI BCP/DR post-incident reporting as a regulator-facing output of the same register.
• For an insurer: add IRDAI annual compliance reporting as a regulator-facing output.
• For a SaaS firm serving EU financial customers: the same register, mapped to DORA Art 13 (learning), satisfies both ISO 22301 10.1 and DORA's post-incident-review obligation.
• For a multi-certification organisation (ISO 22301 + 27001 + 9001): one integrated NCR/CAPA procedure, with clause-tagging per NC, is the cleanest design.

Implementation Roadmap

A defensible Clause 10.1 programme is built in four phases over ~12 months. The roadmap is tiered for a larger (250–2,000 employee) growing company.

Phase 1, Foundation (Days 0–30)

• Days 0–7: Secure top-management sponsorship (CEO/COO + Board RMC chair); name the BCM Manager as 10.1 owner; name the NC Coordinator.
• Days 7–14: Draft the NCR/CAPA Policy (Toolkit Doc 01) and Procedure (Toolkit Doc 02); top-management approval.
• Days 14–21: Stand up the NC register (spreadsheet for now; tool selection deferred to Phase 3); retro-load all NCs from the past 12 months (audit findings, exercise gaps, incidents, regulator communications).
• Days 21–30: Train NC owners and coordinators on the procedure; communicate the policy; publish the register.

Phase 1 exit criteria: A documented policy and procedure; a populated register; a named owner per open NC; top-management approval on record.

Phase 2, Operationalisation (Days 30–90)

• Days 30–45: Train 2–4 internal RCA facilitators (5-Why + Ishikawa + FTA + timeline).
• Days 45–60: Run the first BCM Forum review of open NCs; close the first tranche using the new procedure.
• Days 60–75: Define the effectiveness-check cadence and run the first effectiveness checks on Phase-1 closures.
• Days 75–90: Build the first trend dashboard; integrate the 10.1 dashboard into the management-review input pack (Clause 9.3).

Phase 2 exit criteria: Trained facilitators; first end-to-end NCRs closed with documented effectiveness checks; trend dashboard live; management review has 10.1 visibility.

Phase 3, Maturation (Days 90–180)

• Days 90–120: Select and deploy the tooling (if the spreadsheet is buckling), typically a mid-tier (250–2,000) GRC SaaS or an integrated BCM-specialist SaaS; migrate the register.
• Days 120–150: Integrate with internal audit (Clause 9.2), audit findings auto-flow to the register; integrate with risk register (Clause 6.1), closed NCs feed risk updates; integrate with incident response (Clause 8.4), incident after-action findings auto-flow.
• Days 150–180: Run the first half-yearly board-committee reporting cycle with the trend signal; verify psychological safety (anonymous reporting channel; non-punitive NC culture).

Phase 3 exit criteria: Integrated tooling; multi-source NC intake; trend signal flowing to top management and board committee; healthy reopen rate and detection rate.

Phase 4, Strategic (Days 180–365)

• Days 180–240: Move from operational reporting to strategic insight, use trend analysis to identify systemic root causes; initiate Clause 10.2 continual-improvement projects to address them.
• Days 240–300: Run an independent internal-audit cycle on the 10.1 process (Clause 9.2 applied to 10.1 itself); remediate findings.
• Days 300–365: Year-1 self-assessment against the maturity model (Section 22); set Year-2 targets.

Phase 4 exit criteria: Strategic use of trend data; independent audit of 10.1 completed; maturity self-assessment on record.

Federation by governance forum

FAQ

Q1. We are a small company. Do we need a full 10.1 programme? Clause 10.1 applies identically regardless of size. What changes is the machinery: a small organisation can run 10.1 on a single spreadsheet with one BCM Forum member doubling as NC coordinator. The discipline (logging, RCA, effectiveness check) matters more than the tool.

Q2. Our internal audit raised 12 NCs in the last audit. Do we have to close all of them before the surveillance? It depends on classification. Major NCs typically must be closed (or have a credible corrective-action plan in implementation) before the surveillance. Minor NCs typically need a corrective-action plan with target dates, with closure verified at the next surveillance. The certifier's specific rules govern.

Q3. Our certifier raised a major NC against Clause 10.1 itself. What does that mean? A major NC against 10.1 means the certifier found the corrective-action process itself is failing, typically: recurrence of previously closed NCs; effectiveness checks not done; or the trend signal is unchanged across cycles. This is serious: it can lead to conditions on certification or suspension. Treat it as a top-management priority.

Q4. We had the same NC in two consecutive audits. Is that an automatic major NC? Recurrence is the definitive evidence that prior corrective action was ineffective. The certifier will almost certainly treat it as a major NC against Clause 10.1 (often alongside the original-clause NC). The fix is a deeper RCA on why the prior corrective action failed, not another quick fix.

Q5. Can we use our ISO 27001 NCR/CAPA procedure for ISO 22301 as well? Yes. The Harmonised Structure means the procedure can be shared. Add a "management-system" tag to each NC (ISMS / BCMS / QMS) and a clause-reference per tag.

Q6. Our BCM Manager is also the internal auditor. Is that a problem? Yes, it breaks the independence required by ISO/IEC 17021-1. Internal audit (Clause 9.2) must be independent of the functions it audits; the BCM Manager owns the BCMS and therefore cannot independently audit it. Either outsource the internal audit, rotate the role, or use a different internal auditor for the BCMS.

Q7. How do we handle a corrective action that turns out to be wrong? Reopen the NC. The effectiveness check exists exactly for this purpose. Reopen, re-analyse, and re-plan. A healthy 10.1 process has a non-zero reopen rate; a zero reopen rate is a red flag.

Q8. Our CEO wants us to close all NCs in 30 days. Is that realistic? For minor NCs, 30–45 days is a reasonable target. For major NCs (which often require infrastructure, training, or process change), 60–90 days is more realistic, with effectiveness checks at 30/60/90 days post-implementation. Setting unrealistic targets creates closure bias and undermines the loop.

Q9. What is the difference between correction and corrective action? Correction is the immediate fix of the symptom (restore the failed system, repair the missing record). Corrective action is the root-cause fix (change the process so the failure does not recur). Both are required; correction alone is not corrective action.

Q10. Do we have to do RCA for every minor NC? Yes, but the depth of the RCA should match the NC. A minor NC may need only a 5-Why that takes 30 minutes; a major NC may need a multi-day FTA. The method matches the NC, but the analysis is always required.

Q11. Our regulator (RBI / SEBI / IRDAI) raised findings in the last inspection. Do they go into the 10.1 register? Yes. Regulator findings are NC inputs and must be in the register. In fact, supervisory findings typically get the highest priority and visibility, and the closure tracking is itself reportable back to the regulator.

Q12. How do we handle an NC against a supplier? Log it in your register. Your contract with the supplier should require the supplier to maintain a 10.1-equivalent process and to report NCs affecting your continuity arrangements (see the sample vendor clauses in Section 9.3). Track the supplier's corrective action to closure; if it does not close, escalate per the contract (ultimately to exit/replacement).

Q13. Our last DR test missed RTO by 10%. Is that an NC? Yes. A missed RTO in a test is a Clause 8.5/8.4 NC and should be logged. The RCA should examine whether the RTO is wrong (set too aggressively in the BIA), the strategy is wrong (the recovery solution cannot meet it), or the execution is wrong (the runbook or the team).

Q14. We have an NC register, but no effectiveness checks. Can we still pass a surveillance audit? Possibly, but it is a significant risk. Effectiveness checks are the single most-skipped step and the most common reason for a 10.1 finding at surveillance. Implement them before the surveillance.

Q15. How is Clause 10.1 different from Clause 10.2? 10.1 is reactive (triggered by a detected NC); 10.2 is proactive (improving what already conforms). The same output (a plan change, a control improvement) can come from either, but the trigger differs. Auditors test the demarcation by asking "what triggered this action, a detected NC, or a proactive improvement decision?"

Q16. We are pursuing ISO 22301 certification. How many NCRs does the certifier expect to see? There is no fixed number. A healthy BCMS detects and logs many NCs (a low NC count is often a detection-failure red flag, not a healthy-BMSN signal). What the certifier tests is the loop, not the count: trace 2–5 sample NCRs end-to-end, verify effectiveness checks, verify trend analysis.

Q17. How long should we retain NCR records? At minimum, the full certification cycle (3 years) so the next surveillance can verify closure. Many Indian regulators require longer retention, RBI's Master Direction expectation aligns with general record retention (often 8–10 years for financial records); DPDP requires retention only as long as necessary for the purpose. Align with the strictest applicable rule.

Industry-Specific Requirements

BFSI (Banks, NBFCs, Payment System Operators)

Distinctive 10.1 angles:

• RBI supervisory findings are NC inputs of the highest priority; closure is tracked and reported back to the regulator.
• The Cyber Security Framework (2 June 2016) and the 2023 IT Governance Master Direction make the board accountable for closure; recurrence triggers supervisory action (the HDFC 2020 precedent).
• The CERT-In 6-hour incident-reporting clock creates a high-frequency NC source.
• For PSOs, the Cyber Resilience and Digital Payment Security Controls Master Direction adds payment-specific NC streams (PPI failures, BBPS/AEPS incidents).
• The SEBI CSCRF "Evolve" goal applies to SEBI-regulated entities within the BFSI group (brokers, AMCs).

Specific evidence the regulator/examiner expects:

• NCR register with regulator-grade entries; closure timeline tracked.
• Board RMC minutes showing review of the 10.1 trend signal (SEBI LODR Reg 21).
• External-audit closure reports (when supervisory action mandates an external audit).
• Incident after-action reports with corrective-action tracking.
• Annual compliance return showing status of prior-year findings.

Healthcare (Hospitals, Health-Tech, Pharma)

Distinctive 10.1 angles:

• Clinical-incident investigations (NMC, state medical councils) are NC inputs.
• Patient-safety dimension of effectiveness checks (the corrective action must be verified not to introduce new patient-safety risks).
• Ransomware-specific NCs (AIIMS 2022 precedent); backup and segmentation findings are common.
• For pharma manufacturing, EHS / OSHA-equivalent investigations (OSH Code 2020, which replaced the Factories Act 1948; NDMA Chemical Disaster Guidelines 2007); production-stoppage as a containment action (Sun Pharma 2023).
• DPDP personal-data breach angle (healthcare data is sensitive; breach notification is statutory).

Specific evidence the regulator/examiner expects:

• Clinical-incident after-action reports linked to NCR register entries.
• Segmentation and backup NCs closed with technical evidence.
• Effectiveness checks verified under clinical-load conditions (not just paper review).

Manufacturing & Industrial (Automotive, Pharma, Chemicals, Energy)

Distinctive 10.1 angles:

• OT/IT segmentation findings are common and high-impact.
• Production-stoppage as a containment decision, the BCMS and the production system intersect at 10.1.
• Industrial-Major-Accident-Hazard (MAH) NCs feed NDMA/DISH/Factory Chief Inspector channels.
• For chemicals, NDMA Chemical Disaster Guidelines 2007 mandate integration of industrial plans with District DMPs; an NC at that interface is high-severity.
• LG Polymers (NGT ₹50 cr interim) is the regulatory reminder that un-closed industrial-safety NCs compound catastrophically.

Specific evidence the regulator/examiner expects:

• OT/IT segmentation NCs with technical evidence (network diagrams, segmentation test results).
• EHS NCs linked to Factory/Chief Inspector filings.
• Effectiveness checks run in conjunction with operations / production team (not in isolation).

IT / ITeS & SaaS

Distinctive 10.1 angles:

• Customer-driven NCs (security questionnaires, customer audits, SLA breach reports) are a major source, often the largest.
• Supply-chain NCs (vendor pivot incidents like Wipro 2019 / SITA 2021), the BCMS must consume vendor NCs.
• The NC register is itself a customer-facing asset; closed-loop evidence is a sales asset in B2B.
• For SaaS firms serving EU financial customers, DORA Art 13 (Learning and evolving) feeds the same register.

Specific evidence the regulator/examiner expects:

• Customer-audit findings in the register; closure evidence shared with the customer.
• Vendor NC tracking with right-of-audit clauses exercised.
• For DORA-in-scope customers, the Art 13 post-incident review linked to NCR entries.

Government / PSUs / CPSEs

Distinctive 10.1 angles:

• CAG/CVC findings are NC inputs.
• NDMA Disaster Management Plan templates embed the "Recovery & Reconstruction" phase; an NC against a Ministry/Department DMP is a statutory issue.
• Right to Information exposure on un-closed findings.
• For CPSEs in critical infrastructure (power, telecom, oil & gas), the NC pipeline intersects with national critical-infrastructure protection (NCIIPC under IT Act §70A).

Specific evidence the regulator/examiner expects:

• CAG/CVC findings tracked in the register.
• DMP reviews linked to NCR entries.
• RTI responses consistent with the register (no contradiction between the official response and the internal record).

Airlines & Transport

Distinctive 10.1 angles:

• DGCA surveillance findings are NC inputs (SpiceJet 2022 schedule cap; recurrence pattern).
• Refund-liability tracking (Go First ₹597 cr to ~15.5 lakh passengers) is a 10.1-grade issue for customer-affecting disruptions.
• Aviation-specific RCA culture, the blanket use of "human error" as a terminal root cause is a Clause 10.1 anti-pattern that audit and supervisory bodies increasingly challenge.

Specific evidence the regulator/examiner expects:

• DGCA surveillance findings tracked to closure in the register.
• Refund-liability tracking integrated with NCR closure.
• RCA quality (no "human error" terminal causes without deeper analysis).

Maturity Model

A five-level maturity model for Clause 10.1, described for a larger growing (250–2,000 employee) Indian company.

Level 1, Initial / Ad hoc

• Detection: Accidental. NCs identified when something goes visibly wrong.
• Logging: Informal; emails, meeting notes.
• RCA: Shallow or absent; "root cause: human error" accepted.
• Effectiveness check: None.
• Trends: Not analysed.
• Typical outcome: Recurring NCs; surprise findings at audits; supervisory-action exposure.
• What it takes to reach L2: a consultant, a basic procedure and a register.

Level 2, Reactive / Managed

• Detection: Multiple sources but inconsistent logging.
• Logging: A register exists; population is uneven.
• RCA: 5-Why used inconsistently; depth varies by owner.
• Effectiveness check: Sometimes; quality variable.
• Trends: Reported occasionally; not yet strategic.
• Typical outcome: Pass surveillance audits with minor NCs; some recurrence.
• What it takes to reach L3: a procedure upgrade, RCA facilitator training, effectiveness-check discipline and a first integrated dashboard.

Level 3, Defined (certification floor)

• Detection: All sources logged; psychological safety reasonable.
• Logging: Single register; common schema; consistent population.
• RCA: Multiple methods (5-Why + Ishikawa + FTA + timeline); facilitators trained.
• Effectiveness check: Mandatory at 30/60/90 days; reopen is accepted.
• Trends: Quarterly trend analysis to BCM Steering; half-yearly to management review.
• Typical outcome: Solid ISO 22301 certification; recurrence is exceptional.
• What it takes to reach L4: tooling, integration with audit, risk and incident processes, and a strategic-trend capability.

Level 4, Quantitatively Managed

• Detection: High detection rate; near-miss reporting is routine.
• Logging: Integrated GRC/IRM with audit, risk, incident, supplier modules.
• RCA: Method-to-NC mapping rules; FMEA on critical processes.
• Effectiveness check: Statistical analysis of reopen rates and recurrence; predictive KRIs.
• Trends: Strategic, drives Clause 10.2 continual-improvement portfolio; tied to board-level OKRs.
• Typical outcome: Recurrence rate <3%; closed-loop evidence is a competitive asset.
• What it takes to reach L5: predictive analytics, AI-assisted RCA pattern-matching and full operational-resilience integration.

Level 5, Optimising

• Detection: Continuous; near-miss and weak-signal detection automated.
• Logging: Real-time; integrated with operational telemetry.
• RCA: Cross-organisational learning; pattern recognition across thousands of NCs; AI-assisted.
• Effectiveness check: Continuous monitoring; predictive closure quality.
• Trends: Forward-looking, anticipated risks fed into Clause 6.1 before they materialise.
• Typical outcome: 10.1 is a strategic capability; BCMS outperforms peers; operational-resilience metrics industry-leading.
• What it takes to sustain L5: an analytics platform, capability maintenance and benchmarking.

How to use the maturity model

• Self-assess honestly each year against the level descriptors.
• The certification floor is L3. A typical Year-1 goal for a growing company pursuing ISO 22301 is to reach L3 in 10.1 specifically.
• Each level up delivers disproportionate value. The jump from L2 to L3 is the largest single risk-reduction step (recurrence collapses); L4–L5 are strategic differentiators, not compliance necessities.

Emerging Trends

AI-assisted RCA and pattern recognition

Mature GRC/IRM platforms now offer AI-assisted root-cause pattern recognition, scanning thousands of historical NCs to surface recurring cause patterns a human analyst would miss. The discipline required: AI surfaces patterns, but a human facilitator still runs the RCA. The risk: AI-derived "root causes" treated as authoritative without human verification (the same shallow-RCA anti-pattern in new clothing).

Regulator-facing real-time NC pipelines

Regulators (RBI, SEBI, IRDAI, CERT-In) are progressively moving toward real-time or near-real-time NC reporting pipelines, the CERT-In 6-hour clock, the SEBI CSCRF incident-reporting flows, the DORA Art 19 major-incident reporting. The implication for 10.1: the NC register must be capable of producing regulator-facing extracts on demand, not just at cycle-end. The Indian regulatory direction is toward regulator query access to regulated entities' NC registers.

Convergence of NC across management systems

Organisations running multiple management systems (ISO 22301, 27001, 9001, 14001, 45001, 50001) increasingly run a single integrated NCR/CAPA register with clause-tagging per NC. This convergence is now an industry norm, not a leading practice.

Operational resilience integration

For BFSI and critical infrastructure, 10.1 is being absorbed into broader operational-resilience programmes (DORA in EU; CPS 230 in Australia; FFIEC BCM in the US; MAS TRM in Singapore). The "impact tolerance" model, set a tolerance for disruption to a critical function, test against it, and treat any breach as an NC, is becoming the supervisory expectation. ISO 22301's 10.1 is the management-system backbone for this model.

Climate-change-driven NC streams

ISO 22301 Amendment 1:2024 (Climate action changes, Clauses 4.1/4.2) creates new places for NCs to arise: a climate issue identified under 4.1 but not addressed in the BIA, or climate scenarios missing from the exercise programme. The 10.1 process is the consumer of these NCs.

Psychological safety as a 10.1 control

The recognition that detection rate is a function of psychological safety (staff willingness to report NCs, near-misses, weak signals) is reshaping how mature organisations design their 10.1 programmes. Non-punitive reporting cultures, just-culture frameworks, and explicit incentives for NC detection are becoming mainstream.

Data-driven effectiveness checks

The traditional 30/60/90-day effectiveness check is being supplemented by continuous monitoring, telemetry from the affected process is monitored for recurrence patterns automatically, and the effectiveness check becomes a data-driven continuous process rather than a discrete paper review.

NC pipeline as a board-level KPI

Board committees (Risk Management Committee under SEBI LODR Reg 21; Audit Committee under Companies Act §177) increasingly request the 10.1 trend signal as a standing agenda item. The "NC pipeline health" is becoming a board-level KPI alongside financial and operational metrics.

References and Further Reading

The standard and its companions

• ISO 22301:2019 Security and resilience, Business continuity management systems, Requirements (ISO/TC 292), the standard; this guide paraphrases Clause 10.1.
• ISO 22301:2019/Amd 1:2024, Climate action changes to Clauses 4.1 and 4.2.
• ISO 22313:2020 Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301, companion guidance; §10 commentary on Clause 10.1.
• ISO 22300:2021 Security and resilience, Vocabulary (current third edition; verify whether a 2025 edition has published).
• ISO/IEC 17021-1:2015 Conformity assessment, Requirements for bodies providing audit and certification of management systems, governs how certifiers grade and report NCs.

Other ISO management-system standards with parallel 10.1 wording

• ISO/IEC 27001:2022 Clause 10.1 (identical Harmonised Structure).
• ISO 9001:2015 Clause 10.2 (identical Harmonised Structure).

Indian regulatory and statutory instruments

• Reserve Bank of India, Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024); Cyber Security Framework in Banks (2 June 2016); Master Direction on Outsourcing of IT Services (10 April 2023). Available at rbi.org.in.
• Securities and Exchange Board of India, Cybersecurity and Cyber Resilience Framework (CSCRF), circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 (20 August 2024); Guidelines for BCP/DR of MIIs, SEBI/HO/MRD1/DTCS/CIR/P/2021/33 (22 March 2021). Available at sebi.gov.in.
• IRDAI, Information and Cyber Security Guidelines, 2023 (24 April 2023). Available at irdai.gov.in.
• CERT-In, Directions under Section 70B(6) of the IT Act 2000, No. 20(3)/2022-CERT-In (28 April 2022). Available at cert-in.org.in.
• MeitY, Digital Personal Data Protection Act, 2023 (Act 22 of 2023); DPDP Rules 2025. Available at meity.gov.in.
• Ministry of Corporate Affairs, Companies Act, 2013 (§134(3)(n), §177). Available at mca.gov.in.
• NDMA, Disaster Management Act, 2005 (Act 53 of 2005); National Disaster Management Guidelines (chemical disasters 2007; DMP template). Available at ndma.gov.in.
• IT Act 2000 (as amended 2008), Sections 43, 65, 66, 70, 70A, 70B, 72, 84A. Available at indiacode.gov.in.

Global frameworks and regulations

• DORA, Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector; applies from 17 January 2025. Available at eur-lex.europa.eu.
• APRA CPS 230, Prudential Standard CPS 230 Operational Risk Management (effective 1 July 2025), especially para 30 (remediation), para 45 (internal audit), para 21 (board oversight). Available at apra.gov.au.
• NIST SP 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems (May 2010).
• NIST SP 800-160 Vol 2 Rev 1, Developing Cyber-Resilient Systems (September 2021).
• NIST Cybersecurity Framework 2.0 (NIST.CSWP.29, 26 February 2024), Recover function (RC.RP, RC.CO), with improvement now under Identify (ID.IM).
• FFIEC IT Examination Handbook, Business Continuity Management Booklet (November 2019; OCC Bulletin 2019-57; FRB SR 19-13; FDIC FIL-71-2019).
• FEMA FCD-1 / FCD-2 (17 January 2017 / 13 June 2017) under PPD-40.
• MAS TRM Guidelines (18 January 2021). Available at mas.gov.sg.
• HKMA TM-G-2 (revised) and OR-2 (31 May 2022). Available at hkma.gov.hk.

Practitioner bodies and certification bodies

• The Business Continuity Institute (BCI), global professional institute for BCM practitioners (certifies individuals: CBCI/AMBCI/MBCI/FBCI); the BCI Horizon Scan report series is the most-citable BCM industry dataset.
• DRI International, professional certification body for BCM practitioners (certifies individuals: ABCP/CBCP/MBCP/FBCP); DRII DRI professional-practice framework (living framework, available at drii.org).
• ISO management-system certification bodies operating in India (certify organisations, not individuals): BSI Group, DNV, SGS, TÜV, Bureau Veritas, Intertek, NQA. (Note: "BSI" in the German federal cybersecurity context refers to bsi.bund.de, a different organisation from BSI Group the certification body, these are distinct.)

Incident and case-study anchors (factual events referenced in this guide)

• AIIMS Delhi ransomware (23 November 2022) reporting by The Hindu; a reported ₹200 crore ransom demand that Delhi Police denied.
• HDFC Bank RBI action (2 December 2020), RBI order barring new digital products and fresh credit cards; credit-card ban partially lifted ~August 2021; full digital-initiatives ban lifted ~March 2022.
• Cognizant Maze ransomware (18–20 April 2020), SEC-filed 10-Q/10-K disclosure of Q2 2020 impact of US$50–70 million.
• Infosys McCamish Systems Lockbit (~29 October 2023), 6 million individuals affected; ~US$17.5 million class-action settlement reported.
• Sun Pharmaceutical ransomware (2023), public confirmation and revenue-impact warning.
• SpiceJet DGCA enhanced surveillance (27 July 2022), order to operate 50% of approved Summer Schedule for 8 weeks; extended; enhanced surveillance again in 2024.
• Go First NCLT insolvency (filed 2 May 2023), refund liability of ₹597 crore to ~15.5 lakh passengers.
• LG Polymers Visakhapatnam styrene gas leak (7 May 2020), NGT interim penalty of ₹50 crore (OA 73/2020).
• Jio 17 September 2024 nationwide outage, DC fire; reporting by Reuters and Data Centre Dynamics.
• Mumbai grid blackout (12 October 2020), Maharashtra state and Union Power Ministry positions on cyber link directly contradict; present both, do not assert.
• Wipro phishing breach (reported April 2019), reporting by KrebsOnSecurity.
• Air India / SITA data breach (February 2021, disclosed May 2021), ~4.5 million customers affected; reporting by Reuters and BBC.

End of guide. This guide is published by Singahi for the growing-company audience pursuing ISO 22301:2019 implementation in India. It is general guidance, not legal or certification advice; engage a qualified consultant for organisation-specific implementation.