ISO 22301 Clause 10.2: Continual Improvement

Quick Reference (60 Seconds)

The one-line summary: Clause 10.2 is the engine that stops a BCMS from calcifying, it is the proactive, ongoing discipline of finding ways to make the system better than it already is (more suitable to the changing organisation, more adequate to the changing risk picture, more effective at the continuity outcomes that matter), using every exercise, real disruption, audit, benchmark, and technology shift as raw material, and folding each improvement back into the management system so next year's BCMS is visibly stronger than this year's.

What the Standard Actually Requires

Figure · Process

What Clause 10.2 asks you to do

What the clause requires in substance

ISO 22301 Clause 10.2 asks organizations to continually improve the suitability, adequacy, and effectiveness of the BCMS. The clause sits inside Clause 10 (Improvement) alongside Clause 10.1 (Nonconformity and Corrective Action). The two are a deliberate pair: 10.1 is reactive, it triggers when something has already gone wrong (a nonconformity is detected); 10.2 is proactive and opportunistic, it triggers whenever the organisation sees a chance to raise the bar, regardless of whether anything has gone wrong.

The three adjectives in the requirement are not synonyms. They are the three dimensions along which a certifier will measure whether the BCMS actually improved:

• Suitability, does the BCMS still fit the organisation? As the organisation changes (new products, new geographies, new customers, new regulatory exposure, new ownership, new technology stack, new climate-exposed sites), the BCMS must keep being shaped to that reality. A BCMS designed for a single-product Bengaluru SaaS and unchanged for three years is not suitable for the same company once it has added a regulated BFSI product, a European customer base, and a Hyderabad delivery centre.
• Adequacy, is the BCMS sufficient for the risk picture? As the threat landscape changes (ransomware professionalisation, generative-AI-enabled social engineering, climate-driven floods in new geographies, supply-chain concentration, geopolitical fragmentation), the BCMS must keep being resourced and engineered to that risk. A BCM programme staffed at 2020 levels for a 2026 threat surface is not adequate.
• Effectiveness, is the BCMS achieving its outcomes? The BCMS exists so that prioritised activities continue to be delivered at a defined level through disruption. If exercises, real disruptions, and metrics show that the outcomes are not being met, or are being met only narrowly, the BCMS is not effective, regardless of how good the documentation looks.

Together, these three dimensions give an auditor a structured way to test the improvement claim: "Show me what changed in the last cycle on each of suitability, adequacy, and effectiveness, and show me the evidence that the change was an improvement."

The proactive/reactive demarcation from Clause 10.1

This demarcation is the most-tested conceptual point in Clause 10 audits, and the one most organisations blur in practice:

In practice the same action (rewriting a plan, buying a tool, training a team) can be triggered by either clause. The rule is: if the trigger was a detected nonconformity, the action and its evidence are managed under 10.1; if the trigger was an opportunity, they are managed under 10.2. Many organisations keep a single register with a "trigger" field so the distinction is auditable.

The seven improvement drivers, what feeds Clause 10.2

A working Clause 10.2 programme draws improvement opportunities from at least seven sources. A certifier looking at the improvement register expects to see all seven represented:

1. Exercise after-action findings (Clause 8.5). Every exercise, tabletop, component test, simulation, full failover, produces observations. Some are nonconformities (RTO missed; plan step failed) and go to 10.1; many are improvements (the plan worked, but the call tree was slow; the plan worked, but a key vendor was not tested; the plan worked, but people improvised around a confusing step). The latter feed 10.2.
2. Real-disruption lessons (Clauses 8.4 and 8.6). Real activations are the highest-fidelity test of the BCMS. The post-disruption review (Clause 8.6) will surface both nonconformities (10.1) and improvements (10.2), for example, "the plan worked, but the regulator engagement was improvised; we should pre-stage a regulator-comms playbook."
3. Audit and assurance findings (Clause 9.2 internal audit; external/supervisory audits). Audit recommendations (not nonconformities) feed 10.2. A common audit recommendation is "the BIA should be refreshed annually and after significant change", that is a 10.2 improvement if it is not yet an NC.
4. Monitoring and measurement outputs (Clause 9.1). KPIs and KRIs flag deterioration before it becomes an NC. A six-quarter decline in DR-test RTO achievement is not yet an NC, but it is a 10.2 signal: the system is losing effectiveness, and the improvement programme should diagnose and reverse the trend.
5. Management-review output (Clause 9.3). Management review is where strategic questions are asked ("are we still scoped to the right activities?", "are our objectives still right for the strategy?", "are we keeping pace with industry benchmarks?"). Review output should include improvement decisions, new objectives, scope changes, resource reallocations, that are tracked under 10.2.
6. Benchmarks, horizon scanning, and external intelligence. Industry benchmarks (BCI Horizon Scan reports, regulator-published sector data, published incident case studies), regulator bulletins (CERT-In advisories, RBI/SEBI/IRDAI circulars), and credible analyses of other organisations' public incidents (e.g., the AIIMS Delhi 2022 ransomware; the Cognizant Maze 2020 SEC-filed disclosure; the Jio September 2024 data-centre fire) are all raw material. The discipline is to convert each into a "could this happen to us, and what would we improve to reduce the impact?" question.
7. Change in the organisation, its technology, its risk picture, or its environment. Clause 4.1 context changes (a new product, a new geography, a new ownership structure, a new climate-exposed site, Amendment 1:2024 climate-change considerations), Clause 6.1 risk-and-opportunity changes (a new threat, a new dependency, a new opportunity to differentiate on resilience), and Clause 8.1 technology changes (cloud migration, AI adoption, supply-chain re-architecture) all create both requirements to update the BCMS (managed under Clause 6.3 planning of changes) and opportunities to improve it (managed under 10.2).

The PDCA engine and its place in Clause 10.2

ISO management-system standards are built on the Plan-Do-Check-Act (PDCA) cycle, and Clause 10.2 is where the "Act" stage explicitly lives at the system level (Clause 10.1 is "Act" at the nonconformity level). Concretely, the PDCA loop for Clause 10.2 looks like this:

• Plan, set improvement objectives tied to the BCMS objectives (Clause 6.2), fund the improvement programme, identify a portfolio of opportunities (the seven drivers above), prioritise, assign owners.
• Do, implement improvements as planned changes under Clause 6.3 (purpose, consequences, resources, responsibilities); communicate; train; pilot where appropriate.
• Check, verify the improvement delivered the intended gain in suitability, adequacy, or effectiveness; measure using the Clause 9.1 KPIs; review at Clause 9.3 management review; benchmark externally.
• Act, standardise what worked; institutionalise the lesson in plans, policies, objectives; close the loop and feed the next Plan stage.

This is structurally identical to the Kaizen discipline practised in high-maturity manufacturing and software organisations: small, frequent, evidence-led improvements, owned by the people closest to the work, accumulated into large cumulative gains over years. A growing Indian company that institutionalises Kaizen-style BCM improvement outperforms a competitor that relies on episodic, top-down "transformation" programmes, because the Kaizen firm gets better every quarter while the transformation firm gets better every three years (and loses ground in between).

What the clause does NOT require (the demarcation that protects you from over-engineering)

• 10.2 does not require improvement to match the largest firms in the sector. It requires continual improvement, that the system is demonstrably better this cycle than last, in ways appropriate to the organisation's size, risk, and resources. A 50-person SaaS firm and a 50,000-person bank both satisfy 10.2; what differs is the scale of improvement that is "appropriate" to each.
• 10.2 does not require every improvement idea to be implemented. It requires a defensible prioritisation method. An organisation that receives 40 improvement opportunities in a year, implements 12, defers 20 with documented rationale, and rejects 8 with documented rationale is fully compliant. The point is that the decision was conscious and risk-based, not that every idea became a project.
• 10.2 is not a licence to make unplanned, disruptive changes to the BCMS. Improvement changes go through Clause 6.3 (Planning Changes to the BCMS), purpose, consequences, resources, responsibilities, exactly like any other BCMS change. An "improvement" rushed in without planning, that destabilises the system, is a Clause 6.3 nonconformity even if the intent was good.
• 10.2 is not the same as "do more exercises" or "do bigger exercises". Quantity is not improvement. The clause asks for evidence that the system is more suitable, adequate, and effective, exercises are a source of improvement, not the improvement itself.
• 10.2 is not "raise RTO/RPO targets every year". Targets are derived from the BIA (Clause 8.2), not from the improvement programme. Improvement may result in the organisation being able to achieve tighter targets, or in the BIA showing that the business now wants tighter targets, but 10.2 itself does not set them.
• 10.2 is not "buy more BCM tooling". Tooling can be an improvement, but only if the problem it solves was first diagnosed. Many organisations buy enterprise IRM suites and discover the underlying BCM discipline was the bottleneck, not the tool, the platform is then an expensive decoration over an unchanged system.

What auditors actually check (certification & surveillance)

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

1. A live improvement/opportunity register (spreadsheet, GRC tool, or database) with entries from multiple sources, not just audit.
2. Evidence of prioritisation, a documented method (impact × effort, risk-based, ROI-based) and its application. An auditor will pick three opportunities and ask "why was this one funded and these two deferred?"
3. Traceable implementation under Clause 6.3, for sampled improvements, the planning artefact, the change record, the test/evidence of completion.
4. Effectiveness verification, for sampled improvements, the evidence that the intended gain was realised. "We implemented X" without "and here is the measured improvement" is incomplete.
5. Suitability/adequacy/effectiveness progression, the auditor will look at the BCMS at two points in time (e.g., the last two surveillances) and ask what is materially different. A BCMS that has not changed is a 10.2 red flag regardless of how clean its documentation is.
6. Management-review linkage (Clause 9.3), improvement decisions and the strategic questioning that drove them should appear in management-review minutes, and management-review output should drive improvement actions.
7. Clause 6.1 / 6.2 update, when an improvement changes the risk picture or raises the bar on what is achievable, the risk register and objectives should be updated to reflect that.
8. Lessons-learned from external events, an auditor may ask "what did you change in your BCMS as a result of [a named external incident, e.g., AIIMS 2022 or CrowdStrike 2024]?" A blank answer is a 10.2 finding.

Why This Control Matters

The "frozen BCMS" failure pattern

Most BCMS failures that reach the public record are not failures of plan quality at the time the plan was written. They are failures of plan obsolescence, the plan was good for the organisation as it was, but the organisation changed, the threat changed, or the technology changed, and the plan did not. The BCMS was frozen while the world moved.

Three structural forces guarantee obsolescence unless Clause 10.2 is alive:

1. The organisation changes. Products are added; geographies are entered; teams are restructured; vendors are swapped; companies are acquired; staff turn over. Each change alters who must do what, in which order, with which resources, to keep prioritised activities running through disruption. A plan that maps to last year's org chart fails in this year's disruption.
2. The threat changes. Ransomware professionalised between 2018 and 2023; generative-AI-enabled social engineering emerged between 2022 and 2024; climate-driven floods hit geographies previously considered low-risk; supply-chain attacks became a primary attack vector; geopolitical fragmentation reshaped vendor and dependency risk. A threat assessment done in 2020 is not adequate to 2026.
3. The technology changes. Cloud migration, containerisation, serverless, AI/ML pipelines, and SaaS consolidation have rewritten the dependency map of every growing digital business. The BCMS that assumed a single on-prem data centre is structurally wrong for a multi-cloud, API-mediated, third-party-heavy estate.

The pattern is so reliable in the Indian record that the absence of Clause 10.2 discipline has its own archetype: the "frozen-after-certification" organisation, which earned ISO 22301 by writing a defensible BCMS, then stopped improving it because the certificate was on the wall. Two to three years later, the certificate is still on the wall but the BCMS no longer describes the organisation, and the next real disruption exposes the gap. The certifier escalates at surveillance; the regulator escalates after the incident; the cycle of cost described in §3.4 begins.

The Indian regulatory context, why 10.2 is now a strategic duty

The Indian regulatory environment has, over the last five years, made demonstrable improvement of operational-resilience and continuity capability a board-level and regulator-facing expectation:

• RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (issued 7 November 2023, effective 1 April 2024) is structurally an improvement instrument: it expects the board and senior management to continually raise the maturity of IT service continuity, BCP/DR capability, and outsourcing-risk oversight. The Direction expects periodic external IS audits, supervisory corrective-action closure tracking, and benchmarking, all 10.2-grade disciplines. The HDFC enforcement of December 2020 was, at its core, an RBI response to the absence of demonstrable improvement across three outage cycles.
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) (circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, dated 20 August 2024) is structured as 5 cyber-resilience goals × 6 cybersecurity functions: Governance, Identify, Protect, Detect, Respond, Recover. The "Evolve" goal is the regulatory restatement of Clause 10.2: a SEBI-regulated entity must turn incidents, exercises, audits, and benchmarks into documented improvements, tracked to implementation, with effectiveness verified and reported to the board's Risk Management Committee. CSCRF deadlines phased through 2025 create an enforced improvement cadence.
• 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 only incidents but the improvements implemented to prevent recurrence and raise resilience, a direct 10.2 obligation with regulator visibility.
• 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 improvement actions from prior-year findings. The compliance return is structurally a 10.2 trend report to the regulator.
• RBI Cyber Security Framework in Banks (2 June 2016) requires periodic cyber drills, board-reviewed Cyber Crisis Management Plan, and reporting of cyber incidents within 2–6 hours. Each drill and incident becomes raw material for the 10.2 pipeline; the improvement output is examinable.
• CERT-In Directions (No. 20(3)/2022-CERT-In, dated 28 April 2022), the six-hour incident-reporting clock, 180-day log retention, NTP sync, and the Point-of-Contact designation create an ongoing stream of signals about ICT resilience. A reportable incident that recurs is, by definition, evidence that the 10.2 loop did not close.
• 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. Continual adequacy of security safeguards is the statutory standard; penalties reach ₹250 crore for safeguard failure and ₹200 crore for breach-notification failure. The DPDP frame treats availability as something the Data Fiduciary must keep improving against an evolving threat, exactly Clause 10.2.
• 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. Section 177(4)(vii) makes the Audit Committee evaluate internal financial controls and risk-management systems. 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. Together, these instruments make demonstrable improvement of operational-resilience capability a board-reportable expectation, and an organisation that cannot show year-over-year improvement is exposed.
• Disaster Management Act 2005 and NDMA Guidelines (Chemical Disaster 2007; DMP-template) institutionalise a national improvement discipline: every Disaster Management Plan is reviewed and updated on a defined cadence; every post-disaster review feeds the next plan. Indian industry operating under these frameworks (especially MAH / chemical / manufacturing) inherits a Clause-10.2-shaped obligation by statute.

The strategic implication for a growing Indian company: Clause 10.2 is no longer optional, and it is no longer only the certifier's concern. The Indian regulatory matrix (RBI/SEBI/IRDAI/CERT-In/DPDP/Companies Act/NDMA) now expects the same ongoing-improvement discipline that 10.2 codifies, and an organisation that cannot evidence it is one supervisory engagement away from enforcement.

The cost of a frozen BCMS, by sector

The cost of an obsolescent BCMS

For a growing Indian company, the avoidable cost of a frozen BCMS that gets exposed by a real disruption comes in six forms:

• Direct response and recovery cost (incident response, forensics, recovery engineering, customer SLA credits).
• Lost revenue during extended disruption, for multiple days if the BCMS is too stale to recover quickly.
• Regulatory engagement across a multi-month supervisory engagement (response, mandated external audit, remediation evidence).
• 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, conditions on the certificate, or suspension if the obsolescence is severe.
• Talent and governance cost: typically a senior departure (CIO/CISO/BCM Manager), board-committee review overhead, and a programme rebuild over 12–18 months.

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

The flip side: the strategic upside of demonstrable improvement

The cost story is half the picture. The other half is the upside: organisations that institutionalise Clause 10.2 discipline turn resilience into a commercial advantage. Three patterns recur:

• Sales-cycle acceleration in B2B. A documented improvement programme, current benchmark results, recent exercise outcomes, a credible maturity trajectory, closes security and continuity questionnaires faster. Growing Indian SaaS firms selling to global enterprise customers report that the "what did you change last year?" question is now standard in security reviews; a strong answer shortens cycles by weeks.
• Regulator-grade disclosures that strengthen trust. Boards and audit committees increasingly expect a trajectory, not a snapshot. A CISO or BCM Manager who can show "we moved from L2 to L4 in 24 months on these specific dimensions, here is the evidence" converts operational resilience from a cost centre into a board-level confidence story.
• Insurance and capital-market benefits. Cyber-insurance underwriters and IPO/Disclosure-quality reviewers increasingly price in the improvement discipline of the organisation. A documented Clause 10.2 programme is a measurable, defensible answer to "how do you ensure this doesn't calcify?"

The strategic summary: in 2026, the BCMS that is not visibly improving is visibly decaying, and that decay is now legible to regulators, customers, boards, and insurers. Clause 10.2 is the discipline that keeps the trajectory positive.

Scope and Applicability

Applicability by organisation size

Clause 10.2 applies identically to every organisation in scope of ISO 22301, there is no small-organisation exemption. What changes by size is the machinery and the evidence depth expected at audit:

Applicability by sector (India)

What is in scope for Clause 10.2 vs out of scope

In scope (Clause 10.2 applies):

• Any opportunity to improve the suitability, adequacy, or effectiveness of any part of the BCMS (Clauses 4–10).
• Improvements from any source: exercises, real disruptions, audits (internal and external), monitoring/KPIs, management review, benchmarks, regulator bulletins, external incidents, organisational/technology/risk change, employee suggestions.
• Improvements to documented information (Clause 7.5), to plans (Clause 8.4), to exercises (Clause 8.5), to strategies (Clause 8.3), to scope (Clause 4.3), to policy (Clause 5.2), to objectives (Clause 6.2), to competence (Clause 7.2), to awareness (Clause 7.3), and to the management-system processes themselves.
• Improvements that also change the risk picture (these must update Clause 6.1) or the objectives (Clause 6.2).

Out of scope (or a different clause):

• Reactive correction of a detected nonconformity (Clause 10.1), the trigger is what matters; a nonconformity is a 10.1 input, an opportunity is a 10.2 input.
• Risk-treatment actions (Clause 6.1), those address identified risks, not BCMS improvement. (But many 10.2 improvements change the risk picture, and the Clause 6.1 register must then be updated.)
• Internal-audit recommendations that are scoped as nonconformities, these go to 10.1. Audit recommendations that are not nonconformities go to 10.2.
• Day-to-day incident response and recovery operations (Clause 8.4), that is the live activity; 10.2 is the improvement layer that consumes lessons from those operations.

Key Definitions and Terminology

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

The core terms of Clause 10.2

Continual improvement, recurring activity to enhance performance; in the BCMS context, the ongoing, evidenced raising of the suitability, adequacy, and effectiveness of the business continuity management system. Note the distinction from "continuous improvement": continual means "happening repeatedly with a defined cadence," not "happening every second." Both are valid improvement philosophies; Clause 10.2 is satisfied by either as long as the cadence is real and the evidence is auditable.

Suitability, the degree to which the BCMS fits the organisation: its scope, structure, processes, and resourcing are aligned to the organisation as it currently is (not as it was when the BCMS was first designed).

Adequacy, the degree to which the BCMS is sufficient for the risk picture: the controls, plans, resources, and capabilities are commensurate with the threats, dependencies, and exposures the organisation actually faces.

Effectiveness, the degree to which the BCMS achieves its intended outcomes: prioritised activities are continued at a defined level through disruption, as measured by exercises, real disruptions, and Clause 9.1 KPIs.

Improvement opportunity (also: opportunity for improvement, OFI), a documented idea, observation, or signal that suggests the BCMS could be made more suitable, more adequate, or more effective. The unit of currency of the Improvement / Opportunity Register.

Improvement action, a planned change (under Clause 6.3) that, when implemented, is intended to deliver a measurable gain in suitability, adequacy, or effectiveness. The audit-traceable artefact in the register.

Effectiveness verification, the post-implementation check that the improvement actually delivered the intended gain. The 10.2 analogue of the 10.1 effectiveness check.

The BCMS-specific terms that 10.2 acts on

Recovery Time Objective (RTO), the target time set for the resumption of a prioritised activity after a disruptive incident. RTO is not an improvement metric by itself, but the trend of RTO achievement across exercises is.

Recovery Point Objective (RPO), the point in time to which information used by an activity must be restored. Like RTO, the trend of RPO achievement is the 10.2 signal.

Minimum Business Continuity Objective (MBCO), the minimum level of activity or output acceptable during recovery. Improvement may raise MBCO (we now expect to deliver more during disruption than we used to) or lower it (we have honestly recognised that we cannot sustain the prior level).

Maximum Tolerable Period of Disruption (MTPD), the maximum period an organisation can tolerate disruption of a prioritised activity before it becomes unacceptable. Also called Maximum Acceptable Outage (MAO) in legacy BCI / ISO 22301:2012 vocabulary. Improvement in MTPD-setting maturity (e.g., moving from "guesses" to "evidence-based BIA") is a 10.2 dimension.

Prioritised activity, the activity that must be continued through disruption to deliver a prioritised product or service. The Clause 8.2 BIA identifies them; Clause 10.2 ensures the list is kept current as the organisation changes.

Exercise, the process of training, exercising, testing, and rehearsal of BC plans and procedures (Clause 8.5). The richest source of improvement opportunities.

Lessons-learned log, a structured record of lessons drawn from exercises, real disruptions, audits, and external events, with their disposition (implemented as improvement, deferred, rejected with rationale).

The improvement-discipline terms (Kaizen, PDCA, benchmarking)

PDCA (Plan-Do-Check-Act), the iterative management discipline that underpins all ISO management-system standards. In Clause 10.2, "Act" is the explicit improvement stage at the system level.

Kaizen, a disciplined practice of small, frequent, evidence-led improvements owned by the people closest to the work, accumulated into large cumulative gains. Originally a manufacturing discipline, now applied in software (continuous integration, retrospectives), safety, and BCM. The cultural counterpart of Clause 10.2.

Benchmarking, the structured comparison of one's own BCM performance, maturity, or practice against external reference points (industry datasets, published incident case studies, regulator-published sector data, or specific high-performing peers). A recurring source of 10.2 opportunities.

Maturity model, a structured scale (typically L1–L5) describing the progression of a discipline from ad-hoc to optimising. Used as both a measure of improvement and a roadmap of where to improve next.

KPI (Key Performance Indicator) and KRI (Key Risk Indicator), quantitative measures of BCMS performance (KPI) and of risks that could affect the BCMS (KRI). Their trends are 10.2 signals; their definitions are themselves improvable over time.

Horizon scanning, the structured practice of looking outward to identify emerging risks, technologies, and practices that could affect the BCMS. A standing input to the 10.2 pipeline.

Terms that 10.2 guards against

BCMS calcification / BCMS staleness, the failure mode in which a BCMS that once conformed is no longer fit for purpose because the organisation, threat, or technology changed and the BCMS did not. The principal anti-pattern that Clause 10.2 exists to prevent.

Recurrence, when the same nonconformity or the same disruption pattern appears more than once. Recurrence is both a 10.1 failure (corrective action was ineffective) and a 10.2 failure (improvement did not raise the bar enough to make the pattern impossible). The HDFC and DBS/MAS patterns are the textbook examples.

Plan-exercise disconnect, the failure mode in which exercises no longer stress the plan (because the same scenarios are used, the same people participate, the same result is reached), so the plan appears "validated" but is in fact untested against the current reality. A 10.2-disciplined exercise programme rotates scenarios, escalates scope, and challenges assumptions.

Relationship to Other Clauses

Clause 10.2 in the BCMS architecture

Clause 10.2 is the "Act" loop of the BCMS PDCA at the system level. It draws inputs from almost every other clause and writes outputs back into several. A clear map of those relationships is what an auditor walks when assessing the clause:

                       [Clause 4 Context]      [Clause 5 Leadership]     [Clause 6 Planning]
                              │                         │                         │
                              ▼                         ▼                         ▼
                   (org/threat change     (top-mgmt accountability   (6.1 risks & opportunities,
                    as 10.2 input)         for the improvement arc)   6.2 objectives, 6.3 change
                                                                                   │
                                                                                   ▼
[Clause 9.3 Mgmt Review] ───►  [Clause 10.2 CONTINUAL IMPROVEMENT] ◄─── [Clause 9.1 Monitoring]
   (strategic questioning,          │       │                              (KPI/KRI trends as
    improvement decisions)          │       │                               10.2 signals)
                                   │       │
                  [Clause 9.2      │       │       [Clause 8.5 Exercises]   [Clause 8.6 Post-disruption review]
                   Internal audit]  │       │       (after-action items     (real-disruption lessons
                                   │       │        as 10.2 inputs)          as 10.2 inputs)
                                   ▼       ▼
                       (10.2 updates 6.1, 6.2, 7.5, 8.4, 8.5; pushes
                        improvements via 6.3 planned-change discipline)
                                   │
                                   ▼
                          [Clause 10.1 Corrective Action]
                          (reactive sibling; same artefact types, different trigger)

The closest clause relationships

What 10.2 is NOT, the demarcation from adjacent clauses

• 10.2 is not the same as 10.1. Different triggers, different timing, different energy source. The same artefact (a register entry, a planned change) may exist in either, but the attribution of the trigger must be clean for audit-traceability.
• 10.2 is not the same as 9.3 (Management Review). 9.3 is the forum; 10.2 is the activity. A strong management review produces improvement decisions; a strong 10.2 programme produces evidence that those decisions were implemented and verified.
• 10.2 is not the same as 6.3 (Planning Changes). 6.3 is the method for any BCMS change; 10.2 is the engine that identifies improvement changes and feeds them into 6.3. Every 10.2 improvement is a 6.3 change; not every 6.3 change is a 10.2 improvement (some are corrective, some are scope-driven, some are strategic pivots).
• 10.2 is not "innovation" or "transformation". Those are bigger, episodic, often externally-driven programmes. 10.2 is the steady, recurring, evidenced raising of the bar, it accumulates into transformation-scale change over years without ever being named a transformation.

Cross-framework relationships (preview, full mapping in §16)

• ISO 27001:2022 Clauses 10.1 (Continual improvement) and 10.2 (Nonconformity and corrective action), the ISMS equivalent of Clauses 10.2 and 10.1. A combined ISMS+BCMS shop should run a single improvement register with framework tags.
• ISO 27001 A.5.29 (Information security during disruption) and A.5.30 (ICT readiness for business continuity), the security-side siblings of Clause 8.4 and 8.5; their improvement is a 10.2 obligation for any organisation running both standards.
• NIST CSF 2.0 ID.IM (Improvement) and the GV (Govern) function, the US-framework equivalent of the 10.2 discipline in the recovery and governance slices.
• SEBI CSCRF "Evolve" goal, the regulatory restatement of 10.2 for Indian capital-markets entities.
• DORA Art 13 ("Learning and evolving"), the EU financial-resilience restatement of 10.2.
• APRA CPS 230 para 42 (annual BCM exercise) + para 45 (internal audit review), the prudential-regulator mechanism that creates the recurring 10.2 trigger.

Detailed Implementation Guidance

The five capabilities of a working Clause 10.2 programme

A defensible Clause 10.2 programme is built from five interlocking capabilities. A certifier walks each one:

1. Detection, the disciplined intake of improvement opportunities from all seven sources (§2.3).
2. Triage and prioritisation, a defensible method for choosing what to fund.
3. Implementation, planned-change discipline under Clause 6.3, with named owners and dates.
4. Effectiveness verification, measured evidence that the improvement worked.
5. Standardisation and feedback, folding the improvement into the BCMS so it persists; feeding the next cycle.

Capability 1, Detection: building the Improvement / Opportunity Register

The Improvement / Opportunity Register is the single source of truth for 10.2 evidence. It is structurally similar to the NCR/CAPA register under 10.1, but the entries are opportunities rather than nonconformities. The minimum fields:

A growing Indian company at the Singahi scale (250–2,000 employees) should expect 20–80 improvement opportunities per year in the register, more if the exercise programme is rigorous, fewer if it is light. A register with only one or two entries per year is itself a red flag: it suggests detection is broken, not that there is nothing to improve.

Capability 2, Triage and prioritisation

Most organisations fail 10.2 not at detection but at prioritisation, they collect opportunities but cannot defend why this one was funded and those were not. The certifier's question is always: "Show me your prioritisation method."

A workable method for growing Indian companies is a 2×2 impact-vs-effort matrix with a risk overlay:

• Impact (1–5), the gain in suitability, adequacy, or effectiveness, weighted by the criticality of the affected prioritised activity. A 1-point RTO improvement on a Tier-1 activity is high impact; a 5% documentation cleanup on a Tier-3 plan is low.
• Effort (1–5), person-days, capex, opex, and political cost, weighted by availability. A modest infrastructure change that requires a maintenance window is medium effort; a multi-year programme that requires board approval is high.
• Risk overlay, opportunities that close a risk on the Clause 6.1 register, satisfy a regulatory expectation, or pre-empt a known external threat get a +1 priority bump.
• Quadrant logic, High impact / Low effort → "Quick wins, do this quarter." High impact / High effort → "Strategic, plan and budget." Low impact / Low effort → "Fill-in work, batch when capacity allows." Low impact / High effort → "Reject with rationale."

The rejection rationale matters as much as the funding decision. An opportunity rejected without a documented reason will be raised again; an opportunity rejected with a reason ("deferred pending Q3 budget cycle; will revisit") closes the loop and demonstrates that the prioritisation is a real process.

A more mature organisation adds ROI estimation to the matrix: for each candidate improvement, an estimate of "cost to implement" vs "expected reduction in annualised loss exposure" (ALE). This is more rigorous but also more error-prone (ALE estimates depend on loss data that is often thin). For growing Indian companies, the 2×2 + risk overlay is usually sufficient until L4 maturity.

Capability 3, Implementation: planned changes under Clause 6.3

Every improvement that survives prioritisation is a planned change and must satisfy Clause 6.3. The 10.2 implementation discipline is essentially the 6.3 discipline applied to improvement changes:

1. Define the purpose, what is the intended gain in suitability, adequacy, or effectiveness? Write it as a measurable statement: "raise DR-test RTO-achieve% from 75% to >95% for the digital channels by Q3."
2. Assess the consequences, what else changes if we make this change? Will it affect other plans, other teams, other systems? Will it require training (Clause 7.2), communication (Clause 7.4), updated documented information (Clause 7.5)?
3. Allocate resources, capex, opex, person-days, calendar time. Confirm budget availability. A "shall be done by Q3" without allocated resources is not a plan, it is a wish.
4. Assign responsibilities, named owner (accountable), named implementers (responsible), named reviewers. Avoid "the BCM team will do it" as an owner, names, not teams.
5. Schedule, target date and intermediate milestones; integration with the BCM Forum cadence and the management-review cycle.
6. Plan the effectiveness verification, before implementation, decide how the gain will be measured. This is the single most-skipped step. If you decide verification afterwards, you will measure whatever is convenient rather than what you set out to improve.
7. Communicate, Clause 7.4 obligation. Improvements that affect people's roles or response procedures must be communicated before they take effect, not after.

Capability 4, Effectiveness verification

Effectiveness verification is the step that turns "we implemented an improvement" into "we have evidence the improvement worked." It is the 10.2 analogue of the 10.1 effectiveness check. The discipline:

• Define the metric before implementation. A measurable indicator (RTO-achieve %, plan currency %, MBCO attainment %, KRI breach count, etc.) with a baseline and a target.
• Choose the verification method. Re-run the exercise that produced the opportunity; re-run the audit test; re-measure the KPI after a defined period; conduct a targeted test; conduct a tabletop on the new procedure. The method should mirror the trigger.
• Set the verification interval. Typically 30/60/90 days post-implementation for tactical improvements; one full exercise cycle (3–6 months) for plan or strategy improvements; one annual cycle for policy or scope changes.
• Document the result. "Improvement delivered the intended gain" / "Partial gain, here is the gap and the follow-up action" / "No gain, here is the re-plan." All three are legitimate; the third is rare but credible.
• Close the loop in the register. The opportunity moves from "Implemented" to "Verified-effective" (or back to "Open" if the verification failed).

A common audit question: "Show me three improvements from the last cycle that were verified-effective, and one that was not." A register where every entry is "verified effective" with no nuance is itself a red flag, it suggests the verification is shallow.

Capability 5, Standardisation and feedback

The last capability is the discipline that prevents improvements from eroding. An improvement that depends on a single person's effort or memory will not persist; an improvement that has been standardised into the BCMS persists. Standardisation has three layers:

• Documented information updated (Clause 7.5). The plan, procedure, RTO/RPO catalogue, exercise calendar, BIA, whatever the improvement changed, is updated. The version history shows the change.
• Training and awareness updated (Clause 7.2, 7.3). The people affected are trained on the new way; the awareness programme reflects it.
• Objectives and risk register updated (Clause 6.2, 6.1). If the improvement raises the bar on what is achievable, objectives are tightened; if it closes a risk, the register is updated; if it creates new risks, they are added.

Feedback into the next cycle is the final step. Every verified-effective improvement is a candidate for replication, if it worked in this team, could it work in others? If it worked for this plan, could it work for the others? A mature 10.2 programme treats every improvement as a hypothesis tested, and uses the result to refine the next set of hypotheses.

Tiered implementation by maturity

For an L1–L2 organisation (early maturity):

• Stand up the Improvement / Opportunity Register (a spreadsheet is fine).
• Set a quarterly cadence for review at the BCM Forum.
• Drive detection from the two richest sources: exercises and real disruptions.
• Use a simple impact-vs-effort 2×2 for prioritisation.
• Implement 4–8 improvements per year; verify each one at 30/60/90 days.
• Communicate improvements to top management at the management-review cycle.

For an L3 organisation (certification floor):

• Document a Continual Improvement Procedure (see §9 and toolkit doc 02).
• Run the register inside a growing GRC SaaS or a structured spreadsheet with version history.
• Add the remaining detection sources: audit, monitoring, management review, benchmarks, change.
• Adopt a documented prioritisation method with risk overlay.
• Implement 12–30 improvements per year; verify each; close the loop in the register.
• Benchmark against at least one external dataset (BCI Horizon Scan is the canonical BCM dataset; regulator-published sector data is another).
• Tie the improvement programme to the BCMS objectives (Clause 6.2) and report the trajectory to the management review.

For an L4 organisation (advanced):

• Move to metric-driven improvement: KPI/KRI trends as primary signals; statistical control charts; predictive indicators.
• Benchmark against multiple external datasets; participate in industry-resilience surveys.
• Introduce an annual improvement roadmap (12-month look-ahead) approved by top management.
• Implement 30–80 improvements per year, plus 1–3 strategic multi-quarter programmes.
• Integrate BCM improvement with security (ISO 27001), quality (ISO 9001 if applicable), and operational risk (enterprise risk register) where these exist.
• Begin ROI estimation for major improvements using loss-exposure modelling.

For an L5 organisation (optimising):

• Embed improvement in the operating culture: every team runs short-cycle retrospectives; BCM is a normal part of how work is done, not a separate programme.
• Cross-functional improvement engine: BCM, security, SRE, quality, safety, and operational risk share a single improvement pipeline.
• Industry-leader benchmarking; participation in regulator / industry working groups; published contributions to the discipline.
• Predictive KRIs that trigger improvements before any NC is detected.
• Annual external maturity assessment; publication of improvement trajectory in board and stakeholder reporting.

Tools, Technologies, and Solutions

The tooling landscape (category-level)

Tool selection is a 10.2 decision in its own right, and the discipline is to diagnose the problem before buying the platform. The BCM tooling market has four broad categories relevant to Clause 10.2:

A tool-comparison matrix at category level (we do not name vendors in comparison matrices):

Cost-discipline note: the most expensive tool decision is buying a platform before the discipline exists. A growing company that buys an enterprise IRM suite at L2 maturity typically under-uses it (single-digit-percent feature adoption), pays heavy licence + integration cost, and discovers two years later that the underlying BCM discipline is still L2. The recommended path: define the discipline (procedure, register, cadence, prioritisation) in office-suite tools first; once the discipline is in muscle memory, choose the platform that matches the maturity, not the one that promises to substitute for it.

Adjacent tooling that 10.2 touches

Beyond the BCM/GRC platform, Clause 10.2 interacts with several adjacent tool categories:

• BC / DR runbook and plan automation, category-level "BCM-specialist SaaS" or "DR-replication tech" with automated failover, runbook orchestration, and exercise-scheduling. Improvements to runbook automation are common 10.2 outputs.
• Backup and recovery technology, immutable / air-gapped / segregated backups (the AIIMS 2022 lesson); DR-as-a-Service from cloud providers (AWS, Azure, GCP); replication and snapshot tooling. Backup maturity is a 10.2 dimension; many organisations' single biggest 10.2 improvement is "from tarball-to-immutable-backup."
• Crisis-communication and mass-notification, category-level "mass-notification platform" for activation trees, two-way messaging, multi-channel (SMS, voice, app push) delivery. Improvement candidates: WhatsApp groups (near-ubiquitous, low-friction, but limited audit trail) supplemented by a purpose-built platform for evidence-grade notifications.
• Monitoring, observability, SRE, the modern observability stack (APM, log aggregation, synthetics, SLO monitoring) is a rich source of KPI/KRI trends that feed 10.2. The discipline is to translate SRE signals (e.g., error-budget burn-down) into BCM signals (e.g., RTO risk to a prioritised activity).
• Risk register / IRM, if the organisation runs an enterprise risk register or an IRM platform, the BCM improvement programme should integrate with it (a control improvement may close an enterprise risk; a new BCM risk should appear in the enterprise register).
• Collaboration and documentation, SharePoint / Google Workspace / Confluence are near-ubiquitous for documented information; the discipline is version control, review-cycle evidence, and access control. Draw.io / Lucidchart / Visio / Miro for dependency maps and BIA visualisations.

The "people are the platform" reminder

For growing Indian companies especially, the most important 10.2 "tool" is not software, it is a named BCM Manager with the time, authority, and access to run the improvement programme. A common failure pattern in growing Indian firms is to assign the BCM role as a part-time responsibility to an already-overloaded CIO or Head of IT, with the result that the improvement programme is the first thing that slips when operational pressure rises. The single most valuable 10.2 investment for a growing company is often a full-time BCM Manager (a mid-career professional with 8–15 years of relevant experience) with direct access to the C-suite and a defined seat at the BCM Forum.

Policy and Procedure Templates

The toolkit that accompanies this guide contains a complete Continual Improvement Policy template (toolkit doc 01) and a Continual Improvement Procedure (toolkit doc 02). This section summarises their content so the reader can see what good looks like. Sample policy clauses using "shall" language are fine, they are our own drafting, not the standard's text.

Continual Improvement Policy, sample clauses

A defensible Continual Improvement Policy for a growing Indian company contains clauses of this shape (illustrative, full template in toolkit doc 01):

ISO 22301:2019 Clause 10.2 asks organizations to continually improve the suitability, adequacy, and effectiveness of the BCMS.

The Organisation shall maintain a single Improvement / Opportunity Register as the authoritative record of all opportunities under Clause 10.2, regardless of source.

Top management shall review the improvement trajectory, opportunities detected, prioritisation decisions, implementation status, effectiveness verification, and benchmark comparison, at every meeting of the BCM Forum and at every management review.

The Organisation shall draw improvement opportunities from at least the following sources: exercise after-action findings; real-disruption lessons; internal-audit recommendations; external/supervisory audit recommendations; KPI/KRI trends from Clause 9.1; management-review output; benchmarking and horizon scanning; organisational, technological, regulatory, and risk-context change.

Every improvement implemented under this Policy shall be a planned change under the Clause 6.3 change-management discipline and shall have a named owner, an allocated budget, a target date, and a defined effectiveness verification.

The Organisation shall benchmark its BCMS against at least one external dataset annually and shall convert benchmark findings into improvement opportunities.

The Organisation shall ensure that this Policy and the underlying Procedure are reviewed at least annually and after any significant change to the organisation, its risk picture, or its regulatory environment.

Continual Improvement Procedure, the seven-stage operating model

The Procedure (toolkit doc 02) operationalises the Policy through a seven-stage loop that mirrors the five capabilities (§7.1) plus the prioritisation and review stages:

1. Detect, every source (exercises, disruptions, audit, monitoring, management review, benchmarks, change) has a defined intake path into the register.
2. Log, opportunities are recorded in the Improvement / Opportunity Register with the §7.2 fields.
3. Triage, each opportunity is screened for relevance, scope, and duplication; duplicates are merged; out-of-scope items are routed to the right forum (e.g., a security finding is routed to the ISMS).
4. Prioritise, the 2×2 impact-vs-effort matrix with risk overlay (§7.3) is applied; funding decisions are made at the BCM Forum.
5. Plan, funded improvements are scoped as Clause 6.3 planned changes with purpose, consequences, resources, responsibilities, schedule, and verification method.
6. Implement, the planned change is executed; documented information is updated; training and communication are delivered.
7. Verify and standardise, at the defined interval post-implementation, the effectiveness check is conducted; the result is recorded; verified-effective improvements are standardised into the BCMS and the next cycle is informed.

RACI summary (full matrix in toolkit doc 13)

(R = Responsible, A = Accountable, C = Consulted, I = Informed.)

Templates that make the discipline visible

The toolkit includes a Continual Improvement Procedure (doc 02), an Implementation Checklist (doc 03), an Audit-Evidence Checklist (doc 04), an Implementation Roadmap (doc 05), a Quick Reference Card (doc 06), Training Materials (doc 07), an Improvement-Opportunity Intake Playbook (doc 08), an Improvement Prioritisation Template (doc 09), a Vendor Improvement Template (doc 10), a Metrics & KPI Dashboard (doc 11), a Gap-Analysis Template (doc 12), a RACI Matrix (doc 13), a Tool-Comparison Matrix (doc 14), a Communication Plan (doc 15), a Roles-and-Responsibilities doc (doc 16), and a Regulatory Cross-Framework Mapping (doc 17), plus a README index.

Risk Assessment and Treatment

The improvement-programme risk register

Clause 10.2 itself requires a risk-based approach to improvement. The improvement programme is also a risk discipline: improvement opportunities are responses to identified risks, and the programme must be defensible against the risk register (Clause 6.1). The Clause 10.2 risk view has three layers:

Layer 1, the underlying BCM risk register (Clause 6.1). Every risk on the register is a candidate improvement trigger: if a risk is rated above the organisation's tolerance, an improvement is the standard treatment. The 10.2 pipeline should be traceable to the 6.1 register: each improvement opportunity ideally references the risk it addresses.

Layer 2, the improvement-programme risk register. The improvement programme itself has risks: funding may be cut; key owners may leave; the planned change may destabilise the system; the verification may be shallow; the standardisation may not persist. A mature 10.2 programme maintains a small register of these programme-level risks and reviews them at the BCM Forum.

Layer 3, the meta-risk of "no improvement". The single biggest 10.2 risk is the absence of improvement: a BCMS that is calcifying without anyone noticing. This is the risk that maturity assessments (§22), benchmarking, and the trend-KPIs of Clause 9.1 are designed to surface. An organisation that cannot point to material, verified improvements over the last cycle is carrying this meta-risk regardless of how clean its documentation looks.

Treating the meta-risk of calcification, the four early-warning signals

A working 10.2 programme watches for four early-warning signals that the BCMS is calcifying:

1. RTO/RPO achievement trend declining. If the proportion of exercises meeting their RTO/RPO targets is falling quarter-on-quarter, the system is losing adequacy. This is a 10.2 signal even before any single exercise becomes an NC.
2. Exercise-scenario stagnation. If the same scenarios are exercised year after year, the exercise programme is no longer stretching the plan. Scenario rotation, scope escalation, and surprise elements are 10.2 improvements to the exercise programme itself.
3. Real-disruption patterns recurring. If real disruptions keep producing the same after-action findings, the 10.2 loop is not closing. The HDFC Bank pattern of repeated outages over two years, followed by RBI restrictions in December 2020, is the textbook example.
4. Documented-information currency declining. If plans, the BIA, the risk register, and the policy are overdue their review cycles, the system is decaying on paper before it is decayed in practice. Plan-currency % (§12) is the leading indicator.

Treatment options for improvement opportunities

An improvement opportunity, once detected, can be treated in five ways. The treatment choice is itself auditable evidence of prioritisation:

The five treatments map onto the Clause 6.1 risk-treatment vocabulary (modify, retain, avoid, share, accept), the same risk discipline applies to the management of improvement.

The improvement opportunity vs the nonconformity, risk-prioritisation interaction

An opportunity and a nonconformity may point to the same underlying gap. The risk-prioritisation question is which path the organisation takes. The general rule:

• If the gap has caused or is causing actual harm, treat it as an NC under 10.1 (the 10.1 path is faster, mandatory, and effectiveness-checked).
• If the gap is potential (could cause harm but has not yet), treat it as an opportunity under 10.2.
• If the gap is both, a real incident and a systemic pattern, run both paths in parallel: 10.1 closes the immediate NC; 10.2 raises the bar to prevent the pattern.

The register's "trigger-type" field (NC vs opportunity) keeps the two clean for audit while letting the BCM team see the unified picture.

Audit and Compliance Checklist

This section lists 28 audit questions an ISO 22301 certification or surveillance auditor is likely to ask about Clause 10.2, with the expected evidence and the red flag for each. Use this as a self-assessment before the audit and as the structure for the audit-evidence checklist in toolkit doc 04.

Governance and policy

Detection and the register

Prioritisation and planning

Implementation and verification

Suitability / adequacy / effectiveness evidence

Benchmarking and external intelligence

Integration and feedback

Metrics and KPIs

This section presents 15 KPIs and KRIs that a working Clause 10.2 programme measures. The full Metrics & KPI Dashboard sits in toolkit doc 11. The discipline: each KPI has a definition, formula, target, frequency, owner, and source.

Process KPIs, the improvement engine

Outcome KPIs, the BCMS dimensions

Maturity & trajectory KPIs

The dashboard

At L3 maturity, a one-page dashboard presented quarterly to the BCM Forum and annually to the management review should show:

• Top row, the three outcome KPIs (RTO, RPO, MBCO attainment) as trend lines over the last 8 quarters.
• Middle row, the process KPIs (intake rate, closure rate, lead time, verified-effective rate) as the engine view.
• Bottom row, maturity progression (current vs target by dimension), benchmark comparison, and the top 5 open improvement opportunities with owner and target date.

The dashboard is the single most-cited 10.2 artefact in a certification audit. A clean, current, honest dashboard is the strongest evidence the programme is alive.

Common Pitfalls / Audit Failures

Thirteen named anti-patterns recur in Clause 10.2 failures. Each has a memorable shorthand, the kind of label a BCM team uses internally to call out the failure mode quickly.

"The frozen certificate"

The organisation earned ISO 22301, framed the certificate, and then stopped improving the BCMS. Surveillance audits pass because the documentation is clean; the calcification is invisible until a real disruption exposes it. The certifier eventually escalates; the regulator may escalate first. Symptom: no material change to the BCMS across two surveillance cycles. Fix: require a defined number of verified improvements per cycle as a programme KPI.

"The single-source register"

The improvement register has entries only from internal audit (or only from exercises). The other five sources (real disruptions, monitoring, management review, benchmarks, change) are absent. Symptom: source-diversity KPI is 1 of 7. Fix: add intake paths for each source; assign BCM Forum members to champion specific sources.

"Everything funded, nothing finished"

The register has 80 open opportunities, none rejected, none deferred, few closed. This is detection without prioritisation, the programme is a backlog, not an engine. Symptom: implementation closure rate <40%; lead time >365 days. Fix: apply the 2×2 method; require documented rationale for fund/defer/reject; freeze intake until the backlog is cleared.

"Verified effective, always"

Every closed improvement is marked "verified effective." This is shallow verification, the team is not honestly measuring outcomes. Symptom: verified-effective rate is 100% with no nuance. Fix: expect 70–85% verified-effective; treat the rest as partial or no-gain and document the re-plan.

"The shallow after-action"

After-action reviews (Clause 8.6) produce lessons that name symptoms but not causes ("the plan was unclear"; "people didn't know their role"). These convert into shallow improvements ("we rewrote the plan"; "we ran an awareness session") that do not address the systemic gap. Symptom: the same lesson appears in successive AARs. Fix: require RCA-grade depth in AARs; escalate repeated lessons as Clause 10.1 NCs.

"The exercise programme that doesn't stretch"

The exercise calendar repeats the same scenarios, the same participants, the same scope year after year. The plan "passes" because it is not being tested against the current reality. Symptom: scenario-stagnation KPI; identical after-action findings across cycles. Fix: rotate scenarios; escalate scope; introduce surprise injects; periodically test against emerging threat patterns.

"The 10.1/10.2 confusion"

NCs and opportunities are mixed in the same register with no trigger-type field, so the audit traceability is muddled. Or worse: NCs are mis-classified as opportunities to escape the rigour of corrective-action effectiveness checks. Symptom: the auditor cannot trace an entry to its trigger. Fix: require trigger-type as a register field; conduct a quarterly classification review.

"The management-review reporting disconnect"

The BCM Forum runs a strong improvement programme, but management review (Clause 9.3) only sees status reports, not trajectory. Top management cannot answer "is our BCMS getting better?" Symptom: management-review minutes lack trajectory discussion. Fix: restructure the management-review pack around the dashboard (§12.4); require a trajectory narrative from the BCM Manager.

"The tooling-as-improvement fallacy"

The organisation buys an enterprise IRM suite and counts the deployment as "the improvement." Underlying BCM discipline is unchanged; the suite is a decoration. Symptom: the biggest entry in the improvement register is "deployed GRC platform"; outcome KPIs (RTO, RPO, MBCO) are unchanged. Fix: separate tooling from improvement; the tool enables the discipline, it does not substitute for it.

"The benchmark-and-forget"

The organisation subscribes to the BCI Horizon Scan, reads the report, files it. No improvement opportunities are entered. Symptom: benchmark library exists; no benchmark-sourced register entries. Fix: require a "what would we improve?" workshop after each benchmark release.

"The undocumented improvement"

Real improvements were made (a plan rewritten, a tool deployed, an exercise redesigned) but the documented information, the risk register, and the objectives were not updated. The improvement is invisible to the next audit. Symptom: improvements exist in practice but not in artefacts. Fix: require §7.6 standardisation as a closure criterion.

"The top-management hands-off"

Top management signed the policy and delegated everything to the BCM Manager. No senior visibility of trajectory; no funding defence at budget cycle; no escalation path for strategic improvements. Symptom: BCM Forum attendees are all individual contributors; no C-suite attendance. Fix: require a named C-suite sponsor with defined engagement; require a quarterly 30-minute sponsor briefing.

"The regulator-as-improvement-engine"

The only improvements the organisation makes are the ones the regulator forces (RBI inspection findings, SEBI show-cause responses, IRDAI compliance-return queries). Between supervisory engagements, the programme stalls. Symptom: most funded improvements trace to regulatory origin; few or none to opportunity. Fix: rebalance, regulatory findings are floor, not ceiling; require proactive benchmarking and external-event learning.

Illustrative Scenario 1: Failure, When the Improvement Engine Stops

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 Indian record on recurring banking outages and supervisory action (notably the HDFC Bank pattern of 2018–2022, where repeated digital-banking outages culminated in RBI restrictions on new digital products and fresh credit cards from 2 December 2020, partially lifted around August 2021 and fully lifted around March 2022). The composite is illustrative; the regulatory pattern is factual.

The organisation

A growing Indian private bank ("the Bank"), ~2,200 employees, ~₹22,000 cr in deposits, digital-first positioning, ISO 22301 certified for the digital channels and core banking. The BCM Manager reported to the CIO; the BCM team had three people. The Bank's last surveillance audit had passed cleanly with no major NCs. The certificate was on the wall of the CIO's office.

What the system looked like on paper (Year 0)

The Bank's BCMS documentation was defensible: a board-approved BCP policy (Clause 5.2), a BIA refreshed every 18 months (Clause 8.2), recovery strategies documented per prioritised activity (Clause 8.3), plans for digital channels and core banking (Clause 8.4), an annual DR failover exercise (Clause 8.5), a management review at the Risk Management Committee of the board (Clause 9.3), and a small NC/CAPA register (Clause 10.1). On paper, every clause was satisfied.

What the system was actually doing, and not doing

The Bank had passed certification by writing the right documents. It had not institutionalised the improvement discipline that keeps those documents alive. Specifically:

• The exercise programme was ritualised. The annual DR failover ran the same scenario with the same people in the same maintenance window. The after-action findings were minor, typically "the runbook step 4 needed a small clarification", and the actions were shallow, typically "the runbook was clarified." Nobody asked whether the scenario still represented the realistic threat surface.
• The BIA was refreshed on a calendar, not on trigger. The Bank had launched a new digital lending product, added a third-party KYC vendor, and migrated the cards-processing platform to a new SaaS, none of these changes triggered a BIA refresh between the 18-month cycles. The BCMS was becoming unsuitable to the Bank as it actually was.
• Real disruptions were treated as operational events, not as improvement inputs. A first digital-channel outage (Year 1) was managed competently as an incident, restoration, customer comms, SLA credits, but the after-action review identified the cause as a one-off. The Bank filed the AAR but did not convert the lessons into a 10.2 improvement. There was no register entry; no prioritisation; no systemic change.
• The NC/CAPA register was the only register. There was no Improvement / Opportunity Register. The concept of an opportunity (as distinct from a nonconformity) was not in the operating vocabulary.
• The management review focused on status, not trajectory. The board RMC received a "BCMS status" pack, exercises done, audits passed, no major NCs, but no trajectory data. No KPI trends. No benchmark comparison. No "are we getting better?" question.

The recurrence (Year 2 and Year 3)

In Year 2, a second digital-channel outage hit during a peak window. Restoration took ~4 hours against an RTO of 2 hours. The AAR found that the recovery script had failed at a step dependent on a middleware service whose hostname had been changed; the change had been processed by change management but not flagged as DR-impacting. The Bank's RCA reached "the runbook was wrong" and "the DR team needs retraining." The corrective action was runbook update + retraining under Clause 10.1. The effectiveness check was a 90-day retest in a narrow scenario.

In Year 3, a third outage, this one during a festival-season peak, affected digital banking for ~6 hours with widespread customer impact. The RCA reached the same conclusion as Year 2 ("the runbook was wrong") plus a new symptom ("the cloud-provider's failover tooling reported 'degraded but recovering' for 23 minutes"). The corrective action was again runbook update + retraining + a promise to "evaluate active-active dual-data-centre architecture."

The supervisory action (Year 3, Q4)

The banking regulator initiated supervisory action modelled on the RBI's 2 December 2020 action against HDFC Bank: 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 cited three things:

1. Recurrence of the same digital-channel recovery failure pattern across three years, the definitive Clause 10.2 (and 10.1) failure signal.
2. Inadequacy of the BCMS to the Bank's actual scale and digital-channel exposure, the BIA was stale, the prioritised activities list did not include the new digital lending product, and the strategy had not been re-evaluated against current threat patterns.
3. Unsuitability of the BCMS to the Bank's actual technology architecture, the Bank had migrated cards processing to a SaaS and added a third-party KYC vendor without updating the dependency map or the supplier-continuity expectations (Clause 8.1).

Why Clause 10.2 specifically failed

The post-supervisory review found that the Bank's BCMS would have passed a paper-only audit indefinitely. What was missing was the engine:

1. No improvement discipline. There was no Improvement / Opportunity Register, no documented prioritisation method, no effectiveness verification of improvements (because there were no improvements to verify). The system was frozen at its certification state.
2. No external-event learning. The BCI Horizon Scan was not read. The regulator's sectoral bulletins were not converted into improvements. The public AIIMS 2022 case did not prompt the Bank to ask "could our backup strategy fail us the same way?"
3. No benchmarking. The Bank had no external comparison. Its exercise results, KPIs, and maturity were never measured against peers or industry data.
4. No trajectory data at management review. The board RMC never asked "are we getting better?" because the question was not in the pack.
5. No improvement ownership. The BCM Manager was operationally overloaded with audit-response work; there was no time, no budget, and no mandate for proactive improvement. The C-suite sponsor had not engaged with the BCM programme since certification.

Impact

• Direct cost: customer SLA credits, refund processing, comms recovery, and the mandated external IT audit, across three years.
• Supervisory-action cost: the digital-product restriction held for ~9–12 months, deferring digital-revenue growth.
• Certification impact: a major NC at the Year-3 surveillance; certification maintained with conditions.
• Reputational impact: media coverage of the supervisory action produced measurable deposit-base stagnation for two quarters.
• Governance cost: the CIO departed; the BCM Manager was reassigned; a Chief Operational Resilience Officer was hired reporting to the CEO; the board RMC instituted a half-yearly trajectory review.

Lessons (Clause 10.2 specific)

• Certification is the start, not the end. A BCMS that does not visibly improve after certification is decaying.
• Real disruptions are the highest-fidelity 10.2 input. Treating them as operational events to be survived, not as improvement opportunities to be converted, guarantees recurrence.
• The exercise programme must stretch. A ritualised annual DR test passes the audit without testing the system.
• Trajectory is a board question. A status report without a trend line lets the board believe "all is well" when it is not.
• The improvement discipline is a capability, not an event. It needs a named owner, a budget, a register, a method, and a cadence. Without all five, the certificate is a date stamp, not a guarantee.

Illustrative Scenario 2: Success, How a Growing SaaS Firm Built the Improvement Engine

Illustrative scenario. Composite drawn from the public record on Indian and global IT-services and SaaS incidents (notably the Cognizant 2015 Chennai-floods response and revenue-guidance reaffirmation; the Cognizant Maze ransomware 2020 SEC-filed $50–70M impact). The composite is illustrative and anonymised; numbers and the named entity are not real.

The organisation

A growing Indian B2B SaaS company ("the Company"), ~700 employees, ₹260 cr ARR, serving Indian BFSI and global enterprise customers from Bengaluru and Hyderabad delivery centres. The Company held ISO 22301 (since Year -2) and ISO 27001 certifications; the BCM Manager also held the ISMS Manager role and reported jointly to the CIO and the CRO. The Company had just survived a real disruption, a 5-hour cloud-region outage that had breached customer SLAs, and the after-action review had surfaced multiple improvement opportunities. The CRO asked the BCM Manager a single question at the management review: "How do we make sure this doesn't happen again, and how do we know we're getting better?"

The trigger (Year 1, Q2)

The cloud-region outage was the wake-up call. The BCM Manager used it to make the case for a 24-month improvement programme. The board RMC approved a defined budget (over 24 months, plus tool licensing) and a named CRO sponsor with quarterly engagement.

What the Company built, the seven-engine improvement programme

The BCM Manager designed the programme around the seven improvement drivers (§2.3) plus the five capabilities (§7.1). The architecture:

1. A single Improvement / Opportunity Register (a growing GRC SaaS module, integrated with the ISMS register) with the §7.2 fields and a trigger-type tag (10.1 NC vs 10.2 opportunity). Migration from the prior Excel-based NCR/CAPA log took 6 weeks.
2. A documented Continual Improvement Procedure (toolkit doc 02 shape) approved by the CRO and reviewed annually.
3. A BCM Forum with named members (BCM Manager, CISO, Head of SRE, Head of Infrastructure, Head of Customer Success, Head of HR, General Counsel) meeting monthly for tactical review and quarterly for strategic prioritisation.
4. A defined prioritisation method, the 2×2 impact-vs-effort matrix with a regulatory-risk overlay and an ROI estimate for high-cost items.
5. A benchmarking cadence, annual review of the BCI Horizon Scan, regulator bulletins (CERT-In, RBI, SEBI, IRDAI as applicable), and published incident case studies (AIIMS 2022, CrowdStrike 2024, Cognizant Maze, Jio September 2024, Change Healthcare 2024), with a "what would we improve?" workshop after each.
6. An effectiveness-verification discipline, every funded improvement had a pre-defined metric and verification method.
7. A trajectory dashboard (§12.4 shape) presented quarterly to the BCM Forum and annually to the board RMC, with explicit "are we getting better?" framing.

The improvement portfolio over 24 months

Across 24 months, the Company logged 92 opportunities, prioritised 34 for implementation, deferred 38 with rationale, rejected 18 with rationale, and escalated 2 to the board as strategic decisions. The 34 implemented improvements fell into six themes:

The effectiveness evidence

The BCM Manager measured the trajectory against the Year-0 baseline:

• RTO achievement in exercises: from 60% meeting target in Year 0 to 95% in Year 2.
• Real-disruption MBCO attainment: from "improvised" in the Year-1 trigger event to "delivered to defined level" in two smaller Year-2 disruptions.
• Average recovery time (real activations): from ~5 hours to ~75 minutes across the two Year-2 events.
• KPI trend: plan-currency % from 68% to 96%; exercise-scenario diversity from 3 distinct scenarios to 11.
• Audit findings: from 6 minor NCs + 2 recommendations in Year 0 to 0 NCs + 3 recommendations in Year 2.
• Maturity progression: from L2 (Repeatable) on the §22 scale at Year 0 to solid L3 (Defined) at Year 2, with two dimensions at L4 (Managed/Measured).
• External recognition: the Company's pre-contract security and continuity questionnaire response time dropped from an average of 17 days to 6 days, with the improvement programme cited as a positive in three customer audits.

The outcome

The CFO's review at 24 months found:

• Programme cost: the 24-month budget plus an over-run on DR infrastructure, spread across the BCM Manager FTE, the GRC platform module, the mass-notification platform, the DR-infrastructure upgrades, and the supplier-clause renegotiations (legal cost).
• Avoided cost: the BCM Manager's model gave a real chance of a repeat of the Year-1 outage within 24 months without the programme; the programme removed most of that exposure.
• Revenue acceleration: 3 enterprise customers cited the BCM improvement programme as a positive factor in contract renewals and expansions.
• Insurance: the Company's cyber-insurance renewal premium rose far less than the market trend for the same period.
• Audit and compliance effort: combined ISO 22301 + ISO 27001 surveillance audits took less effort through the unified register and integrated evidence vault.

Net result: the expected-value and realised benefits exceeded the programme cost several times over, with the residual capability compounding into subsequent cycles.

Lessons (Clause 10.2 specific)

• A real disruption is the most powerful 10.2 catalyst. The board RMC approved the programme because the Year-1 trigger event had made the cost of not improving legible.
• A single register across 10.1 and 10.2 (with trigger-type field) dramatically improves traceability. Audit cost fell; clarity rose.
• Effectiveness verification is the unlock. It is the step that turns "we did things" into "we got better", and gives the board the confidence to keep funding.
• The trajectory dashboard is the most-cited artefact. Internally, externally, regulatorily. A clean dashboard is worth the discipline required to produce it.
• ROI is measurable. The "soft" benefits of resilience become defensible numbers when the improvement programme is run with verification discipline.
• The CRO-sponsor engagement is non-negotiable. A named C-suite sponsor with quarterly engagement converted the BCM programme from an operational responsibility into a strategic capability.

Multi-Framework Mapping

This section maps Clause 10.2 to the most-cited adjacent frameworks and regulations. The control numbers are real and verified against the source instruments cited in §24. Use this as the basis for a combined audit or for satisfying multiple regulators with one improvement programme.

ISO family

US frameworks

EU and global prudential

Indian regulatory

The combined-improvement-programme value

The pattern across the table: every major framework and every Indian regulator now expects the same ongoing-improvement discipline that Clause 10.2 codifies. A growing Indian company that runs one defensible 10.2 programme satisfies all of them simultaneously, and produces one set of evidence (register, prioritisation, planned changes, effectiveness verification, trajectory dashboard) that maps to all of them. This is the highest-use compliance investment a growing company can make.

Implementation Roadmap

This 30/90/180/365-day roadmap is calibrated for a growing Indian company at the Singahi scale (250–2,000 employees) starting from L1–L2 maturity and targeting solid L3 within 12 months. The full Implementation Roadmap is in toolkit doc 05.

First 30 days, establish the discipline

Week 1–2: Appoint, scope, and quick-win

• Name the BCM Manager as the improvement-programme owner (or confirm the existing BCM Manager has the bandwidth; if not, reallocate or augment).
• Identify the named C-suite sponsor (typically CRO, COO, or CIO); confirm 30-minute quarterly engagement.
• Stand up the Improvement / Opportunity Register (a structured spreadsheet is sufficient for the first 30 days; growing GRC SaaS module later).

Week 2–3: Retro-load the last 12 months

• Mine the last 12 months of exercise AARs, real-disruption reviews, internal-audit reports, external-audit findings, customer-complaint trends, and management-review minutes.
• Log every meaningful opportunity into the register with the §7.2 fields; expect 15–40 retro-loaded entries.
• Tag each with source, theme, and a tentative priority.

Week 3–4: First BCM Forum

• Convene the BCM Forum (named members: BCM Manager, CISO/Security, SRE/Infrastructure, HR, Customer Success, General Counsel).
• Walk the retro-loaded register; agree the prioritisation method (start with the 2×2 + risk overlay).
• Fund the first 3–5 quick wins; assign owners and target dates; defer or reject the rest with rationale.

Days 31–90, systematise and run the first cycle

Month 2: Document the procedure

• Draft the Continual Improvement Procedure (toolkit doc 02 shape); route for review.
• Define the effectiveness-verification discipline (every funded improvement has a pre-defined metric and verification method).
• Define the BCM Forum cadence (monthly tactical; quarterly strategic).

Month 2–3: Add the missing detection sources

• Add intake paths for the sources missing from the register (typically: monitoring/KPIs, benchmarks, change events).
• Subscribe to the BCI Horizon Scan (or equivalent); read the latest issue; convert into opportunities.
• Set up a quarterly review of regulator bulletins (CERT-In, RBI, SEBI, IRDAI as applicable) and published incident case studies.

Month 3: First prioritisation session; first effectiveness verifications

• Run the first formal prioritisation session at the BCM Forum; document funding/deferral/rejection decisions.
• Complete effectiveness verification for the first 3–5 quick wins funded in Day 1–30; record results honestly (including partial or no-gain).
• Update relevant documented information (plans, BIA, risk register, objectives) for verified-effective improvements.

Days 91–180, institutionalise

Month 4–5: Move to platform (if ready)

• If register volume or audit-evidence demands justify it, migrate to a growing GRC SaaS module or a structured SharePoint/Google Workspace list with version history.
• Maintain the trigger-type field (10.1 vs 10.2) throughout.

Month 4–6: Build the trajectory dashboard

• Define the §12.4 dashboard (top: RTO/RPO/MBCO trends; middle: process KPIs; bottom: maturity, benchmarks, top 5 open items).
• Back-cast the KPIs to the last 8 quarters where data exists; baseline where it does not.
• Begin quarterly BCM Forum reporting against the dashboard.

Month 6: First management-review trajectory report

• Present the dashboard and the trajectory narrative to the management review (Clause 9.3) and the board RMC.
• Frame the report around the suitability / adequacy / effectiveness dimensions.

Days 181–365, embed and verify

Month 7–9: First surveillance audit cycle

• Run the audit-evidence checklist (toolkit doc 04) as a self-assessment; remediate gaps.
• Walk the certifier through the register, the prioritisation, the planned changes, the effectiveness verification, and the trajectory dashboard.
• Use surveillance findings as further 10.2 inputs.

Month 7–12: Scale the programme

• Begin benchmarking against at least one external dataset; convert findings into opportunities.
• Begin cross-functional integration with the ISMS, the enterprise risk register, and the internal-audit plan.
• Initiate 1–2 strategic multi-quarter improvements (e.g., DR-architecture upgrade, supplier-continuity programme).

Month 12: Annual review

• Refresh the Continual Improvement Policy and Procedure.
• Conduct a maturity self-assessment (§22); set the next 12-month trajectory targets.
• Re-baseline KPIs; confirm or reset targets.

The 24-month horizon, toward L4

A 12-month L3 programme is the certification floor. The L4 progression (over 12–24 additional months) adds:

• Metric-driven improvement with statistical KPI/KRI trends and predictive indicators.
• Multi-dataset benchmarking and industry-survey participation.
• An annual improvement roadmap approved by top management.
• ROI estimation for major improvements.
• Deeper cross-functional integration with operational risk and security.
• 30–80 implemented improvements per year plus 1–3 strategic programmes.

FAQ

Q1. What is the single biggest difference between Clause 10.1 and Clause 10.2?

The trigger. Clause 10.1 is reactive, it triggers when a nonconformity is detected (something has fallen short of a requirement). Clause 10.2 is proactive and opportunistic, it triggers whenever the organisation sees a chance to make the BCMS better, even if nothing has gone wrong. The same artefact types (register, prioritisation, planned change, effectiveness verification) appear in both; the difference is what puts an entry into the register.

Q2. Can we run one register for 10.1 and 10.2?

Yes, and most well-run combined ISMS+BCMS shops do. The key is a "trigger-type" field that attributes each entry to its source (nonconformity for 10.1, opportunity for 10.2). This preserves audit traceability while letting the BCM team see the unified picture.

Q3. How many improvement opportunities should we expect to log per year?

At the Singahi scale (250–2,000 employees), a working programme logs 20–80 opportunities per year. Fewer than 10 suggests detection is weak (typically only audit findings are captured). More than 100 suggests detection is healthy but prioritisation may be overloaded.

Q4. Our certifier did not raise any Clause 10.2 findings last surveillance. Does that mean our programme is fine?

Not necessarily. Certifiers tend to focus on the artefacts they can trace end-to-end in a sample, a register, a planned change, an effectiveness verification. A BCMS that produces those artefacts but does not materially change year over year can still pass surveillance while calcifying. Use the §13 anti-patterns list and the §22 maturity model as your own honest self-assessment, not just the certifier's verdict.

Q5. Do we have to use a BCM/GRC platform to satisfy Clause 10.2?

No. A structured spreadsheet with the §7.2 fields, a version-controlled SharePoint/Google Workspace document set, and disciplined cadence satisfy 10.2 at L1–L3. Platform investment is justified when register volume, audit-evidence demands, multi-standard integration, or regulator-facing reporting requirements cross thresholds that office-suite tools no longer support.

Q6. How do we handle improvements that overlap with our ISMS (ISO 27001) programme?

Run a single register with framework tags. Most modern GRC SaaS modules and a well-structured spreadsheet support tagging. Each improvement gets one or more tags (BCMS, ISMS, etc.); the same evidence satisfies both standards. Combined surveillance audits typically accept this approach.

Q7. How do we satisfy the SEBI CSCRF "Evolve" goal with our Clause 10.2 programme?

Map the §16.4 SEBI CSCRF row onto your register by adding an "Evolve" tag to each improvement that originated from an incident, exercise, or audit and that is reportable under CSCRF. The CSCRF annual reporting then draws from the same register that satisfies 10.2. This avoids running two parallel improvement programmes.

Q8. Our BCMS documentation is clean but we have not changed anything in 18 months. Are we at risk?

Yes, this is the §13.1 "frozen certificate" anti-pattern. The certifier may not flag it at surveillance, but the next real disruption will expose it, and the regulator (RBI/SEBI/IRDAI/CERT-In as applicable) will treat it as a systemic failure if it does. Begin retro-loading the last 12 months of opportunities (§17.1) this week.

Q9. How do we benchmark our BCMS if we are a private company with no public peers?

Use the BCI Horizon Scan as the canonical external dataset (published annually, sector and region cuts available). Read the public record of major incidents (for AIIMS 2022, public reporting and the government's reply to Parliament; for Cognizant Maze 2020, its SEC filings). Subscribe to your regulator's sector bulletins (CERT-In, RBI, SEBI, IRDAI). Engage with a consultancy like Singahi for an external maturity assessment against an industry dataset.

Q10. What is the right KPI to lead with to the board RMC?

The trajectory dashboard (§12.4) lead metric should be the RTO achievement trend for Tier-1 prioritised activities, year over year. It is the single number that most cleanly answers "are we getting better?" in language a board understands. Pair it with the implementation closure rate from the 10.2 programme for the engine view.

Q11. How is DPDP 2023 affecting Clause 10.2?

The DPDP Act's Section 8(5) requires reasonable security safeguards against a personal data breach, and loss of availability counts as a breach. This converts continuity of personal-data handling into a regulator-facing obligation with penalties up to ₹250 crore for safeguard failure. A growing Indian company that is a Data Fiduciary must now run its Clause 10.2 programme with the understanding that improvements (or the absence of them) to availability of personal-data-handling systems are statutory matters, not just internal management-system matters.

Q12. What if our top-management team does not engage?

This is the §13.12 "top-management hands-off" anti-pattern and one of the most common reasons 10.2 programmes fail. The fix is structural: require a named C-suite sponsor with defined engagement (30 minutes quarterly is enough); put the trajectory dashboard on the management-review (Clause 9.3) agenda as a standing item; use the board's RMC (under SEBI LODR Reg. 21 for listed companies, or voluntarily for unlisted) as the accountability forum. If senior engagement cannot be obtained, the BCM Manager should escalate the risk formally, in writing, to the audit committee.

Q13. How often should we exercise to keep the 10.2 programme fed?

The exercise programme (Clause 8.5) is the richest 10.2 input. At Singahi scale, expect to run 4–8 exercises per year (mix of tabletop, component, simulation, and at least one full-failover or near-full-failover per Tier-1 activity). Each exercise should produce 3–10 opportunities for the register. The exercise calendar itself should be improved annually (scenario rotation, scope escalation, surprise injects).

Q14. Is Kaizen the same as Clause 10.2?

Structurally, yes. Kaizen is the disciplined practice of small, frequent, evidence-led improvements owned by the people closest to the work. Clause 10.2 is the management-system codification of the same idea. An organisation that has institutionalised Kaizen in any function (engineering retrospectives, safety briefings, quality circles) has the cultural raw material for a strong 10.2 programme; the work is to extend it to the BCM domain.

Q15. How do we avoid the "tooling-as-improvement" trap (§13.9)?

Diagnose before you buy. Define the discipline (procedure, register, cadence, prioritisation, verification) in office-suite tools first. Run it for at least two quarters. Only then evaluate platforms against the actual bottlenecks the discipline has surfaced. If the bottleneck is "we cannot maintain version history across multiple editors" or "we cannot produce the dashboard from spreadsheet data without manual effort", a platform helps. If the bottleneck is "we do not have time to run the programme", a platform will not fix it.

Industry-Specific Requirements

BFSI, banks, NBFCs, payment system operators

BFSI is the most regulator-intensive sector for Clause 10.2 in India. The combination of RBI Master Direction on IT Governance (effective 1 April 2024), the 2016 RBI Cyber Security Framework, the SEBI CSCRF (where the entity is also SEBI-regulated), and the DPDP Act creates overlapping improvement obligations that the BCMS must satisfy simultaneously.

Distinctive BFSI angles:

• Supervisory findings as the dominant 10.2 input. RBI inspection findings, RBI-imposed external-audit recommendations, and SEBI inspection findings all flow into the improvement register. The board RMC reviews closure trajectory half-yearly.
• The HDFC pattern as the cautionary tale. Recurring digital-channel outages with supervisory action is the canonical Clause 10.2 failure in Indian BFSI. Boards and CROs treat recurrence as the single most damaging signal.
• Cyber Crisis Management Plan (CCMP) improvement cycle. The 2016 framework requires board-reviewed CCMP; cyber drills feed the 10.2 pipeline.
• Outsourcing-continuity improvement. The RBI Master Direction on Outsourcing of IT Services (10 April 2023) requires outsourcer/cloud BCP-DR to inherit the RE's standards, recurring 10.2 trigger as the outsourced estate evolves.
• Sector benchmarks. RBI-published sector data, Indian Banks' Association guidance, and CERT-In advisories supplement the BCI Horizon Scan.

Capital markets, MIIs, brokers, AMCs

SEBI's layered regime (CSCRF 2024 on top of vertical MII BCP/DR circulars) makes Clause 10.2 regulator-facing.

Distinctive capital-markets angles:

• The "Evolve" goal as regulatory 10.2. SEBI CSCRF's sixth operational function is the regulatory restatement of 10.2. Improvement reporting is mandatory.
• MII BCP/DR improvement reporting. The 2021 MII circular (SEBI/HO/MRD1/DTCS/CIR/P/2021/33) requires MIIs to report improvements implemented to prevent recurrence, a direct 10.2 obligation with regulator visibility.
• Near Site + DRS architecture as ongoing adequacy subject. RTO/RPO targets (45 minutes and 15 minutes for critical MII systems) and live-failover drill cadence are recurring 10.2 triggers.
• TLPT-style testing. Where applicable, threat-led penetration testing (DORA Article 26 for EU-exposed entities; SEBI CSCRF equivalents for Indian MIIs) produces a stream of high-fidelity 10.2 inputs.

Insurance

IRDAI Information and Cyber Security Guidelines, 2023 (24 April 2023) is the marquee instrument; annual compliance return within 90 days of FY-end is structurally a 10.2 trend report to the regulator.

Distinctive insurance angles:

• Board-approved Information & Cyber Security Policy including BCP/DR, annual refresh and improvement trajectory are examinable.
• 180-day log retention aligned with CERT-In, log-retention maturity is a 10.2 dimension.
• DR drills mandatory; results feed 10.2.
• ICT outsourcing continuity oversight, recurring 10.2 trigger as the outsourced estate evolves.
• Policyholder-data locality, improvements to data-locality controls are 10.2 obligations under both IRDAI guidelines and DPDP.

Healthcare

Healthcare is the sector where the patient-safety dimension of "effectiveness" is most legible. AIIMS Delhi ransomware (23 November 2022) is the cautionary tale.

Distinctive healthcare angles:

• Clinical-fallback improvement. The AIIMS lesson, paper-mode fallback for OPD/admissions/billing/labs must be tested, not assumed, drives a recurring 10.2 theme.
• Offline/immutable backups. The single biggest healthcare-sector 10.2 improvement since 2022 is the move from online-only backups to immutable, air-gapped, and offline copies.
• Patient-safety as effectiveness metric. Real-disruption MBCO in clinical terms (e.g., "operations continued at reduced capacity"; "no patient-safety event attributed to the disruption") is the highest-stakes effectiveness measure.
• Regulator landscape. National Medical Commission; state health authorities; NDMA where hospital is part of disaster-response; DPDP for patient-data availability.

IT/ITeS & SaaS

The B2B SaaS and IT-services sector faces the most commercially-legible 10.2 pressure: customers' security questionnaires, audit rights, and SLA-breach remediation clauses all turn resilience into a sales-cycle issue.

Distinctive IT/ITeS angles:

• Customer-driven 10.2. Customer security reviews, contracted improvement commitments, and SLA-breach remediation plans are dominant 10.2 inputs.
• Supply-chain 10.2. Vendor-pivot incidents (Wipro 2019 phishing; Infosys McCamish 2023; SITA 2021 affecting Air India) drive recurring supplier-continuity improvements.
• Multi-region continuity. Cloud-region failover, multi-AZ architecture, and DR-as-a-Service from AWS/Azure/GCP are recurring 10.2 outputs.
• Combined ISMS+BCMS improvement. Most growing SaaS firms hold both ISO 27001 and ISO 22301, a single improvement register with framework tags is the standard pattern.

Manufacturing & pharma (especially MAH)

The manufacturing and pharma sectors face a distinctive 10.2 obligation: OT/IT segmentation, process-safety continuity, and environmental-disaster preparedness.

Distinctive manufacturing/pharma angles:

• LG Polymers Vizag (7 May 2020) as cautionary tale. Styrene gas leak during COVID lockdown; 12–13 fatalities; NGT interim penalty ₹50 cr. Un-improved process-safety controls are continuity failures.
• OT/IT segmentation as recurring 10.2 theme. Sun Pharmaceutical (2023) publicly confirmed ransomware and warned of revenue hit, the segmentation gap is the canonical 10.2 improvement.
• NGT-driven environmental NCs. Industrial-MAH continuity under NDMA Chemical Disaster Guidelines 2007 creates recurring 10.2 triggers.
• Production-stoppage as containment. For pharma/mfg, the decision to stop production during a ransomware containment IS a continuity decision, pre-staging isolated OT segments and validated backups is the 10.2 improvement.

Government, PSUs, CPSEs

Government and public-sector entities face CAG/CVC findings, NDMA Disaster Management Plan templates, and Right-to-Information exposure.

Distinctive government angles:

• NDMA DMP template institutionalises the "Recovery & Reconstruction" and "Capacity Building" phases, structural restatement of 10.2 for Indian government.
• CAG/CVC findings as 10.2 inputs alongside internal audit.
• RTI exposure. Un-improved findings can be RTI-subject; the discipline of demonstrable improvement is reinforced by public accountability.

Airlines & transport

DGCA surveillance and the SpiceJet 2022 schedule cap are the cautionary tales.

Distinctive aviation/transport angles:

• DGCA enhanced surveillance as 10.2 escalation. The 27 July 2022 DGCA order capping SpiceJet to 50% of approved Summer Schedule flights for 8 weeks, extended, with the airline placed under enhanced surveillance again in 2024: recurrence after a regulator's intervention is the signal Clause 10.2 is meant to prevent.
• Asset-integrity under-resourcing as continuity failure. The Go First collapse (NCLT filing 2 May 2023; refund liability ₹597 cr to ~15.5 lakh passengers) is the supply-chain-concentration case: for an airline, engine availability IS the business.
• Refund-liability continuity. Customer-refund processing during operational disruption is a BC procedure that itself requires 10.2 improvement.

Maturity Model

This five-level maturity model is calibrated for growing Indian companies. It is the model used in §17 (roadmap) and §12.3 (KPI 14, maturity progression). The INR ranges are indicative annual run-cost of the BCM continual-improvement programme at each level (fully loaded: people + tooling + benchmarks + training), not the cost of moving from one level to the next.

Level 1, Initial / Ad-hoc

Characteristics. No documented improvement procedure. No register; opportunities are handled in email or in the BCM Manager's head. Improvements happen reactively and episodically. The BCMS is recognisably the one that was certified. Real-disruption lessons are not converted into systemic change.

Typical resourcing. Essentially no dedicated spend.

Detection signals. Register does not exist or is a single emailed list; no defined cadence; no prioritisation method; no effectiveness verification; no benchmarking.

Audit posture. Major Clause 10.2 NC at surveillance; certificate at risk.

Next-step move. Stand up the register, run the first 30-day quick-win (§17.1).

Level 2, Repeatable / Intuitive

Characteristics. An informal register exists (typically a spreadsheet). Some opportunities are logged, mostly from exercises and audits. BCM Forum meets irregularly. Prioritisation is intuitive ("we know what matters"). Effectiveness verification is occasional. Benchmarking is absent. Some real improvements happen, but they are person-dependent.

Typical resourcing. A part-time BCM Manager slice; office-suite tooling; minimal benchmarks.

Detection signals. Register exists but source-diversity is 1–2 of 7; closure rate is opaque; effectiveness verification is patchy; no trajectory dashboard.

Audit posture. Minor Clause 10.2 findings at surveillance; some 10.2 evidence but not consistent.

Next-step move. Document the procedure (§9.2); add detection sources (§7.7); define the prioritisation method.

Level 3, Defined (the certification floor)

Characteristics. Documented Continual Improvement Procedure. Single Improvement / Opportunity Register with the §7.2 fields, ideally in a growing GRC SaaS module or structured SharePoint/Google Workspace list. BCM Forum meets monthly tactical, quarterly strategic. Documented 2×2 + risk overlay prioritisation. Effectiveness verification at 30/60/90 days. Annual benchmarking. Trajectory dashboard reported to management review and board RMC. Integration with 9.1 KPIs, 9.3 management review, and 6.1 risk register. Trigger-type field for 10.1 vs 10.2.

Typical resourcing. A full-time or near-full-time BCM Manager; a growing GRC SaaS module; a horizon-scanning subscription; an annual external maturity assessment.

Detection signals. Source-diversity ≥5 of 7; closure rate ≥80%; effectiveness verification ≥95%; verified-effective rate 70–85%; trajectory dashboard live; management review discusses trajectory.

Audit posture. Strong Clause 10.2 evidence; surveillance passes cleanly.

Next-step move. Begin metric-driven improvement with statistical KPI/KRI trends; add multi-dataset benchmarking; initiate 1–2 strategic multi-quarter improvements.

Level 4, Managed / Measured

Characteristics. Metric-driven improvement. Statistical KPI/KRI trends with control charts. Predictive indicators that trigger improvements before any NC is detected. Multi-dataset benchmarking. Industry-survey participation. Annual improvement roadmap approved by top management. 30–80 implemented improvements per year. ROI estimation for major improvements. Cross-functional integration with security, quality, and operational risk. 1–3 strategic multi-quarter programmes in flight.

Typical resourcing. A BCM Manager plus 1–2 analysts; enterprise or BCM-specialist SaaS; multiple benchmarks; cross-functional programme costs.

Detection signals. Statistical KPI/KRI control charts; predictive KRIs triggering pre-emptive improvements; ROI on major improvements; cross-functional programme governance.

Audit posture. Strong Clause 10.2 evidence with quantitative rigour; surveillance findings rare.

Next-step move. Embed improvement in operating culture; cross-functional single pipeline; industry-leader benchmarking; consider contributions back to the discipline (working groups, publications).

Level 5, Optimising

Characteristics. Improvement embedded in the operating culture: every team runs short-cycle retrospectives; BCM is part of how work is done, not a separate programme. Cross-functional improvement engine spanning BCM, security, SRE, quality, safety, and operational risk, with a single pipeline. Industry-leader benchmarking; participation in regulator and industry working groups; published contributions. Annual external maturity assessment; trajectory reported in board and stakeholder reporting.

Typical resourcing. A BCM Centre of Excellence; an enterprise IRM suite; a cross-functional programme; multiple benchmarks; published contributions.

Detection signals. Predictive KRIs; cross-functional single pipeline; industry-leading benchmarks; published thought leadership; trajectory publicly reportable.

Audit posture. Strong Clause 10.2 evidence with quantitative rigour and a sustained trajectory; the certifier uses the programme as a positive exemplar.

Sustaining move. Avoid complacency. L5 organisations are at risk of believing their own trajectory; the discipline of external challenge (independent maturity assessment, regulator engagement, public reporting) keeps the engine honest.

Maturity progression expectations

A growing Indian company moving from L1 to solid L3 typically takes 12–18 months with focused effort. L3 to L4 takes a further 12–24 months. L4 to L5 takes a further 24–36 months. The progression is not uniform across dimensions, an organisation may reach L4 on exercise-programme improvement while still at L2 on benchmarking. The §22.1 sub-dimensions (procedure, register, prioritisation, implementation, verification, standardisation, integration, benchmarking, culture) should be assessed separately.

Emerging Trends

Seven emerging trends are reshaping Clause 10.2 practice over the 2025–2028 horizon. Growing Indian companies that anticipate these now will lead their sectors; those that ignore them will find them in the next supervisory cycle.

Operational resilience supersedes business continuity

The global prudential shift (DORA in the EU from 17 January 2025; APRA CPS 230 in Australia from 1 July 2025; UK PRA/FCA operational-resilience policy; HKMA OR-2 since 31 May 2022; MAS TRM) reframes continuity from "recover from disruption" to "maintain critical operations within tolerance through severe disruption." The implication for 10.2: improvement is no longer measured only by RTO/RPO achievement but by impact-tolerance attainment, did the organisation keep the critical operation within its tolerance through the disruption? Indian regulators are aligning: SEBI CSCRF (2024), the RBI Master Direction on IT Governance (2023), and IRDAI Guidelines (2023) all move in this direction.

Climate change enters the BCMS (ISO 22301 Amendment 1:2024)

Amendment 1:2024 to ISO 22301 adds climate change to Clauses 4.1 and 4.2 (4.1: determine whether climate change is a relevant issue; 4.2: interested parties can have climate-related requirements). The 10.2 implication: organisations that find climate change relevant must improve their BCMS to address climate-related disruption as an ongoing adequacy question, not a one-off context entry. Indian organisations with climate-exposed sites (coastal Andhra/Tamil Nadu; flood-prone Assam/Bihar; heatwave-exposed North India; cyclone-exposed East coast) have a specific 10.2 obligation to keep climate-disruption scenarios current in their exercise programme and their strategy.

AI-enabled disruption and AI-enabled defence

Generative AI is reshaping both sides of the BCM equation. On the threat side: AI-enabled social engineering, deepfake-driven CEO fraud, automated attack tooling, and AI-augmented ransomware deployment are now first-order BCM risks. On the defence side: AI-augmented monitoring, predictive KRIs, automated playbooks, and AI-assisted exercise injects are emerging improvement opportunities. A working 10.2 programme treats AI as both: a threat to keep current against, and a capability to selectively improve with.

Concentration-risk and third-party resilience as first-class 10.2 themes

The CrowdStrike 2024 global outage (a single content-update grounding airlines, healthcare, and financial services worldwide), the Change Healthcare 2024 ransomware (a single payment-processor crippling US healthcare billing), and the CDK Global 2024 ransomware (a single SaaS backbone crippling US auto dealerships for weeks) made concentration risk a board-level BCM issue. The 10.2 implication: third-party and SaaS concentration must be a recurring improvement theme, concentration-risk mapping, multi-vendor strategies, exit-plan testing, and contractually-mandated continuity commitments. Indian firms depending on global SaaS (productivity suites, cloud platforms, CRM/identity providers) face the same risk and the same 10.2 obligation.

Quantum-readiness and crypto-agility (horizon: 5–10 years)

The long-term shift to post-quantum cryptography (NIST PQC standards published 2024) creates a 10.2 obligation to keep crypto-agility in the BCM roadmap. Backups encrypted with today's algorithms may be vulnerable to "harvest now, decrypt later" attacks. For growing Indian companies in regulated sectors (especially BFSI and government contractors), crypto-agility is emerging as a multi-year 10.2 programme.

Cyber-insurance pricing as a 10.2 input

Cyber-insurance underwriters increasingly price in the improvement discipline of the organisation, documented BCMS, tested DR, immutable backups, MFA everywhere, segmented OT, and (now) a demonstrable 10.2 trajectory. A growing Indian company with a strong 10.2 programme is materially more insurable at materially lower premium. This converts 10.2 from cost to revenue (via reduced premium), a board-legible value story.

Public reporting of operational resilience

Listed-company disclosure regimes (SEBI LODR Business Responsibility and Sustainability Reporting, BRSR, for top-listed Indian companies; SEC cybersecurity disclosure for US-listed; EU DORA public-register reporting for financial entities) are making operational-resilience posture public. A documented 10.2 trajectory is increasingly a disclosure-grade asset; its absence is a disclosure-grade liability. Indian companies pursuing IPO or already listed should treat their 10.2 programme as part of the disclosure posture, not only the compliance posture.

References and Further Reading

The following Tier-1 sources underpin this guide. They are the primary instruments, regulations, and datasets cited in §1–23. Where an instrument is a regulation, the issuing body's official domain is the canonical source; the publication reference is provided so the reader can verify directly.

The ISO 223xx family

• ISO 22301:2019 + Amendment 1:2024, Security and resilience, Business continuity management systems, Requirements. International Organization for Standardization.
• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301.
• ISO 22300:2021, Security and resilience, Vocabulary (3rd ed.; verify whether a 2025 edition has published on iso.org/standard/77008.html before citing a year).
• ISO/TS 22317:2021, Security and resilience, Business continuity management systems, Guidelines for business impact analysis (2nd ed.; supersedes 2015).
• ISO/TS 22331:2018, Security and resilience, Business continuity management systems, Guidelines for business continuity strategy.
• ISO/TS 22318:2021, Security and resilience, Business continuity management systems, Guidelines for supply chain continuity (2nd ed.; supersedes 2015).
• ISO/TS 22330, Security and resilience, Business continuity management systems, Guidelines for people resilience.
• ISO 22316, Security and resilience, Organizational resilience, Principles and attributes.
• ISO/IEC 17021-1:2015 and IAF Mandatory Documents, the rule-set governing accredited ISO 22301 certification audits.

Global frameworks

• NIST SP 800-34 Rev 1 (May 2010), Contingency Planning Guide for Federal Information Systems. DOI 10.6028/NIST.SP.800-34r1.
• NIST SP 800-160 Vol 1 (Nov 2016) and Vol 2 Rev 1 (Sept 2021), systems security engineering and cyber-resilience techniques.
• NIST CSF 2.0 (NIST.CSWP.29, 26 Feb 2024), Recover function (RC.RP, RC.CO), with improvement now under Identify (ID.IM) and Govern function.
• FFIEC IT Examination Handbook, Business Continuity Management Booklet (Nov 2019; OCC Bulletin 2019-57; FRB SR 19-13; FDIC FIL-71-2019).
• FEMA FCD-1 (17 Jan 2017) and FCD-2 (13 Jun 2017) under PPD-40.
• DORA, Regulation (EU) 2022/2554 of 14 Dec 2022 on digital operational resilience for the financial sector; applies 17 Jan 2025 (Art 64).
• APRA CPS 230, Operational Risk Management; effective 1 July 2025; para 37 (tolerance levels), para 42 (annual BCM exercise), para 45 (internal audit review).
• MAS TRM Guidelines (18 Jan 2021); MAS Guidelines on Business Continuity Management.
• HKMA SPM TM-G-2 (rev. 31 May 2022), Business Continuity Planning; OR-2 (31 May 2022), Operational Resilience; SA-2, Outsourcing.
• UK Civil Contingencies Act 2004 (c.36) and statutory guidance Emergency Preparedness.

Indian regulatory instruments

• RBI Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (issued 7 Nov 2023; effective 1 Apr 2024; RBI portal id 12562).
• RBI Cyber Security Framework in Banks (2 Jun 2016).
• RBI Master Direction on Outsourcing of Information Technology Services (10 Apr 2023).
• RBI graded Cyber Security Framework for Primary (Urban) Cooperative Banks (31 Dec 2019).
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF), circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 (20 Aug 2024).
• SEBI BCP/DR for MIIs, circular SEBI/HO/MRD1/DTCS/CIR/P/2021/33 (22 Mar 2021).
• IRDAI Information and Cyber Security Guidelines, 2023 (24 Apr 2023).
• CERT-In Directions under Section 70B(6) of the IT Act, No. 20(3)/2022-CERT-In (28 Apr 2022).
• Digital Personal Data Protection Act, 2023 (Act 22 of 2023; enacted 11 Aug 2023) and DPDP Rules, 2025.
• Disaster Management Act, 2005 (Act 53 of 2005); NDMA Guidelines, Chemical Disasters (Industrial) 2007; Preparation of DMPs; National Policy on Disaster Management 2009.
• Companies Act, 2013, Section 134(3)(n) and Section 177; SEBI LODR Regulation 21 (Risk Management Committee).
• Information Technology Act, 2000, Sections 43, 65, 66, 70, 70A, 70B, 72, 84A.

Practitioner and data-report sources (citable bodies and datasets)

• BCI Horizon Scan 2025 ("Complex and Interconnected Risk") and BCI Horizon Scan 2024, the most-citable BCM industry datasets, published by the Business Continuity Institute.
• DRI International, accredited BCM certification body and professional-development organisation (drii.org).
• Cited primary-source incident cases: AIIMS Delhi 2022 ransomware (public reporting and the government's reply to Parliament); HDFC Bank 2020 RBI action (RBI order); Yes Bank 2020 moratorium (RBI press releases and the Yes Bank Reconstruction Scheme, 2020); Cognizant Maze 2020 (SEC 10-Q / 10-K filed disclosure, Q2 2020 impact US$50–70M); Chennai floods 2015 (Cognizant official statement, FY2015 revenue guidance reaffirmed at ≥US$12.41bn); LG Polymers Visakhapatnam 2020 (NGT interim penalty ₹50 cr; OA 73/2020); Go First 2023 NCLT filing (refund liability ₹597 cr to ~15.5 lakh passengers); SpiceJet 2022 DGCA order (50% of approved Summer Schedule for 8 weeks); Air India / SITA 2021 data breach (~4.5m customers, Reuters reporting); Jio 17 Sep 2024 data-centre fire (Reuters reporting); Cognizant Chennai-floods 2015 (company statement); NPCI/UPI outage patterns (Oct 2020, Jan 2022, 12 Apr 2025).

Accredited certification bodies (citable as certification-process references)

• BSI Group (bsigroup.com), DNV (dnv.com), SGS (sgs.com), TÜV (various institutes), Bureau Veritas (bureauveritas.com), Intertek (intertek.com), NQA (nqa.com). Note: "BSI" the German federal cybersecurity authority (bsi.bund.de) is a different organisation from BSI Group the certification body; do not conflate.

A note on the authoring discipline

This guide paraphrases ISO 22301:2019 Clause 10.2 throughout; the official clause text is copyrighted by ISO and is not reproduced here. Regulatory references point to the issuing body's published instruments; reconfirm circular numbers and dates on the official page before quoting them in a contract or regulatory submission. Tool and platform references are category-level. The illustrative scenarios in §14 and §15 are composites, labelled as such, and are not assertions about any named organisation.

End of guide.