ISO 22301 Clause 6.1: Actions to Address Risks and Opportunities

Quick Reference (60 Seconds)

If you only read one thing: Clause 6.1 is where the BCMS stops being a documentation exercise and becomes a thinking system. A 6.1-conformant BCMS is one in which the organisation has decided in advance what could go wrong with the BCMS itself, what could go better than planned, how it will decide which risks to treat and which opportunities to chase, who owns each decision, when each decision will be revisited, and how the residual risk position flows to top management. The certification auditor will examine this discipline ruthlessly, and so will a regulator after a real disruption, when an incident strikes, the second question after "who is in charge?" is always "did you know this could happen, and what had you decided about it?" Get 6.1 wrong and however strong the policy, the BIA, and the plans, the BCMS will fail the standard's outcomes test. Get it right and every other clause becomes evidence-based because the planning logic is defensible.

What the Standard Actually Requires

The paraphrased requirement

ISO 22301 Clause 6.1 asks organizations to plan how to handle the risks and opportunities that could affect the BCMS achieving its outcomes. The paraphrase compresses a great deal of architectural work into one sentence. Plan is the operative verb. The standard expects the organisation to think ahead, document the thinking, and act on the documentation, not to react after the fact and call the reaction a plan. Risks and opportunities is a paired construction: the standard treats positive and negative uncertainty symmetrically. A BCMS that is excellent at killing risks but blind to opportunities is conformant on the surface and under-performing in substance. Affect the BCMS achieving its outcomes is the scope test. The outcomes of the BCMS, as set out in Clause 1 of the standard and shaped by Clause 4 context, are the continuity of prioritised activities, the protection of interested-party value, and the fulfilment of legal, contractual, and regulatory obligations. Risks that affect those outcomes through the BCMS are 6.1 risks; risks to the underlying business activities from disruptive events are Clause 8.2 risks.

The standard's deliberate use of both risks and opportunities is important. Many Indian BCMSs treat 6.1 as a risk-only clause; that produces a register full of negative scenarios and an empty opportunity column, and that asymmetry is a frequent Stage 1 finding. The opportunity dimension is not optional or aspirational, it is structural. Opportunities include chances to improve continuity capability beyond the baseline (faster RTO, cheaper recovery, stronger supplier pool), to win business on resilience credentials (the EU customer who insists on DORA-aligned continuity, the SEBI-regulated customer who insists on CSCRF-aligned suppliers), to convert regulatory change into competitive edge (DPDP Act 2023 preparedness as a sales argument), and to absorb sector shocks asymmetrically (when a competitor falls, the prepared organisation gains). Section 7 of this guide walks through how to surface and capture these.

What "plan" means in 6.1

The planning obligation in 6.1 is structural, not cosmetic. The organisation must do four things. First, decide the methodology, the process by which risks and opportunities will be identified, analysed, evaluated, treated, and monitored. The methodology must be documented (Clause 7.5) and approved at a level that matches the BCMS scope, typically by the BCM Steering Committee or, for regulated entities, by the Risk Management Committee. Second, apply the methodology, run the process and produce the registers and the treatment plan. Third, integrate the outputs, feed the risk and opportunity decisions into the rest of the BCMS: Clause 6.2 objectives, Clause 8.2 BIA assumptions, Clause 8.3 strategy selection, Clause 9.1 monitoring, Clause 9.3 management review. Fourth, keep it current, review on calendar (typically quarterly for the register, annually for the methodology) and on event triggers (significant change per Clause 6.3, incident per Clause 8.6, audit finding per Clause 9.2, regulatory shift, BIA change).

The most common 6.1 failure in the Indian growing-company segment is to produce the artefacts and skip the integration. The register exists, the methodology document exists, the treatment plan exists, but the BIA was completed without consulting the risk register, the objectives were set without consulting the risk treatment plan, and the management review never received the residual risk position. The standard expects the 6.1 outputs to be load-bearing, to influence what the rest of the BCMS does. Where the register sits unread between audit cycles, the 6.1 obligation is unmet even though every artefact is in place.

The 6.1 vs 8.2 demarcation (the mistake every auditor catches)

The single most important architectural decision in implementing 6.1 is to keep it distinct from Clause 8.2 (Business Impact Analysis and Risk Assessment). The two clauses both deal with risk, both require a register, and both feed treatment actions, and that surface similarity is the trap. They operate at different altitudes and serve different purposes.

Clause 6.1 operates at the BCMS level. It asks: what could stop the BCMS itself from working? Risks include a methodology that misses a category of threat; an executive sponsor who disengages; a budget cut that starves Clause 7.1 resources; a key BCM Manager resignation; a regulatory shift (DPDP Act 2023, DORA, APRA CPS 230) that invalidates the current scope; a supplier-concentration risk in the BIA data set itself; an opportunity to win a contract because of demonstrated resilience; an opportunity to upgrade the BCM to industry-leading practice after a competitor's public failure. These are risks and opportunities that affect the management system.

Clause 8.2 operates at the prioritised-activity level. It asks: for each activity the organisation must continue through a disruption, what is the impact of disruption over time (BIA), and what disruptive events could cause that disruption (risk assessment)? Risks include flood at the Chennai delivery centre, ransomware on the core banking system, fire at the Pune DC, prolonged power outage at the Mumbai office, supplier failure at a tier-2 vendor. These are risks of disruption to business activities.

The two registers overlap in the sense that some disruption risks (8.2) also weaken the BCMS (6.1), a ransomware incident that encrypts the BCM documents themselves is both. But the analysis is performed separately, the owners differ, the treatment options differ, and the integration map differs. The clean architectural test is: if the risk materialised, would the harm flow through the underlying business being disrupted (8.2) or through the management system failing to manage that disruption (6.1)? Both can apply, but the registers are separate and the auditor will check.

What "opportunities" means and why it matters

The opportunities dimension of 6.1 is the clause's most under-appreciated load-bearing requirement. Many Indian firms treat it as a tick-box; that produces a register with one or two generic entries ("improve BCM maturity") and no capture mechanism. The standard expects opportunities to be identified with the same rigour as risks and acted on with the same discipline.

Opportunities surface in six recurring patterns. The first is regulatory-shift opportunity, when a new regulation raises the bar, organisations that have already built the capability win business from those that have not. DPDP Act 2023 preparedness, DORA-aligned ICT continuity for EU-facing Indian IT/BPO, RBI MD IT Governance readiness for banks and NBFCs are all current examples. The second is sector-shock opportunity, when a competitor suffers a public disruption, prepared organisations absorb their customers. The third is technology-shift opportunity, when a new technology (immutable backup, active-active multi-region cloud, zero-trust segmentation) materially improves recovery economics, the first movers gain. The fourth is contract-win opportunity, when a customer issues a tender with BCM or DR requirements, a demonstrably mature BCMS converts the requirement into revenue. The fifth is insurance-and-finance opportunity, a demonstrably mature BCMS attracts lower premiums and better counterparty terms. The sixth is people-and-culture opportunity, BCM maturity attracts and retains talent, especially in regulated functions where personal liability is a concern.

Each opportunity is captured with a decision: exploit (commit resources to capture it), share (partner to capture it), enhance (scale up existing capability to capture more), or accept-by-inaction (acknowledge the opportunity and consciously decline). The accept-by-inaction category is important, not every opportunity is worth chasing, and a register that shows a leadership team making deliberate trade-offs is more credible than one that shows them chasing everything.

What the standard does NOT require (the demarcation competitors miss)

Clause 6.1 is widely misread as "produce a risk register", open a spreadsheet, list risks, rate them high/medium/low, file it. That misreading produces the single most common 6.1 nonconformity in the Indian growing-company segment. Being explicit about what 6.1 does not require protects against two failure modes: under-investing (treating the register as a documentation artefact) and over-reaching (treating 6.1 as the entire enterprise risk management programme).

• 6.1 does not require a specific risk methodology. ISO 22301 does not mandate ISO 31000, NIST SP 800-30, OCTAVE, or any other named methodology. The standard requires a methodology that is documented, applied, and effective; the choice is the organisation's. Most well-formed Indian BCMSs borrow from ISO 31000 because it is methodology-agnostic and pairs cleanly with the Harmonized Structure, but that is leading practice, not standardised mandate.
• 6.1 does not require quantitative risk analysis. Qualitative scales (likelihood bands, impact bands, rating grid) are sufficient. Quantitative analysis (monte-carlo, FAIR, ALE) is leading practice in L4 to L5 maturity organisations and required in some sector frameworks (DORA implied through Art 11(5) quant + qual criteria; APRA CPS 230 implied through scenario analysis), but the ISO 22301 baseline is qualitative.
• 6.1 does not require a single enterprise-wide risk register. A BCMS-specific register is the requirement. Integration with the enterprise risk register is advisable (and structurally required for SEBI LODR Reg. 21 listed companies) but the BCMS register can stand alone.
• 6.1 does not require every risk to be mitigated. Risk treatment options include accept, and for risks where the treatment cost exceeds the benefit, acceptance is the correct decision. The standard requires the acceptance to be deliberate, owner-approved, and reviewed; not silent.
• 6.1 does not require risks to be ranked numerically. A rating grid (e.g., 1 to 5 or low/medium/high/critical) is sufficient. Numerical ranking is a convenience for prioritisation, not a requirement.
• 6.1 does not require every opportunity to be exploited. Opportunities can be consciously declined. The standard requires the decision to be documented; it does not require the decision to be yes.
• 6.1 does not require a separate "opportunities register" as a distinct document, the opportunities can be a section of the BCMS risk register, a separate sheet, or a separate document. What is required is that opportunities are captured with the same discipline as risks.
• 6.1 does not require the BCM Manager to be the Risk Owner for every risk. Risk Owners are the function owners in whose domain the risk lives. The BCM Manager is the methodology custodian, not the universal Risk Owner.
• 6.1 does not require top management to approve every risk treatment. Authority thresholds are the organisation's choice. The standard requires treatments above defined thresholds (typically "high" and "critical" residual ratings) to be accepted at top-management level; below that, delegated authority is acceptable.
• 6.1 does not require quantitative benefit capture for opportunities. Qualitative benefit descriptions are sufficient. Quantitative ROI is leading practice and makes the opportunity register more credible to leadership, but is not standardised.
• 6.1 does not require the risk register to be software-hosted. A spreadsheet is conformant. A GRC platform is leading practice in larger organisations but is not mandated. The standard requires the register to be controlled, versioned, and accessible, properties a well-managed spreadsheet has.
• 6.1 does not require a calendar quarterly refresh specifically. The standard requires the register to be kept current; the cadence is the organisation's choice. Quarterly is leading practice; event-triggered updates are essential regardless of the calendar cadence.

Why This Control Matters

The business risk

When a disruption strikes, the second-largest determinant of outcome, after whether named, competent, authorised people are in post (Clause 5.3), is whether the organisation has thought about it in advance. The BIA (Clause 8.2) gives the impact shape; the strategy (Clause 8.3) gives the recovery direction; the plans (Clause 8.4) give the execution choreography. But none of those work the way they should if the BCMS itself has structural weaknesses, methodology gaps, resourcing drift, leadership disengagement, regulatory drift, supplier concentration in the BCM supply chain itself, missed opportunities to upgrade. 6.1 is the clause that surfaces and treats those structural weaknesses.

Every major Indian incident of the last decade that turned from a contained event into a public crisis shares a 6.1 failure mode. The November 2022 AIIMS Delhi ransomware that took e-Hospital down for days, the post-incident review surfaced that the BCM risk register had not contemplated primary-and-backup simultaneous encryption, had not contemplated hospital ransomware as a patient-safety event, and had not captured the opportunity to invest in immutable backups when that technology became affordable in 2019-20. The November 2020 HDFC digital outage that drew the RBI's ban on new digital products, the public record shows that repeated smaller outages in 2018 and 2019 were treated as IT operations issues, not as BCMS warning signals, and the risk register did not upgrade their likelihood. The September 2024 Jio data-centre fire that took a national carrier dark for hours, the BCMS had not contemplated single-DC fire as a risk to the BCMS itself, only to the network; the opportunity to learn from the July 2024 CrowdStrike outage ten weeks earlier was missed.

The business risk of weak 6.1 implementation is concentrated in three failure modes. The first is register-as-documentation, the spreadsheet exists for the auditor, not for the business; the leadership team has never read it; the BCM Manager updates it the night before the surveillance audit. The second is methodology drift, the methodology was sound when written in 2020, but the threat landscape, the regulatory landscape, and the technology landscape have moved; no one refreshed the methodology because no trigger was defined. The third is integration failure, the register exists and is current, but the BIA, the strategy, the objectives, and the management review do not use it; the register is a parallel artefact, not a load-bearing one. All three failure modes produce the same audit finding: the BCMS does not use the output of its own risk assessment to drive improvement.

The Indian regulatory context

The Indian regulatory environment has, over the last decade, transformed 6.1 from a planning formality into a regulator-supervised risk-management expectation with named artefacts and named owners. The transformation has happened across every major sector regulator.

For banks, NBFCs, and payment system operators, the RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024) consolidates a chapter on IT risk management that requires a documented, board-approved IT risk methodology covering identification, assessment, treatment, and monitoring. The RBI Cyber Security Framework (2 June 2016) requires a baseline cyber security risk assessment to inform the board-approved cyber security policy. The RBI's action against HDFC in December 2020, barring new digital products and fresh credit cards pending an external IT audit, demonstrated that the RBI treats risk-assessment drift as a board-level governance failure, not an IT-ops issue.

For SEBI-regulated entities, the Cybersecurity and Cyber Resilience Framework (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024) defines five cyber resilience goals across six operational functions, of which Identify is the function that maps to Clause 6.1. The Identify function requires REs to identify assets, risks, dependencies, and third-party relationships, and to feed the identification into the protection, detection, response, and recovery functions. The SEBI MII BCP-DR circular (22 March 2021) requires Market Infrastructure Institutions to define and document the risks their BCP-DR addresses. For SEBI LODR Reg. 21 listed companies, the Risk Management Committee must include members with cyber, operations, and continuity risk expertise, a structural 6.1 role assignment at the board level.

For insurers, the IRDAI Information and Cyber Security Guidelines (24 April 2023) require a board-approved Information and Cyber Security Policy including risk assessment, vulnerability assessment, and the embedding of risk outputs into the BCP/DR framework.

CERT-In Directions (20(3)/2022-CERT-In, 28 April 2022) indirectly raise the stakes on 6.1: the 6-hour incident-reporting clock presupposes that the organisation has already identified the categories of incident it must report. A risk register that has not contemplated ransomware, unauthorised access, data breach, DoS, or cloud-outage as reportable scenarios is a risk register that will miss the 6-hour clock.

The DPDP Act 2023 (Act 22 of 2023) introduces two new 6.1 risk categories for every Data Fiduciary. Section 8(5) makes the availability of personal data a statutory duty, meaning the BCMS now has a regulator-enforced availability obligation, not just a contractual one. Section 8(6) imposes a breach-notification duty on the Data Protection Board and on affected Data Principals, meaning the BCMS must contemplate breach scenarios as both operational risks (8.2) and BCMS-design risks (6.1: is the breach-notification process itself resilient?). For Significant Data Fiduciaries, the DPDP Rules 2025 add DPIA, periodic security audits, and a DPO obligation, all of which become 6.1 risks if the SDF status is contested or the audit cadence slips. Penalties up to ₹250 crore for failure to take adequate security safeguards and up to ₹200 crore for failure to notify a breach convert 6.1 from a planning exercise into a financial-risk-mitigation exercise.

The 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 for the company, including the elements of risk that may threaten the existence of the company itself. Section 177 and SEBI LODR Regulation 21 give the Audit Committee and the Risk Management Committee explicit oversight of risk management systems. For listed entities, the 6.1 BCMS risk register is in scope of those committees.

The NDMA Disaster Management Act 2005 and the National Disaster Management Guidelines (Chemical Disasters 2007; Disaster Management Plans 2014) require industrial operators, especially in chemicals, petrochemicals, pharma, and manufacturing, to identify disaster risks and integrate industrial plans with District Disaster Management Plans. The LG Polymers Vizag styrene gas leak (7 May 2020) that killed 12-13 people and drew an NGT interim penalty of ₹50 crore is the starkest Indian example of what a 6.1 failure looks like at the industrial-hazard end of the spectrum: the risk of running years without proper environmental clearance was not contemplated, not treated, and not accepted in writing, it was simply invisible to the organisation's risk register.

The cost of non-compliance

The financial exposure of weak 6.1 implementation is concrete and quantifiable. Sector-specific penalties include RBI monetary penalties under the Banking Regulation Act (typically ₹1 crore to ₹10 crore per failure for SCBs; higher for systemic cases); SEBI penalties under the SEBI Act (up to ₹25 crore per contravention); IRDAI penalties (monetary penalties for ongoing non-compliance for insurers (verify the current daily limit)); DPDP penalties (up to ₹250 crore for security-safeguard failures, up to ₹200 crore for breach-notification failures); CERT-In enforcement (escalation to MeitY, with downstream consequences for the entity's ability to operate ICT in India). Beyond direct penalties, the indirect costs typically dwarf the direct ones: share-price drops after a public disruption (Yes Bank's deposit base halved between March and June 2020; Cognizant's Maze ransomware cost $50-70 million in Q2 2020 revenue and margin impact per SEC-filed 10-Q); customer churn (HDFC's repeated outages drove public customer anger and competitor switching); board and executive reputational damage; and the cost of remediation programmes mandated by regulators (HDFC's external IT audit was a precondition for lifting the digital-products ban).

A well-built 6.1 evidence set does not eliminate these risks but it does three things. First, it makes the risks visible, and visible risks get resourced. Second, it makes the organisation's risk decisions defensible, when a regulator asks "did you contemplate this?", the answer is yes, with documentation. Third, it converts the BCMS from a cost centre into an opportunity engine, every regulatory shift, every sector shock, every technology change becomes a question of how to capture it rather than how to survive it.

Scope and Applicability

Who must implement 6.1

Clause 6.1 applies to every organisation that claims conformity to ISO 22301:2019, whether through formal third-party certification, through self-declaration, or through a customer-mandated alignment. There is no organisation size, sector, or geography that is exempt from the planning obligation; the depth and formality scale with the BCMS scope (Clause 4.3), but the obligation itself is universal.

For Indian growing companies (50 to 250 staff), 6.1 typically produces a 30-to-60-entry risk register and a 10-to-20-entry opportunity register, refreshed quarterly, owned by the BCM Manager with function owners as Risk Owners. For growing Indian organisations (250 to 2,000 staff), the register typically grows to 80 to 150 entries, the opportunity register to 25 to 40 entries, and a Risk Management Committee is constituted (mandatory for SEBI LODR Reg. 21 listed companies). For multi-entity enterprises (2,000+ staff), the 6.1 portfolio is integrated with enterprise risk management, with group BCM risk tolerance cascaded to subsidiary risk registers, and with multi-jurisdiction regulatory overlays (DORA for EU financial-sector exposure; APRA CPS 230 for Australian operations; MAS TRM for Singapore operations; RBI MD for Indian banking operations).

Scope boundaries

The 6.1 scope mirrors the BCMS scope (Clause 4.3). If the BCMS scope covers the organisation's Indian payments business but not its international payments business, then 6.1 covers risks and opportunities affecting the Indian payments BCMS only. Scope-boundary risks, risks at the interface between in-scope and out-of-scope, are still 6.1 risks if they affect the BCMS achieving its outcomes.

Outsourced activities (Clause 8.1) are in 6.1 scope if their continuity affects the BCMS. A cloud-hosted core banking system, an outsourced BPO process, a third-party logistics provider, all are 6.1-relevant through supplier-concentration risk, fourth-party risk, and exit-strategy risk. The RBI Master Direction on Outsourcing of IT Services (10 April 2023) and the SEBI CSCRF third-party risk expectations require these to be in the BCMS risk register.

What 6.1 is distinct from

• 6.1 is not enterprise risk management. ERM covers strategic, financial, operational, compliance, and reputational risk across the organisation. 6.1 covers BCMS-level risk and opportunity only. The two should integrate but not collapse into each other.
• 6.1 is not internal audit. Internal audit (Clause 9.2) independently tests the BCMS, including the 6.1 methodology. 6.1 is part of the management system being audited; it is not the audit function.
• 6.1 is not incident management. Incident management (Clause 8.4) operates during disruption. 6.1 operates before disruption (planning) and after (post-incident review feeds back into 6.1).
• 6.1 is not the BIA. The BIA (Clause 8.2) identifies prioritised activities and the impact of disruption over time. 6.1 identifies what could stop the BCMS working. They feed each other but they are not the same artefact.
• 6.1 is not risk treatment execution. Selecting a treatment option is 6.1; executing the treatment (deploying an immutable backup system, switching suppliers, building a work-area recovery site) is operational and falls under Clause 8.1 (operational planning and control) or sector-specific operational clauses.

Key Definitions and Terminology

Risk

In the ISO 22301 / ISO 31000 tradition, risk is the effect of uncertainty on objectives. Three features matter. First, risk is about uncertainty, probabilities, not certainties. Second, risk is relative to objectives, in 6.1 the relevant objectives are the BCMS outcomes (continuity of prioritised activities, fulfilment of obligations, protection of interested-party value). Third, risk can be positive or negative, positive uncertainty is opportunity, addressed separately below. The BCMS risk register captures both negative risks (the everyday use of the word) and the conditions that could create them.

Opportunity

An opportunity is a positive uncertainty, a chance to improve the BCMS's outcomes beyond the baseline. Opportunities include upgrading capability, winning business, capturing regulatory tailwinds, absorbing sector shocks asymmetrically, and improving recovery economics. The opportunity register is the paired complement to the risk register; both use the same identification-discipline-treatment-capture discipline.

Risk source

A risk source is the element (alone or in combination) that has the potential to give rise to a risk. Risk sources for the BCMS include: leadership disengagement, methodology drift, resourcing cuts, regulatory shifts, supplier concentration, technology obsolescence, key-person dependencies, scope creep, scope shrinkage, audit findings, incident learnings, climate change (per ISO 22301:2019 Amendment 1:2024, climate-related risk has been an explicit consideration in Clause 4.1 context since the amendment), geopolitical shifts, and sector shocks.

Risk event

A risk event is the occurrence of a risk. Most BCMS risks do not have a single dramatic event; they degrade over time. "Leadership disengagement" plays out as missed Steering Committee meetings, deferred decisions, and budget cuts, not as a single incident. The risk register captures both acute-event scenarios (the BCM Manager resigns) and chronic-degradation scenarios (the BCM loses executive air-cover over six months).

Risk consequence

A risk consequence is the outcome of a risk event. For 6.1, consequences are measured against BCMS outcomes: did the BCMS continue to deliver continuity of prioritised activities? did it fulfil its obligations? did it protect interested-party value? Consequence scales are typically defined in terms of degradation of those outcomes, minor (RTO missed by minutes), moderate (RTO missed by hours), major (continuity failure for one prioritised activity), severe (continuity failure for multiple prioritised activities), catastrophic (BCMS collapse).

Risk likelihood

Risk likelihood is the chance of the risk event occurring. Likelihood scales are typically defined in qualitative bands (rare, unlikely, possible, likely, almost certain) sometimes with quantitative anchors (e.g., once in 10+ years, once in 5-10 years, once in 2-5 years, once in 1-2 years, more than once a year). The likelihood scale must be calibrated to the BCMS scope, a national carrier's likelihood of a DC fire is different from a single-office startup's.

Risk rating

Risk rating is the combined likelihood-consequence score on the agreed risk-criteria matrix. A 5-by-5 matrix is the most common structure; ratings of low, medium, high, critical correspond to coloured zones on the matrix. The rating drives the treatment category and the authority level for acceptance.

Risk treatment

Risk treatment is the decision and action on a risk. The four classical options, avoid (eliminate the risk source), mitigate (reduce likelihood or consequence), transfer (move the consequence to a third party via insurance, contract, or outsourcing), accept (consciously retain the residual risk), are the menu. Most BCMS risks require a combination: mitigate the likelihood, transfer the residual, accept the untransferable remainder.

Residual risk

Residual risk is the risk remaining after treatment. The standard requires the residual position to be visible to top management (Clause 5.1 / 9.3). The risk-acceptance log captures every residual above threshold with the acceptor, the rationale, and the review date.

Risk appetite and risk tolerance

Risk appetite is the level of risk the organisation is willing to pursue (often framed as "how much risk are we willing to take to capture an opportunity?"). Risk tolerance is the level of risk the organisation is willing to bear (often framed as "beyond this line, we must treat"). Both are set by top management, informed by Clause 4.1 context and Clause 5.2 policy, and operationalised through the 6.1 risk-criteria matrix.

Risk owner

A Risk Owner is the person accountable for a risk, its treatment decision, its residual position, its review. Risk Owners are function owners in whose domain the risk lives (CISO for cyber risks; Head of Operations for process risks; Head of Procurement for supplier risks). The BCM Manager is the methodology custodian, not the universal Risk Owner, a register where every risk has the same owner is a register without ownership.

Scenario

A scenario is a structured description of a risk event, its source, trigger, progression, consequence, and detection. Scenarios are the working units of the risk register; abstract risks ("cyber attack") are converted into scenarios ("ransomware on the core ledger encrypts primary and backup, halting inter-bank settlement for 6 hours"). The Clause 8.5 exercise programme uses 6.1 scenarios as inputs.

BCMS outcomes

The BCMS outcomes are the purposes for which the BCMS exists, as set out in Clause 1 of the standard and shaped by Clause 4.1 context. They are: continuity of prioritised activities (the 8.2 outputs), fulfilment of legal, contractual, and regulatory obligations, and protection of interested-party value. The 6.1 risk and opportunity assessment is calibrated to these outcomes, a risk matters if it could compromise an outcome; an opportunity matters if it could advance one.

Terminology variants across frameworks

Different frameworks use overlapping-but-not-identical labels. RTO and RPO are near-universal but the business-impact ceiling is called MAO (Maximum Acceptable Outage) in older ISO 22301:2012 tradition, MTPD (Maximum Tolerable Period of Disruption) in ISO 22301:2019 / ISO/TS 22318:2021, and tolerance for the maximum period of disruption in APRA CPS 230 paragraph 38. MBCO (Minimum Business Continuity Objective) is ISO's label for the minimum acceptable delivery level, expressed as minimum service levels in CPS 230 paragraph 38(c) and as impact tolerance in UK FCA/PRA/CB operational resilience policy. The 6.1 methodology should state which terminology variants it uses and reconcile them in cross-framework mappings (see Section 16).

Relationship to Other Clauses and Frameworks

Inside ISO 22301:2019

Clause 6.1 is positioned in Clause 6 (Planning) alongside 6.2 (objectives) and 6.3 (change management). The positioning is architectural: 6.1 identifies the uncertainties, 6.2 sets the objectives that respond to those uncertainties, and 6.3 ensures changes to the BCMS go through the same planning discipline.

The relationships cascade in both directions.

Upstream of 6.1:

• Clause 4.1 (context) supplies the internal and external issues that are the source of BCMS risks.
• Clause 4.2 (interested parties) supplies the needs and expectations that calibrate which risks matter.
• Clause 4.3 (scope) defines what 6.1 covers.
• Clause 4.4 (the BCMS) is the system whose risks 6.1 addresses.
• Clause 5.1 (leadership) ensures the methodology exists, is resourced, and is used.
• Clause 5.2 (policy) sets the risk appetite and tolerance.
• Clause 5.3 (roles) names the Risk Owners.

Downstream of 6.1:

• Clause 6.2 (objectives) cascades from the risk treatment plan, each "high" residual risk should generate a corresponding objective.
• Clause 6.3 (change) triggers risk re-assessment when the BCMS scope or design changes.
• Clause 7.1 (resources) funds the treatment plan.
• Clause 7.4 (communication) covers risk communication to interested parties.
• Clause 7.5 (Documented Information) controls the register, methodology, and treatment plan.
• Clause 8.1 (operational planning and control) executes the day-to-day risk-management actions.
• Clause 8.2 (BIA and disruption risk) is the other risk clause, it operates at the prioritised-activity level and uses 6.1 outputs (especially the risk criteria) but produces its own register.
• Clause 8.3 (strategy) selects continuity solutions that address the 8.2 disruption risks, validated against the 6.1 BCMS risks.
• Clause 8.5 (exercise programme) uses 6.1 scenarios as exercise inputs.
• Clause 8.6 (evaluation) feeds post-disruption learnings back into 6.1.
• Clause 9.1 (monitoring) tracks risk KPIs.
• Clause 9.2 (internal audit) tests the methodology.
• Clause 9.3 (management review) receives the residual risk position.
• Clause 10.1 (corrective action) updates the register for nonconformities.
• Clause 10.2 (continual improvement) advances the methodology maturity.

The cleanest framing: 6.1 is the risk-and-opportunity spine of the BCMS. It draws inputs from Clause 4 and 5; it feeds outputs into Clauses 6.2, 7, 8, 9, and 10. A BCMS without a working 6.1 is a body without a nervous system, the limbs (BIA, strategy, plans, exercises) work in isolation but the system has no overall coordination.

To other ISO management-system standards

ISO/IEC 27001:2022 Clause 6.1 (information security risks) is the direct parallel. Both clauses use the same Harmonized Structure, both require a documented methodology, both require a register, both require treatment decisions, both require integration with the rest of the management system. For organisations running both an ISMS and a BCMS, the methodologies should align (same likelihood scale, same consequence scale where the consequence domain overlaps) but the registers are separate because the risk populations differ. Common ground: cyber-attack scenarios appear in both registers (ISMS focuses on confidentiality/integrity threats; BCMS focuses on availability/continuity consequences). Integration avoids duplicate work and conflicting ratings.

ISO/IEC 27001:2022 Clause 6.1.2 (information security risk assessment) and Clause 6.1.3 (information security risk treatment) together fulfil the same role for ISMS that 6.1 does for BCMS. The Statement of Applicability (SoA) in 27001 is the treatment-decision artefact; the BCMS equivalent is the risk treatment plan.

ISO 31000:2018 (Risk Management, Guidelines) is methodology-agnostic guidance that aligns cleanly with 6.1. Many Indian BCMSs borrow ISO 31000's vocabulary (risk source, risk event, consequence, likelihood) and its process (scope → identify → analyse → evaluate → treat → monitor). ISO 31000 is not a management-system standard and is not certifiable, but it is the methodological bedrock.

ISO 9001:2015 Clause 6.1 (actions to address risks and opportunities) is the quality-management parallel. Same Harmonized Structure, same paired risks-and-opportunities construction. For organisations running an integrated Quality + BC management system, the 6.1 clauses of both standards can be jointly implemented, a single risk-and-opportunity register covering both quality and continuity risks, with the appropriate domain tagging.

ISO 22313:2020 (guidance on the use of ISO 22301) provides companion guidance on Clause 6.1, expanding on what the standard requires without adding new mandatory obligations. The guidance is non-authoritative for certification (only ISO 22301:2019 itself is the certification reference) but it is the most useful practitioner elaboration of 6.1.

To sector and global frameworks

Section 16 of this guide provides the full multi-framework mapping. The headline anchors: DORA Articles 6 to 16 (ICT risk management framework) operationalise 6.1 for EU financial entities; APRA CPS 230 paragraphs 16-19 (risk management framework) and 26-28 (scenario analysis) operationalise it for Australian prudential entities; FFIEC BCM Booklet structures its risk-and-impact principle to mirror ISO 22301 6.1; NIST SP 800-30 Rev 1 and NIST SP 800-39 provide the US federal risk-assessment methodology that maps to 6.1; NIST CSF 2.0 Govern function covers risk-management strategy; MAS TRM and HKMA OR-2 provide the Singapore and Hong Kong equivalents. Indian regulatory anchors: RBI MD IT Governance 2023 (IT risk chapter), RBI Cyber Security Framework 2016, SEBI CSCRF 2024 Identify goal, IRDAI ICS 2023, DPDP Act 2023, CERT-In Directions 2022, Companies Act 2013 §134(3)(n) and §177, SEBI LODR Reg. 21, NDMA DM Act 2005. A well-built 6.1 evidence set satisfies all of these simultaneously.

Detailed Implementation Guidance, The Eight Risk-and-Opportunity Moves

Figure · Process

What Clause 6.1 asks you to do

This section walks through the eight implementation moves that together produce a 6.1-conformant BCMS risk-and-opportunity system. The moves are sequenced for a first-cycle implementation; a mature BCMS runs them in parallel on different cadences.

Move 1, Charter the risk-and-opportunity assessment (methodology, criteria, scope)

The first move is to charter the assessment: agree the methodology, set the criteria, define the scope, and name the owners. The output is a BCMS Risk and Opportunity Assessment Charter (one of the toolkit artefacts) approved by the BCM Steering Committee.

The charter must specify the following eight elements.

First, scope, the slice of the BCMS the assessment covers. For most first-cycle implementations, the scope mirrors the Clause 4.3 BCMS scope. Subsequent cycles may run thematic deep-dives (e.g., a cyber-risk deep dive, a supplier-risk deep dive, a regulator-risk deep dive).

Second, methodology, the process by which risks and opportunities are identified, analysed, evaluated, treated, and monitored. The methodology must name the process standard or framework it borrows from (ISO 31000:2018 is the default for Indian BCMSs; NIST SP 800-30 Rev 1 is common for cyber-heavy BCMSs; sector-practitioner methodologies are common in BFSI).

Third, likelihood scale, the bands and definitions. A five-band scale (rare / unlikely / possible / likely / almost certain) is the most common, with quantitative anchors calibrated to the BCMS scope. For example: rare = once in 10+ years; unlikely = once in 5-10 years; possible = once in 2-5 years; likely = once in 1-2 years; almost certain = more than once a year.

Fourth, consequence scale, the bands and definitions, calibrated to BCMS outcomes. A five-band scale (insignificant / minor / moderate / major / catastrophic) is the most common. For BCMS consequences, the scale typically references continuity of prioritised activities (a "moderate" consequence might be "RTO missed by hours for one prioritised activity"; a "catastrophic" consequence might be "BCMS collapse, multiple prioritised activities down beyond MTPD, regulatory enforcement triggered").

Fifth, risk-criteria matrix, the 5-by-5 (or 4-by-4, or 3-by-3) grid that combines likelihood and consequence into a rating. The matrix maps to four zones: low (acceptable, monitor), medium (treat if cost-effective, accept with documented rationale), high (treat, accept only with top-management sign-off), critical (treat, accept only with board Risk Committee sign-off and a time-bound remediation plan).

Sixth, treatment categories, avoid, mitigate, transfer, accept for risks; exploit, share, enhance, accept-by-inaction for opportunities. The charter specifies the authority levels for each treatment decision (e.g., BCM Manager can accept "low" risks; Executive Sponsor can accept "medium"; Steering Committee can accept "high"; Board Risk Committee accepts "critical").

Seventh, review cadence and triggers, calendar cadence (quarterly for the register, annually for the methodology) plus event triggers (significant change per Clause 6.3; incident per Clause 8.6; audit finding per Clause 9.2; regulatory shift; BIA change; new threat intelligence).

Eighth, owner assignments, the BCM Manager as methodology custodian; function owners as Risk Owners for risks in their domain; the Risk Management Committee (or BCM Steering Committee in non-listed entities) as the review forum; top management as the residual-risk acceptor for "high" and "critical" residuals.

The charter is the single most important 6.1 artefact. A Stage 1 certification audit that finds no charter will typically issue a major nonconformity on 6.1 regardless of how clean the risk register looks.

Move 2, Build the BCMS scenario library

The second move is to build the scenario library, the structured catalogue of BCMS-level threat and opportunity scenarios that the assessment will work through. The scenario library is the working vocabulary of the risk-and-opportunity register; abstract risks ("cyber attack") are useless, scenarios ("ransomware encrypts primary and backup of core ledger, halting inter-bank settlement for 6 hours") are actionable.

For BCMS-level risk, eleven scenario families cover the recurring patterns.

Family 1, Leadership and governance risks. Executive sponsor disengagement, BCM Manager resignation, Steering Committee non-quorum, board Risk Committee skills gap, top management non-engagement with Clause 9.3 review, role-assignment drift (Clause 5.3 lapse), authority-matrix staleness, deputy and succession gap.

Family 2, Methodology risks. Methodology drift (the 2020 methodology does not reflect 2025 threat landscape), criteria mis-calibration (likelihood anchors no longer match observed frequency), scenario-blindness (a category of threat is missing, e.g., climate per Amd 1:2024, supply-chain cyber, AI-related risk), integration failure (the BIA, strategy, and plans do not use the register outputs).

Family 3, Resource risks. Budget cuts, staffing loss, BCM role unfilled, training budget eliminated, exercise budget reduced below the level needed to validate Clause 8.5, GRC platform decommissioned without replacement.

Family 4, Regulatory risks. DPDP Act 2023 SDF designation, breach-notification timeline slippage, RBI MD IT Governance supervisory finding, SEBI CSCRF compliance gap, IRDAI ICS non-conformity, CERT-In Directions enforcement, NDMA enforcement, new sector regulation (e.g., the upcoming Digital India Act), cross-border regulation (DORA, APRA CPS 230, MAS TRM) for organisations with international exposure.

Family 5, Supplier and outsourcing risks. Single-supplier concentration (one cloud provider, one BPO, one logistics partner), fourth-party risk (the supplier's supplier), supplier BCP/DR not inheriting the customer's standard (RBI MD Outsourcing 2023 violation), supplier exit or financial failure, supplier migration lock-in, supplier-side incident that propagates (Change Healthcare 2024, CrowdStrike 2024, the CDK Global 2024 ransomware that took down 15,000 auto dealers).

Family 6, Technology and infrastructure risks. Cloud-region concentration, single-DC architecture (the Jio September 2024 DC fire lesson), single-cloud-vendor lock-in, technology obsolescence (legacy systems past vendor support), immutable-backup absence (the AIIMS 2022 lesson), OT/IT segmentation absence (the LG Polymers lesson applied to OT continuity), AI and ML failure modes (model drift, training-data poisoning, prompt injection for LLM-based services).

Family 7, People and competence risks. Key-person dependencies (the Akasa Air pilot-exodus lesson; the BCM Manager resignation; the sole CISO departure), skills shortage (cyber, BCM, OT, cloud architecture), workforce concentration in one geography (the Chennai floods 2015 lesson), home-office single-point-of-failure (entire critical team in one flood-prone neighbourhood).

Family 8, Geographic and climate risks. Site concentration in a single seismic / flood / cyclone / industrial-hazard zone, climate-driven frequency shift in extreme weather (per ISO 22301:2019 Amendment 1:2024), coastal infrastructure exposure, urban heat-island effects on DC cooling, water stress for industrial processes.

Family 9, Cyber, ransomware, and IT outage risks (BCMS-level). Ransomware that disables the BCMS itself (encrypts the BCM documents, the contact tree, the BIA), supply-chain ransomware (the Cognizant Maze 2020 lesson), SaaS outage (the CrowdStrike 2024 lesson that downed IndiGo), nation-state activity on critical infrastructure (the contested Mumbai October 2020 blackout attribution is the Indian reference), identity-provider outage, certificate-expiry cascade.

Family 10, Reputational and trust risks. Public incident disclosure that damages customer trust (the Sun Pharma 2023 ransomware disclosure lesson), regulator-publicised enforcement, social-media crisis amplification, customer churn after a continuity failure, board reputational exposure.

Family 11, Opportunity scenarios (paired complement). Regulatory shift creates a customer requirement the BCMS can satisfy (DPDP Act 2023 preparedness wins contracts; DORA-aligned continuity wins EU-facing business), sector shock makes competitor customers available (post-incident customer migration), technology shift lowers recovery economics (immutable backup, multi-region active-active, zero-trust), insurance premium reduction for demonstrated BCM maturity, talent attraction through BCM credibility, board-level risk-oversight credibility through demonstrated 6.1 maturity.

The toolkit provides the scenario library as a starting catalogue. Each scenario is customised to the organisation's context, scope, and BIA outputs.

Move 3, Identify the risks (BCMS level)

The third move is to identify BCMS-level risks, populate the risk register using the scenario library as the working vocabulary. Risk identification is a structured, facilitated activity; it is not a solo desk exercise by the BCM Manager.

The recommended identification process has four parts. First, a leadership interview set, one-hour conversations with the executive sponsor, the CISO, the Head of Operations, the Head of Procurement, the Head of HR, the Head of Legal/Compliance, and (for regulated entities) the regulator-mandated officers. The interviews surface risks the BCM Manager would not see from their position. Second, a function-workshop series, half-day workshops with each function to walk through the eleven scenario families and surface function-specific risks. Third, a BIA cross-reference, the BIA (Clause 8.2) outputs are reviewed to identify where BIA assumptions could be invalidated by BCMS-level risks (e.g., a BIA that assumes a supplier will be available is exposed if the supplier is single-sourced). Fourth, a lessons-input review, the last 12 months' incidents (Clause 8.6 outputs), audit findings (Clause 9.2), exercise results (Clause 8.5), and corrective actions (Clause 10.1) are reviewed for emerging risks.

Each identified risk is captured with: a unique ID; a one-sentence scenario description; the risk source (which of the eleven families); the Risk Owner (a named function owner); the date identified; the existing controls (what is already in place that addresses the risk); the identification method (interview, workshop, cross-reference, lessons-input).

The 6.1-vs-8.2 demarcation test is applied at this stage. For each candidate risk, the BCM Manager asks: does this risk affect the BCMS achieving its outcomes, or does it affect the underlying business being disrupted? If the former, it is a 6.1 risk. If the latter, it is an 8.2 risk. If both, it goes in both registers with a cross-reference.

Move 4, Identify the opportunities

The fourth move is to identify BCMS-level opportunities, populate the opportunity register with the same rigour as the risk register. Opportunity identification is the most-skipped move in 6.1 implementations and the most-asked-about in Stage 2 audits.

The recommended opportunity-identification process has four parts. First, a leadership opportunity workshop, a half-day session with the executive sponsor and direct reports to surface strategic opportunities the BCMS could capture. The six recurring opportunity patterns in Section 2.4 are used as the working framework. Second, a regulatory-shift horizon scan, the compliance and legal functions scan the next 12-24 months of regulatory change for opportunities (DPDP Rules 2025 finalisation, Digital India Act, sector-specific circulars, cross-border frameworks the organisation could align with). Third, a customer-tender BCM requirements review, the sales and account management functions review recent and in-pipeline tenders for BCM requirements the BCMS could satisfy competitively. Fourth, a technology and economics scan, the CTO and CFO functions review emerging technology and economic shifts that could improve BCMS economics (immutable backup, multi-region cloud, zero-trust, AI-assisted incident detection).

Each identified opportunity is captured with: a unique ID; a one-sentence description; the opportunity source (which of the six patterns in Section 2.4); the Opportunity Owner (a named leader); the potential benefit (qualitative or quantitative); the capture decision options (exploit / share / enhance / accept-by-inaction); the date identified.

Move 5, Analyse and evaluate against the criteria

The fifth move is to analyse and evaluate every identified risk and opportunity against the criteria set in Move 1. Analysis is the careful estimation of likelihood and consequence for each entry. Evaluation is the comparison of the analysis against the criteria to produce a rating.

For each risk, the analysis estimates likelihood (against the likelihood scale) and consequence (against the consequence scale), with the existing controls taken into account. The analysis is documented in the register: the rationale for the likelihood rating, the rationale for the consequence rating, the existing controls that informed the analysis. The evaluation then plots the likelihood-consequence pair on the risk-criteria matrix to produce the inherent rating (before additional treatment) and the residual rating (after planned treatment). The gap between inherent and residual is the planned treatment benefit, a useful indicator for prioritisation.

For each opportunity, the analysis estimates likelihood (the chance the opportunity materialises if pursued) and benefit (the positive consequence if captured). Opportunities can use a parallel criteria matrix, likelihood on one axis, benefit on the other, to produce a priority rating. The analysis is documented: the rationale for the likelihood, the rationale for the benefit, the existing capability that would support capture.

Analysis and evaluation are best run as a structured workshop with Risk Owners present, the BCM Manager facilitates, the Risk Owner provides the input, the CISO or Head of Risk challenges the ratings (the "red team" function). Workshopping avoids the failure mode of a BCM Manager single-handedly rating risks they do not fully understand.

Move 6, Select risk treatment and opportunity capture decisions

The sixth move is to select treatment and capture decisions for every risk and opportunity. The selection is a decision, not a default, every entry in the register has a documented decision with rationale, owner, and target date.

For risks, the four classical treatment options are the menu:

• Avoid, eliminate the risk source. Example: decommission a legacy single-DC system that is the source of the single-point-of-failure risk; replace with active-active multi-region. Avoidance is the most decisive and often the most expensive option; it is preferred when the risk cannot be adequately mitigated or transferred.
• Mitigate, reduce likelihood or consequence. Example: implement immutable backups to reduce the consequence of ransomware; diversify suppliers to reduce the likelihood of single-supplier failure; cross-train deputies to reduce the likelihood of key-person risk crystallising. Mitigation is the workhorse of BCMS risk treatment.
• Transfer, move the consequence to a third party. Example: buy cyber-insurance to transfer the financial consequence of a ransomware incident; contractually require suppliers to maintain BCM standards that inherit yours (RBI MD Outsourcing 2023 expectation); outsource a non-core activity to a specialist with stronger BCM. Transfer does not eliminate the risk, it moves the financial consequence; reputational and regulatory consequences typically remain.
• Accept, consciously retain the residual risk. Acceptance is legitimate when treatment cost exceeds treatment benefit, when the risk is below the threshold set in the charter, or when no treatment is feasible. Acceptance requires the acceptor to be at the right authority level (per the charter) and the rationale to be documented in the risk-acceptance log.

For opportunities, the four parallel capture options:

• Exploit, commit resources to capture the opportunity. Example: invest in DPDP Act 2023 readiness ahead of competitors and use it in sales conversations. Exploit is the opportunity analogue of mitigate.
• Share, partner to capture the opportunity. Example: partner with a complementary service provider to bid for a contract that requires combined BCM capability.
• Enhance, scale up existing capability to capture more of the opportunity. Example: extend an existing immutable backup deployment to cover more systems, capturing additional insurance premium reduction.
• Accept-by-inaction, consciously decline the opportunity. Accept-by-inaction is legitimate when the capture cost exceeds the benefit, when the opportunity is outside strategic focus, or when capacity is constrained. The decision is documented to demonstrate the opportunity was considered, not missed.

Each treatment and capture decision is captured with: the decision (which option), the rationale (why this option, why not the alternatives), the action owner (who executes), the target date (when the action will be complete), the expected residual rating (for risks) or expected benefit (for opportunities), the resources required (per Clause 7.1).

Move 7, Build the risk treatment plan and integrate

The seventh move is to build the risk treatment plan, the sequenced, resourced, dated action list that operationalises the treatment decisions, and to integrate the outputs across the BCMS.

The risk treatment plan is a single document (or a single sheet in the register) that aggregates every treatment and capture action with an owner and a date. The plan is sequenced by priority (high-rated risks first) and by dependency (some treatments depend on others, e.g., implementing immutable backup before revising the ransomware scenario in the BIA). The plan has milestones (typically 30-day, 90-day, 180-day) and a reporting cadence to the BCM Steering Committee.

Integration is what makes the 6.1 outputs load-bearing. The integration map has six paths:

• 6.1 → 6.2 (objectives). Each "high" or "critical" residual risk generates a corresponding Clause 6.2 objective. Example: a high-rated supplier-concentration risk generates an objective "reduce single-supplier exposure for top-5 critical activities from 100% to 50% by FY end." The 6.2 objective is the operationalisation of the 6.1 treatment decision.
• 6.1 → 8.2 (BIA). The BIA assumptions are stress-tested against the 6.1 risk register. If the BIA assumes a supplier will be available within RTO, and the 6.1 register flags that supplier as a concentration risk, the BIA assumption is challenged and either justified (with documented rationale) or revised.
• 6.1 → 8.3 (strategy). Continuity strategy selection uses the 6.1 outputs. If 6.1 flags cyber-risk as high-rated, the strategy must include cyber-resilience solutions (immutable backup, segmentation, threat detection). If 6.1 flags supplier risk, the strategy must include supplier-diversification options.
• 6.1 → 8.5 (exercises). The exercise programme uses 6.1 scenarios as inputs. A high-rated ransomware scenario is the input to the next ransomware exercise; a high-rated supplier-failure scenario is the input to the next supplier-failover exercise.
• 6.1 → 9.1 (monitoring). Risk KPIs (see Section 12) are added to the monitoring set. The residual risk trend, the high-rated risk count, the overdue-treatment-action count, the opportunity-capture rate, all are tracked.
• 6.1 → 9.3 (management review). The residual risk position is a mandatory input to the management review. The 9.3 review package shows the top-10 residual risks, the treatment-plan progress, the opportunity-capture status, and any risks accepted at top-management level.

Move 8, Monitor, review, and continually improve

The eighth move is to monitor, review, and continually improve the risk-and-opportunity portfolio. This move is what keeps 6.1 from becoming a once-and-done exercise; it is the difference between an L2 (register-as-documentation) and an L4 (living-portfolio) BCMS.

Monitoring operates on three cadences. Real-time, risk KPIs on the BCM dashboard, alerts on overdue treatment actions, watch on emerging threat intelligence. Periodic, monthly review by the BCM Manager, quarterly review by the BCM Steering Committee, half-yearly review by the Risk Management Committee (or board Risk Committee for listed entities), annual review by top management as part of the 9.3 management review. Event-triggered, re-assessment of the affected risks whenever a defined trigger occurs: significant change to the BCMS (Clause 6.3), incident (Clause 8.6), audit finding (Clause 9.2), regulatory shift, BIA change, new threat intelligence, key-person change.

Review operates on two cadences. Calendar review, the methodology itself is reviewed annually to ensure the criteria, the scenario library, and the integration map are still fit for purpose. Trigger review, the methodology is reviewed whenever a structural shift occurs (new regulation, new business line, new geography, major incident, major audit finding).

Continual improvement operates on a maturity-advancement model (see Section 22). Each annual cycle should produce at least one methodological advance, a new scenario family added, a quantitative dimension introduced, a new integration path wired up, a new metric tracked. The Clause 10.2 continual improvement obligation applies directly to 6.1: the BCMS risk-and-opportunity system must get better over time, not just stay current.

Tools, Technologies, and Solutions

The 6.1 tooling landscape divides into four layers, each with different cost, complexity, and integration profiles. Indian growing companies typically start at Layer 1 and progress upward as the BCMS matures; the certification audit does not require any specific layer, only that the artefacts are controlled, versioned, and accessible (Clause 7.5).

Layer 1, Spreadsheet and document repository

The entry-level 6.1 toolset is a structured spreadsheet for the risk register, a parallel sheet for the opportunity register, a document for the methodology and charter, and a shared drive or document repository for version control. For a 50-to-250-staff growing company, this layer is sufficient for first-cycle conformity. Cost is essentially zero (existing productivity tooling), and the BCM Manager's time is the main investment.

The failure mode of Layer 1 is the spreadsheet-as-graveyard, the register is updated once and then neglected because no one is forced to look at it. The fix is discipline: calendar reviews, event-triggered updates, and integration with the BCM Steering Committee agenda (so the register is opened at every meeting, not just at the annual audit).

Layer 2, GRC platform with BCM module

The next layer is a Governance, Risk, and Compliance platform with a BCM module. The platform provides structured risk capture, workflow for treatment actions, dashboards for KPIs, integration with the rest of the GRC set (ISMS risk register, audit management, policy management, supplier risk), and an audit trail. Indian growing companies typically adopt a GRC platform at the 250-to-2,000-staff stage, when the volume of risks, the complexity of integration, and the audit-evidence burden make spreadsheets uneconomic.

Cost ranges (illustrative third-party platform pricing, not Singahi pricing): Indian and India-anchored GRC platforms typically range from ₹3-8 lakh per year for a 250-500-staff mid-market (250 to 2,000 staff) deployment to ₹15-40 lakh per year for a 1,000-5,000-staff enterprise deployment. Global GRC platforms with India presence typically range from ₹8-25 lakh per year for mid-market (250 to 2,000 staff) to ₹40-150 lakh per year for enterprise. The platform selection should be driven by the integration requirements (does it integrate with the ISMS risk register? with the supplier management tool? with the audit management tool?), the India regulatory content (does it ship with RBI MD, SEBI CSCRF, IRDAI ICS, DPDP control mappings?), and the user-experience (will function owners actually use it?).

Layer 3, Integrated risk and resilience suite

The third layer is an integrated risk-and-resilience suite, a platform that combines BCMS risk, BIA, strategy selection, plan management, exercise management, incident management, and crisis communications in a single workflow. This layer is the L4-to-L5 maturity toolset; it is what large regulated entities (banks, MII, insurers, pharmaceutical manufacturers, critical-infrastructure operators) typically deploy.

Cost ranges (illustrative): typically ₹25-100 lakh per year for a full enterprise deployment, plus implementation services. The business case rests on three arguments: regulatory defensibility (the platform produces the evidence the regulator expects), operational efficiency (one workflow instead of many disconnected artefacts), and risk reduction (faster detection, faster response, faster recovery).

Layer 4, Custom and AI-augmented

The fourth layer is custom-built or AI-augmented risk management, typically an extension of Layer 3 with custom analytics, AI-assisted scenario generation, predictive risk modelling, and integration with threat-intelligence feeds. This layer is at the leading edge; a small number of Indian and global firms operate at this level. The cost and complexity are substantial, and the value depends on the organisation's ability to convert the analytics into decisions.

The category-level tool comparison

The toolkit provides a tool-comparison matrix (document 14) that frames the choice across six categories: spreadsheet-and-repository, India-anchored GRC, global GRC with India presence, integrated risk-and-resilience suite, custom-built, and AI-augmented. The matrix evaluates each category on dimensions relevant to 6.1: risk-register management, opportunity capture, integration with BIA and strategy, audit-evidence production, India regulatory content, total cost of ownership, time-to-value, and user adoption.

The categories are described at the category level, the matrix does not name specific vendors, in keeping with the IP-and-sourcing rules that govern this series. The procurement decision is then made by issuing a request-for-proposal across the relevant categories, evaluating against the organisation's specific requirements, and piloting the shortlisted options.

Free and low-cost resources

For organisations at the very start of the 6.1 journey, several free and low-cost resources support methodology design. ISO 31000:2018 (the risk management guidelines) is the methodological bedrock; the NIST SP 800-30 Rev 1 risk-assessment methodology is free at csrc.nist.gov; the NIST CSF 2.0 Govern function documentation is free at nist.gov; the RBI Master Direction on IT Governance (7 November 2023) is free at rbi.org.in; the SEBI CSCRF (20 August 2024) is free at sebi.gov.in; the CERT-In Directions are free at cert-in.org.in. These primary sources provide the framework against which any paid tooling must demonstrate value.

Policy and Procedure Templates

The 6.1 policy and procedure set comprises four documents. The toolkit provides ready-to-customise templates for each; this section summarises the structure and intent.

The BCMS Risk and Opportunity Policy

The apex policy is the BCMS Risk and Opportunity Policy, a top-management-approved document that sets the risk appetite, the risk tolerance, the methodology, the authority levels, and the integration obligations. The policy is what the certification auditor asks to see first; everything else flows from it.

A well-structured policy contains: (a) purpose and scope, linking to the Clause 5.2 BCMS Policy and the Clause 4.3 BCMS Scope; (b) risk appetite and tolerance statements, framed in business language; (c) methodology summary (full methodology in a separate document); (d) roles and responsibilities, cross-referencing the Clause 5.3 RACI matrix; (e) authority levels for treatment decisions and risk acceptance; (f) integration obligations (the six integration paths in Move 7); (g) review cadence and triggers; (h) documented information requirements per Clause 7.5; (i) sample "shall" clauses of the organisation's own drafting that bind internal stakeholders to the policy (these are permitted and encouraged, they are the organisation's own commitments, not the standard's text).

Sample policy "shall" clauses of Singahi's drafting (illustrative, adapt to the organisation's context):

ISO 22301:2019 Clause 6.1 asks organizations to plan how to handle the risks and opportunities that could affect the BCMS achieving its outcomes.

The [Organisation]'s top management shall accept residual risks rated "high" or "critical" in writing, with documented rationale, before such risks are retained.

The [Organisation]'s BCM Manager shall report the residual risk position to the BCM Steering Committee at every calendar quarter and to top management at the annual management review.

Function owners shall act as Risk Owners for risks in their domain and shall maintain the accuracy of the risk entries assigned to them.

The BCMS Risk and Opportunity Assessment Procedure

The procedure document is the operating manual for Move 1 to Move 8. It specifies step-by-step how the methodology is applied: who does what, when, with what inputs, producing what outputs, in what format, stored where. The procedure is what makes the methodology reproducible, different people running the procedure at different times should produce comparable outputs.

The procedure document contains: (a) the eight-move sequence; (b) the templates and forms used at each move; (c) the workshop facilitation guides; (d) the integration touchpoints with Clause 6.2, 8.2, 8.3, 8.5, 9.1, 9.3; (e) the version control and review cycle; (f) the escalation paths.

The Risk and Opportunity Register

The register is the working artefact, the single source of truth for every identified risk and opportunity. The register can be a spreadsheet, a database, or a GRC platform module; the structure is the same regardless of the medium.

A conformant register contains for each risk: unique ID; scenario description; risk source (one of the eleven families); Risk Owner (named individual); date identified; identification method; existing controls; likelihood rating and rationale; consequence rating and rationale; inherent rating; treatment decision (avoid / mitigate / transfer / accept); treatment action description; treatment action owner; target date; expected residual rating; actual residual rating at next review; review date; status (open / in-treatment / treated / accepted / closed).

For each opportunity: unique ID; description; opportunity source (one of the six patterns); Opportunity Owner (named individual); date identified; potential benefit (qualitative or quantitative); capture decision (exploit / share / enhance / accept-by-inaction); capture action description; capture action owner; target date; expected benefit realisation; actual benefit at next review; review date; status.

The Risk Treatment Plan

The treatment plan is the sequenced action list, the operational output of the register. It is what the BCM Steering Committee tracks at every meeting. The treatment plan is typically a single sheet derived from the register, sorted by priority, with milestone dates.

The treatment plan contains for each action: action ID; source risk or opportunity ID; action description; owner; start date; target date; milestones; resources required; current status; blockers; next report date. The plan is reviewed monthly by the BCM Manager and quarterly by the BCM Steering Committee.

The Risk Acceptance Log

The risk-acceptance log captures every residual risk accepted at top-management level. The log is a separate document (or a clearly demarcated part of the register) that records: the accepted risk ID; the residual rating; the acceptor (named top-management individual or committee); the rationale; the conditions of acceptance (e.g., "accepted until the Q3 treatment action completes"); the review date; the next review owner.

The log is what proves to the auditor that risk acceptance is deliberate and authorised, not silent drift. A register with high-rated residual risks and no corresponding acceptance-log entries is a Stage 1 nonconformity waiting to happen.

Risk Assessment and Treatment

This section walks through a worked 6.1 risk assessment and treatment cycle, using a representative Indian growing-company scenario. The intent is to show what a conformant implementation looks like in practice, not to provide a universal template, every organisation's risk register is context-specific.

The worked scenario

Consider Trinetra Biosciences, a Hyderabad-based pharmaceutical-API manufacturer with 380 staff, ISO 22301:2019 certification scope covering the API manufacturing and export business, and a customer base including US and EU pharmaceutical companies. The 6.1 cycle runs quarterly with an annual full refresh; the worked example below is from a recent cycle.

Risk identification, five representative entries

The cycle surfaced five BCMS-level risks from five of the eleven scenario families:

R-2026-014 (Leadership). The Executive Sponsor (COO) is approaching retirement in 18 months; no successor has been named; the BCM Steering Committee has not discussed the succession. Risk source: Family 1 (leadership and governance). Risk Owner: CEO. Existing controls: none. Likelihood: likely (3 on a 5-band scale). Consequence: major (4 on a 5-band scale), leadership transition is exactly when BCMSs drift. Inherent rating: high.

R-2026-015 (Methodology). The 2022 BCMS risk methodology does not include climate-related risk explicitly, despite ISO 22301:2019 Amendment 1:2024 having added climate as a Clause 4.1 context consideration. Risk source: Family 2 (methodology). Risk Owner: BCM Manager. Existing controls: partial, climate is implicitly in some scenarios. Likelihood: almost certain (5), the gap is certain. Consequence: moderate (3). Inherent rating: high.

R-2026-016 (Regulatory). DPDP Act 2023 may classify Trinetra as a Significant Data Fiduciary given the volume of customer and employee personal data; SDF status triggers DPIA, periodic security audit, and DPO obligations that the BCMS does not currently accommodate. Risk source: Family 4 (regulatory). Risk Owner: CISO. Existing controls: gap assessment under way. Likelihood: possible (3). Consequence: major (4), non-compliance penalty up to ₹250 crore. Inherent rating: high.

R-2026-017 (Supplier). A single Indian logistics partner handles 92% of export shipments to EU customers; the partner's BCP/DR has not been re-audited since 2023. Risk source: Family 5 (supplier). Risk Owner: Head of Supply Chain. Existing controls: contractual BCM clauses (not recently enforced). Likelihood: possible (3). Consequence: major (4), single-source concentration threatens export continuity. Inherent rating: high.

R-2026-018 (Cyber, BCMS-level). The BCM document repository (including the BIA, the contact tree, and the plans) is hosted on the corporate SharePoint tenant with no offline copy; a ransomware incident that encrypts SharePoint would disable the BCMS itself. Risk source: Family 9 (cyber, BCMS-level). Risk Owner: CISO. Existing controls: SharePoint backup exists but is on the same identity provider. Likelihood: unlikely (2). Consequence: severe (5), BCMS-availability failure. Inherent rating: high.

Opportunity identification, three representative entries

The cycle surfaced three BCMS-level opportunities:

O-2026-007 (Regulatory-shift). A major EU pharmaceutical customer issued a tender requiring DORA-aligned ICT continuity (DORA Arts 11, 12, 19, 26) for vendors handling personal data of EU data subjects; Trinetra's BCMS could be enhanced to demonstrate DORA alignment and win the contract. Opportunity source: regulatory-shift pattern. Opportunity Owner: VP Business Development. Potential benefit: ₹14 crore per year in new revenue. Capture decision: exploit.

O-2026-008 (Technology-shift). Immutable backup as a service has become affordable in India (cost down ~60% in 18 months); deployment across critical systems would reduce ransomware consequence and reduce cyber-insurance premium. Opportunity source: technology-shift pattern. Opportunity Owner: CISO. Potential benefit: ₹1.2 crore per year in insurance premium reduction plus reduced risk. Capture decision: exploit.

O-2026-009 (Insurance-and-finance). Trinetra's cyber-insurance broker indicated that a documented BCMS risk methodology with quarterly refresh would qualify for a 15-20% premium reduction at renewal. Opportunity source: insurance-and-finance pattern. Opportunity Owner: CFO. Potential benefit: ₹40 lakh per year. Capture decision: exploit (already implementing).

Treatment decisions

For each risk, the treatment decision was documented with rationale, action owner, target date, and expected residual:

• R-2026-014 (leadership succession). Mitigate. Action: COO succession planning process launched with board, including BCM Steering Committee continuity as an explicit criterion. Owner: CEO. Target: 6 months. Expected residual: low.
• R-2026-015 (climate in methodology). Mitigate. Action: methodology revised to explicitly include climate scenarios per Amd 1:2024; scenario library extended. Owner: BCM Manager. Target: 3 months. Expected residual: low.
• R-2026-016 (DPDP SDF status). Mitigate + transfer. Mitigate: DPIA commissioned; SDF readiness assessment completed; DPO role scoped. Transfer: outside legal counsel engaged for SDF notification strategy. Owner: CISO. Target: 9 months. Expected residual: medium.
• R-2026-017 (logistics concentration). Mitigate. Action: second logistics partner onboarded for 30% of EU export volume; contractual BCM clauses enforced with audit rights; quarterly BCP review with primary partner. Owner: Head of Supply Chain. Target: 6 months. Expected residual: medium.
• R-2026-018 (BCM documents offline). Mitigate. Action: offline immutable copy of all BCM documents established, with quarterly restore tests; identity-provider diversified so SharePoint outage does not lock out the offline copy. Owner: CISO. Target: 4 months. Expected residual: low.

For each opportunity, the capture decision was similarly documented with rationale, action owner, target date, and expected benefit. The treatment plan aggregated all eight actions with milestones and reporting cadence.

Integration

The integration map wired the 6.1 outputs into the rest of the BCMS:

• The R-2026-014 leadership-succession risk generated a Clause 6.2 objective: "complete COO succession with documented BCM continuity by [date]."
• The R-2026-017 logistics-concentration risk challenged the BIA assumption that the EU export activity would meet RTO with current supplier arrangements; the BIA was updated to reflect the second partner.
• The R-2026-018 BCM-document-offline risk was added to the next Clause 8.5 exercise scenario library, the next exercise would test access to BCM documents during a SharePoint outage.
• The O-2026-007 DORA-alignment opportunity generated a Clause 6.2 objective: "achieve demonstrable DORA alignment by [date] to support [customer] tender."
• The full residual risk position was added to the next Clause 9.3 management review input set, with the top-5 residuals highlighted for top-management discussion.

The integration is what makes the 6.1 outputs load-bearing; without it, the register is documentation only.

The risk-criteria matrix (worked illustration)

The risk-criteria matrix is the evaluation tool that combines likelihood and consequence into a rating. The worked matrix for Trinetra is a 5-by-5 grid with the following structure (likelihood bands on one axis, consequence bands on the other):

Treatment authority levels: Low (BCM Manager can accept); Medium (Executive Sponsor can accept); High (Steering Committee accepts); Critical (Board Risk Committee accepts with time-bound remediation plan). The matrix is calibrated to the organisation's risk appetite, a more risk-averse organisation shifts the boundaries toward "high" and "critical"; a less risk-averse organisation shifts the boundaries toward "low" and "medium."

Common treatment-decision patterns

Across many Indian 6.1 implementations, six treatment patterns recur. First, key-person concentration is almost always mitigate-via-deputy-and-cross-training, often with transfer via cyber-insurance or key-person insurance. Second, single-supplier concentration is mitigate-via-second-source plus transfer via contractual indemnity. Third, methodology drift is mitigate-via-annual-review-cycle with explicit triggers. Fourth, regulatory shift is typically mitigate-via-compliance-project plus transfer via outside counsel for novel questions. Fifth, leadership disengagement is mitigate-via-Steering-Committee-cadence and escalate to top management. Sixth, BCM-document-availability is mitigate-via-offline-copy plus transfer via immutable backup.

Risk acceptance, when "accept" is the right answer

Risk acceptance is not failure. For risks where treatment cost exceeds benefit, where the risk is below the threshold, or where no feasible treatment exists, acceptance is the correct decision. The risk-acceptance log captures the rationale; the audit test is whether the acceptance was deliberate and authorised, not whether it was avoided. A register with zero accepted risks is a register where someone is not making decisions.

Audit and Compliance Checklist

The certification auditor (and the internal auditor per Clause 9.2) tests 6.1 against a consistent set of evidence and interview questions. This section provides a 25-question audit checklist with the expected evidence and the red flags.

Methodology and charter

Q1. Show me the BCMS Risk and Opportunity Assessment Charter. Expected evidence: a single document specifying scope, methodology, criteria, scales, treatment categories, authority levels, review cadence, owner assignments, approved by the BCM Steering Committee. Red flag: no charter, or a charter without approval, or a charter whose criteria do not match the register.

Q2. What methodology did you use and why? Expected evidence: methodology section in the charter naming the framework borrowed from (ISO 31000, NIST SP 800-30, etc.) with rationale. Red flag: "we just used a spreadsheet" with no documented methodology.

Q3. Show me the likelihood scale. Expected evidence: a documented scale (typically 5-band) with definitions and quantitative anchors. Red flag: a 3-band scale with no anchors, or a scale where every risk lands at the same rating.

Q4. Show me the consequence scale. Expected evidence: a documented scale (typically 5-band) with definitions calibrated to BCMS outcomes. Red flag: a scale calibrated to financial impact only, ignoring continuity-of-prioritised-activity impact.

Q5. Show me the risk-criteria matrix. Expected evidence: a grid combining likelihood and consequence into ratings, with treatment authority levels per zone. Red flag: no matrix, or a matrix without authority levels.

Register and identification

Q6. Show me the BCMS risk register. Expected evidence: a structured register with unique IDs, scenario descriptions, owners, ratings, treatment decisions, residual positions, review dates. Red flag: a register without owner names, or with every owner being the BCM Manager.

Q7. How did you identify the risks? Expected evidence: documented identification process, leadership interviews, function workshops, BIA cross-reference, lessons-input review. Red flag: "the BCM Manager wrote it" with no documented process.

Q8. Show me the scenario library. Expected evidence: a catalogue of BCMS-level scenarios across the eleven families (or equivalent), customised to the organisation's context. Red flag: no scenario library, or a library that duplicates the Clause 8.2 disruption-scenario library.

Q9. How do you distinguish 6.1 risks from 8.2 risks? Expected evidence: a documented demarcation test (the BCMS-vs-prioritised-activity test) applied to each entry. Red flag: registers that duplicate each other's content.

Q10. Show me the opportunity register. Expected evidence: a register with opportunities, owners, capture decisions, expected benefit. Red flag: an empty opportunity register, or one with generic entries ("improve BCM maturity").

Analysis and evaluation

Q11. Walk me through the analysis of risk [X]. Expected evidence: the likelihood and consequence ratings with rationale, the existing controls, the inherent rating, the residual rating, the analysis date. Red flag: ratings with no rationale, or ratings that do not match the criteria.

Q12. How do you ensure analysis consistency across risks? Expected evidence: a structured workshop with Risk Owners, plus a red-team challenge (typically the CISO or Head of Risk). Red flag: the BCM Manager single-handedly rating all risks.

Treatment and capture decisions

Q13. Walk me through the treatment decision for risk [X]. Expected evidence: the treatment option selected (avoid/mitigate/transfer/accept), the rationale, the action owner, the target date, the expected residual. Red flag: "accept" for every high-rated risk with no rationale.

Q14. Show me the risk treatment plan. Expected evidence: a sequenced action list with milestones, owners, dates, and reporting cadence. Red flag: a treatment plan with no dates, or with every action owned by the BCM Manager.

Q15. Show me the risk-acceptance log. Expected evidence: every high-or-critical residual accepted at top-management level with rationale, acceptor, review date. Red flag: accepted risks with no named acceptor, or accepted by the BCM Manager alone.

Q16. Walk me through the capture decision for opportunity [Y]. Expected evidence: the capture option selected (exploit/share/enhance/accept-by-inaction), the rationale, the action owner, the target date, the expected benefit. Red flag: no capture decisions, or "accept-by-inaction" for every opportunity.

Integration

Q17. How does the risk register feed the Clause 6.2 objectives? Expected evidence: each high-or-critical residual risk maps to a Clause 6.2 objective. Red flag: no mapping, or 6.2 objectives that have no link to 6.1 risks.

Q18. How does the risk register feed the Clause 8.2 BIA? Expected evidence: the BIA assumptions are stress-tested against the 6.1 register; cross-references exist. Red flag: BIA and 6.1 register operate in isolation.

Q19. How does the risk register feed the Clause 8.3 strategy? Expected evidence: strategy selection rationale references the 6.1 outputs. Red flag: strategy selection with no reference to 6.1 risks.

Q20. How does the risk register feed the Clause 9.3 management review? Expected evidence: the management review input set includes the residual risk position; minutes record top-management discussion. Red flag: no 6.1 input to the management review.

Monitoring and review

Q21. Show me the review cadence and the last three reviews. Expected evidence: documented quarterly (or other) cadence plus event triggers, with minutes of the last three reviews. Red flag: no reviews since the last audit.

Q22. What triggers an interim review? Expected evidence: defined event triggers, change per Clause 6.3, incident per Clause 8.6, audit finding per Clause 9.2, regulatory shift, BIA change, threat intelligence. Red flag: "we review annually" with no event triggers.

Q23. Show me the KPI dashboard for 6.1. Expected evidence: the Section 12 KPIs (or equivalent) tracked over time with trends. Red flag: no KPIs, or KPIs with no trend data.

Documented information

Q24. Show me the Documented Information control for the register. Expected evidence: version history, approvals, review triggers, retention per Clause 7.5. Red flag: unversioned register, or no approval, or no review history.

Q25. How do you ensure the register is accessible to those who need it? Expected evidence: access controls, distribution list, awareness per Clause 7.3. Red flag: register lives only on the BCM Manager's laptop.

Metrics and KPIs

A 6.1-conformant BCMS measures its risk-and-opportunity performance with a small, meaningful KPI set. Too many KPIs produce noise; too few produce blindness. The recommended set has 12 KPIs across four categories.

Coverage KPIs

KPI-1. Risk register coverage ratio. Formula: (number of in-scope BCMS activities with at least one identified risk) / (total in-scope BCMS activities). Target: 100%. Frequency: quarterly. Why it matters: gaps in coverage mean risks the organisation is not seeing.

KPI-2. Scenario-library coverage. Formula: (scenario families with at least one entry in the register) / (total scenario families in the library). Target: 100% for the eleven families. Frequency: annually. Why it matters: a scenario family with no entries is either genuinely absent or genuinely blind.

KPI-3. Risk-owner assignment ratio. Formula: (number of risks with a named Risk Owner who is not the BCM Manager) / (total risks). Target: ≥90%. Frequency: quarterly. Why it matters: a register where every risk is owned by the BCM Manager is a register without ownership.

Treatment KPIs

KPI-4. Treatment-action on-time completion rate. Formula: (number of treatment actions completed by target date) / (number due). Target: ≥85%. Frequency: monthly. Why it matters: overdue treatments are risks not being addressed.

KPI-5. Overdue-treatment-action count. Formula: count of treatment actions past target date. Target: zero; trend downward. Frequency: monthly. Why it matters: the count is a single number the Steering Committee can track.

KPI-6. Treatment effectiveness ratio. Formula: (number of risks whose residual rating was reduced as planned) / (number of treatments completed). Target: ≥80%. Frequency: quarterly. Why it matters: treatments that do not reduce residual are treatments that need redesign.

Residual-risk and acceptance KPIs

KPI-7. High-or-critical residual risk count. Formula: count of risks with residual rating "high" or "critical". Target: trend downward over time; spike triggers root-cause analysis. Frequency: quarterly. Why it matters: the headline residual position reported to top management.

KPI-8. Risk-acceptance-log coverage. Formula: (number of accepted high-or-critical residuals with documented acceptor and rationale) / (total high-or-critical residuals). Target: 100%. Frequency: quarterly. Why it matters: silent drift is the failure mode this KPI catches.

KPI-9. Average days-since-last-review per risk. Formula: average of (today − last review date) across all open risks. Target: ≤90 days for a quarterly-cycle BCMS. Frequency: monthly. Why it matters: stale entries are entries no one is owning.

Opportunity and integration KPIs

KPI-10. Opportunity-capture rate. Formula: (number of opportunities with capture decision "exploit", "share", or "enhance") / (total opportunities identified). Target: ≥40%, the rest may be consciously declined. Frequency: quarterly. Why it matters: an opportunity register with no capture decisions is documentation, not action.

KPI-11. Opportunity-benefit realisation. Formula: (actual benefit captured) / (expected benefit at capture decision), aggregated across mature opportunities. Target: ≥70%. Frequency: annually. Why it matters: validates that the opportunity pipeline produces real value.

KPI-12. 6.1-to-6.2 objective linkage. Formula: (number of Clause 6.2 objectives with a documented source in a 6.1 risk or opportunity) / (total 6.2 objectives). Target: ≥80%. Frequency: annually. Why it matters: confirms the integration path is wired up.

Reporting cadence

The 12 KPIs report at three cadences. Monthly to the BCM Manager (KPI-4, KPI-5, KPI-9). Quarterly to the BCM Steering Committee (all KPIs). Annually to top management in the Clause 9.3 management review (all KPIs with annual trend). The dashboard layout is the same at all three levels, the difference is the depth of commentary, not the structure of the data.

Benchmarking

Indian growing companies can benchmark their KPI trajectory against sector norms. BFSI: RBI MD IT Governance expectations push KPI-4 (on-time completion) above 90% and KPI-7 (high-or-critical residual count) onto the board Risk Committee agenda. SEBI-regulated: CSCRF 2024 pushes KPI-2 (scenario-library coverage) to include cyber scenarios explicitly. Healthcare: DPDP and the post-AIIMS 2022 environment push KPI-1 (coverage ratio) above 95%. Manufacturing: NDMA chemical-disaster guidelines push scenario-library coverage of industrial-hazard families. Sector benchmarking is illustrative; the organisation's own baseline and trend are more important than external comparison.

Common Pitfalls and Audit Failures

Thirteen anti-patterns account for the majority of 6.1 audit findings in the Indian growing-company segment. Each is named, explained, and paired with the corrective action.

Pitfall 1, The register-as-documentation. The spreadsheet exists for the auditor, not for the business; the leadership team has never read it; the BCM Manager updates it the night before the surveillance audit. Correction: wire the register into the BCM Steering Committee agenda so it is opened at every meeting; produce a one-page top-10 risks summary for the executive committee.

Pitfall 2, The 6.1/8.2 confusion. The 6.1 register duplicates the 8.2 disruption-risk register, with no demarcation test applied. Correction: apply the BCMS-vs-prioritised-activity test to every entry; cross-reference where both apply; train the Risk Owners on the distinction.

Pitfall 3, The empty opportunity column. The opportunity register is empty or has generic entries, while the risk register is full. Correction: run a leadership opportunity workshop using the six opportunity patterns in Section 2.4; require at least three opportunities per cycle.

Pitfall 4, BCM Manager as universal owner. Every risk has the BCM Manager as Risk Owner. Correction: assign Risk Owners by domain (CISO for cyber, Head of Operations for process, Head of Procurement for supplier); the BCM Manager is custodian, not universal owner.

Pitfall 5, Methodology drift. The methodology was written years ago and has not been refreshed; the threat landscape has moved; the criteria no longer match observed frequency. Correction: annual methodology review with explicit triggers; include climate (per Amd 1:2024), AI, supply-chain cyber, and other contemporary scenario families.

Pitfall 6, Inconsistent ratings. Risks of obviously different severity end up with the same rating because the BCM Manager single-handedly rated them. Correction: run analysis as a workshop with Risk Owners; add a red-team challenge.

Pitfall 7, Accept-without-authority. High-rated residual risks are accepted by the BCM Manager without top-management sign-off. Correction: enforce the authority levels in the charter; maintain the risk-acceptance log with named acceptors.

Pitfall 8, Treatment plan without dates. The treatment plan has actions but no target dates, no milestones, no reporting. Correction: every action has a target date, an owner, and a Steering Committee reporting cadence.

Pitfall 9, Integration gap. The register exists and is current, but the 6.2 objectives, the 8.2 BIA, the 8.3 strategy, and the 9.3 management review do not use it. Correction: wire the six integration paths in Move 7 explicitly; audit them annually.

Pitfall 10, The once-a-year cycle. The register is reviewed annually with no event-triggered updates. Correction: define event triggers (change, incident, audit, regulatory, BIA, threat intel) and the corresponding update protocol.

Pitfall 11, No KPIs. The BCMS measures its risk-and-opportunity performance with no metrics. Correction: adopt the 12-KPI set in Section 12 (or equivalent); track trend, not just absolute value.

Pitfall 12, Inaccessible register. The register lives on the BCM Manager's laptop; no one else can find it; new starters do not know it exists. Correction: host on the controlled document repository with access controls and awareness per Clause 7.3.

Pitfall 13, No scenario library. The register has abstract risks ("cyber attack") with no scenario structure. Correction: build the scenario library from the eleven families in Section 7; convert every abstract risk into a scenario.

Illustrative Scenario 1: Failure, Kalpataru Precision Components (Illustrative)

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

Disclaimer: The following is an illustrative scenario. Kalpataru Precision Components is a fictional composite; the events, characters, and figures are representative of patterns seen in the Indian Tier-2 auto-component sector and are not a report of any specific real company or incident.

The company and the BCMS

Kalpataru Precision Components Pvt. Ltd. is a Pune-based Tier-2 auto-component manufacturer with 410 staff, ₹280 crore annual revenue, supplying precision-machined parts to two Indian OEM customers (70% of revenue) and one Korean OEM's Indian subsidiary (22% of revenue). The company achieved ISO 22301:2019 certification in March 2022 on the strength of a BCMS covering the Pune manufacturing and export business. The certification was driven by the Korean OEM's supplier BCM mandate.

The BCMS was built rapidly in 2021 to meet the customer deadline. The Clause 6.1 risk register was produced as a spreadsheet with 38 entries, most of them BCMS-generic ("loss of key supplier", "cyber attack", "pandemic"), rated medium across the board, with the BCM Manager (the Head of Quality, wearing a second hat) as Risk Owner for every entry. The opportunity register had two entries, both generic. The risk treatment plan had eight actions, all dated "Q4 2022", all owned by the BCM Manager. The BCM Steering Committee met twice in 2022 (charter and certification), then once in 2023 (the surveillance audit preparation).

What the register missed

Between certification in March 2022 and the failure event in late 2025, the BCMS context changed in ways the 6.1 register did not capture.

Customer concentration increased. The Korean OEM's share of revenue grew from 18% in 2022 to 35% in 2025 as the Indian OEMs reduced orders during a sectoral slowdown. The 6.1 register had no entry on customer-concentration risk; it was treated as a sales issue.

Single-source shipping concentration hardened. A single Mumbai-based freight forwarder handled 96% of export shipments by 2025; the alternative had been dropped during cost-cutting in 2023. The 6.1 register had one supplier-risk entry that pre-dated the consolidation.

OT migration introduced new cyber-risk. A 2024 Industry-4.0 upgrade connected previously air-gapped OT systems to the corporate network for real-time quality analytics. The 6.1 register had no OT-cyber entry; the BIA (8.2) had assumed OT was air-gapped.

Climate exposure shifted. The 2024 monsoon flooded the industrial estate twice; the 2025 monsoon was projected to be heavier. ISO 22301:2019 Amendment 1:2024 had added climate as an explicit Clause 4.1 context consideration; the Kalpataru methodology was not refreshed.

Leadership engagement drifted. The COO who had been the Executive Sponsor retired in early 2024; the replacement deferred to the CFO, who treated BCM as a Quality team responsibility. The 6.1 register had no entry on leadership-succession risk for the BCMS.

The opportunity was missed. A competitor (a 600-staff Tier-2 supplier in Gujarat) suffered a public ransomware incident in 2024 that took them offline for three weeks. Two of the Korean OEM's Tier-2 suppliers were asked to absorb volume. Kalpataru could have bid; the BCMS did not flag the opportunity because no one was looking for it.

The failure event

In late October 2025, a ransomware incident, propagated through the corporate network to the OT systems, encrypted both the primary ERP and its backups, halting production for six weeks. The freight forwarder simultaneously suffered a separate cyber incident that took its shipment-management system offline for ten days. The Korean OEM, with no alternate supplier onboarded, sourced emergency volume from a Thai Tier-2 supplier and publicly announced that Kalpataru had been removed from the preferred-supplier list pending "evidence of operational resilience."

The financial impact was severe. Six weeks of revenue lost: approximately ₹22 crore. Customer penalty from the Korean OEM for non-delivery: approximately ₹8 crore. Emergency recovery and remediation cost: approximately ₹6 crore. Surveillance audit nonconformity on Clause 6.1 (and 8.2, 8.4): certification suspended. Total direct cost: approximately ₹40 crore plus the loss of the largest customer.

Root causes, all 6.1 failures

The post-incident review (per Clause 8.6 and 10.1) identified five root causes, all of which were 6.1 failures.

First, the risk register was documentation, not a living artefact, it had not been refreshed since March 2022. Second, the methodology had not been reviewed, so it missed the OT-cyber, climate, customer-concentration, and supplier-concentration shifts. Third, the opportunity register had no capture decisions, so the 2024 competitor-incident opportunity was missed entirely. Fourth, the integration paths were broken, the BIA still assumed OT was air-gapped, the strategy still assumed a single freight forwarder, the 6.2 objectives had no link to the 6.1 risks. Fifth, the BCM Steering Committee had stopped meeting, so there was no forum to surface the drift.

Lessons specific to 6.1

The Kalpataru failure is a textbook 6.1 collapse. Every Clause 8.x technical artefact (BIA, strategy, plans, exercises) was weaker than it should have been because the 6.1 risk-and-opportunity system had failed. The lesson is that 6.1 is the upstream cause of BCMS effectiveness, get it wrong and the downstream artefacts degrade silently; get it right and the downstream artefacts stay honest.

The specific correctives: refresh the methodology annually; treat the opportunity register as mandatory; wire the integration paths explicitly; keep the BCM Steering Committee meeting; assign Risk Owners by domain; refresh on event triggers, not just calendar.

Illustrative Scenario 2: Success, Trinetra Biosciences (Illustrative, with ROI)

Disclaimer: The following is an illustrative scenario. Trinetra Biosciences is a fictional composite; the events, characters, and figures are representative of patterns seen in the Indian pharmaceutical-API sector and are not a report of any specific real company.

The company and the BCMS

Trinetra Biosciences Pvt. Ltd. is a Hyderabad-based pharmaceutical-API manufacturer with 380 staff, ₹420 crore annual revenue, exporting 65% of output to US and EU pharmaceutical customers. ISO 22301:2019 certified since 2020, with a BCMS scope covering API manufacturing, quality control, regulatory affairs, and export operations. The BCM Manager (a dedicated role since 2023) reports solid-line to the COO and dotted-line to the CEO; the BCM Steering Committee meets quarterly; the board Risk Committee (Trinetra is not listed but has voluntarily constituted one) receives a half-yearly BCM report.

The 6.1 system

Trinetra's 6.1 system was rebuilt in 2023 after a surveillance audit minor nonconformity on integration. The rebuild produced the eight-move architecture in Section 7 of this guide.

The charter was approved by the Steering Committee in April 2023. The methodology borrows from ISO 31000:2018 with a 5-band likelihood scale, a 5-band consequence scale calibrated to BCMS outcomes, and a 5-by-5 risk-criteria matrix. Treatment authority levels: BCM Manager accepts "low"; Executive Sponsor accepts "medium"; Steering Committee accepts "high"; board Risk Committee accepts "critical".

The scenario library has 142 BCMS-level scenarios across the eleven families, customised to pharmaceutical-API context (GMP continuity, regulatory cold-chain, controlled-substance handling, FDA/EDQM inspection readiness, single-reactor concentration, chemistry-manufacturing-controls drift). The opportunity library has 47 entries captured across three cycles.

The register runs at 96 active risks and 23 active opportunities as of the latest cycle. Risk Owners are named function owners (CISO for cyber, Head of Supply Chain for logistics, Head of QC for quality-continuity, Head of Regulatory for compliance, CFO for insurance, CEO for leadership-succession). The BCM Manager is methodology custodian, not universal owner. The opportunity register has captured ₹14 crore of new EU business (DORA-aligned continuity) and ₹1.6 crore of insurance premium reduction over the last two cycles.

The anticipated shock, and how 6.1 captured it

In mid-2025, Trinetra's compliance function flagged three regulatory shifts that would converge in 2026: the DPDP Rules 2025 finalisation (with possible SDF designation for Trinetra given customer and employee data volumes), the DORA application (already live since 17 January 2025 but now being enforced against non-EU vendors handling EU personal data), and the tightening of NDMA chemical-disaster guidelines after a near-miss at a peer manufacturer.

The standard reaction would have been to treat each regulation as a separate compliance project, run in parallel by separate functions, with no BCMS-level coordination. The 6.1 system produced a different response.

The BCM Manager convened a cross-functional 6.1 workshop in August 2025. The workshop surfaced six BCMS-level risks (DPDP SDF readiness gap, DORA-aligned-continuity evidence gap, NDMA-aligned emergency-response plan staleness, cross-regulatory overlap of breach-notification timelines, board Risk Committee skills gap on DPDP/DORA, BCM Manager single-point-of-knowledge on the cross-regulatory landscape) and three BCMS-level opportunities (DORA-aligned continuity as a sales argument to EU customers; DPDP readiness as a customer-trust differentiator; insurance premium reduction for demonstrated multi-regulator alignment).

The treatment decisions were sequenced into a single integrated plan: a 9-month, ₹1.8-crore programme covering DPDP SDF readiness, DORA-aligned continuity evidence package, NDMA-aligned emergency-response refresh, a unified breach-notification decision-tree, a board Risk Committee skills uplift (two new members with DPDP and DORA expertise), and deputy-cross-training on the cross-regulatory landscape.

The ROI

The programme delivered measurable returns over the following 24 months.

New EU contract won. A €3 million per year (₹27 crore) contract with a German pharmaceutical customer, whose tender explicitly required DORA-aligned ICT continuity, was awarded to Trinetra in Q1 2026. The customer's vendor evaluation noted Trinetra's 6.1 evidence set as the differentiator against two European competitors. Trinetra's capture: ₹14 crore of the contract (the rest depended on capacity allocation decisions).

Insurance premium reduced. The cyber-insurance renewal in Q2 2026 came in 18% lower than the prior year, reflecting the broker's assessment of the demonstrated BCM risk methodology. Saving: approximately ₹40 lakh per year.

Regulatory penalty avoided. A DPDP-related complaint in Q3 2026 (a vendor-side data incident that exposed Trinetra customer data) was managed within the 72-hour breach-notification window using the unified decision-tree; no DPDP penalty. Estimated avoided exposure: ₹8-15 crore (the range reflects DPDP Section 8(6) and Schedule penalties applied to a comparable incident).

Audit findings reduced. The 2026 surveillance audit produced zero major nonconformities (down from one in 2023 and two in 2024) and one minor on documentation formatting. The certification body's report explicitly cited the 6.1 system as a strength.

Speed of response. The September 2025 NDMA-led inspection of the Hyderabad facility was completed in 1.5 days (industry norm 3-5 days) because the BCMS documentation was current and the inspection-readiness was driven by the same risk register.

Total realised value over 24 months: ₹14 cr new business + ₹0.8 cr insurance saving + ₹8-15 cr avoided penalty + uncounted cost savings = ₹22-30 crore against ₹1.8 crore invested. ROI: 12x to 17x over 24 months. The 6.1 programme was the highest-ROI investment the BCMS made in the period.

Why 6.1 was the cause of success

Every element of the Trinetra success traces back to a 6.1 move. The integrated regulatory response was a Move 4 opportunity-identification output. The sales differentiation was a Move 6 capture-decision output. The unified breach-notification decision-tree was a Move 6 treatment action. The board Risk Committee skills uplift was a Move 7 integration action. The insurance premium reduction was a Move 8 monitoring KPI (KPI-11 opportunity-benefit realisation). The reduction in audit findings was the cumulative effect of a load-bearing rather than documentary 6.1 system.

The lesson is that 6.1 is the highest-use clause in ISO 22301 for organisations willing to invest in it as a thinking system rather than a documentation artefact. The Trinetra pattern is replicable across regulated Indian sectors, pharmaceutical, BFSI, IT/ITeS, manufacturing, where regulatory tightening creates both risks to manage and opportunities to capture.

Multi-Framework Mapping

The 6.1 obligation maps to a structured set of anchors across global frameworks and Indian regulations. The mapping below shows the primary anchor for each framework; the full crosswalk (including secondary anchors) is in toolkit document 17.

ISO management-system parallels

Sector / prudential frameworks

Indian regulatory anchors

SOC 2 trust-services mapping

For organisations seeking SOC 2 alignment alongside ISO 22301, the 6.1 obligation maps to the Common Criteria risk-assessment principles: CC3.1 (the entity specifies objectives to enable identification and assessment of risks), CC3.2 (the entity identifies risks), CC3.3 (the entity assesses risks), CC3.4 (the entity considers the potential for fraud), and the Availability criteria around resilience risk. The mapping is bidirectional, an ISO 22301 6.1 evidence set produces strong SOC 2 risk-assessment evidence.

How the mapping is used in an integrated audit

For organisations running multiple management systems (ISO 22301 + ISO 27001 + ISO 9001), an integrated audit tests the 6.1 clauses of all three standards together. The auditor walks a sample of risks through all three registers to confirm consistency. The integration is enabled by the Harmonized Structure, the same clause number (6.1) and the same paired risks-and-opportunities construction across ISO management-system standards.

For organisations responding to sector regulators (RBI, SEBI, IRDAI, CERT-In, DPDP, NDMA), the 6.1 evidence set is the single most reusable artefact. The same risk register, with appropriate tagging, satisfies the RBI MD IT risk chapter, the SEBI CSCRF Identify function, the IRDAI risk assessment, the CERT-In incident-category identification, the DPDP SDF DPIA input, and the NDMA industrial-hazard identification. The toolkit's regulatory crosswalk (document 17) provides the clause-level mapping.

Implementation Roadmap

The 6.1 implementation roadmap for a first-cycle Indian growing-company BCMS is sequenced across four horizons. The roadmap assumes a 50-to-250-staff organisation; mid-market (250 to 2,000 staff) and enterprise implementations extend each horizon proportionally.

Days 0-30, Foundation

The first 30 days establish the foundation. Week 1: charter the assessment, convene the BCM Steering Committee, agree the scope, name the methodology (default: ISO 31000:2018), set the criteria, draft the charter for approval. Week 2: build the scenario library, workshop with the BCM Manager, the Executive Sponsor, the CISO, the Head of Operations, and the Head of Procurement to populate the eleven scenario families with organisation-specific entries. Week 3: build the risk-criteria matrix, agree the likelihood scale, the consequence scale, the matrix, and the treatment authority levels. Week 4: identify the risks, run the leadership interviews and the first function workshops; populate the register with first-pass entries.

Milestones at Day 30: charter approved; scenario library drafted; risk-criteria matrix approved; register with first-pass entries; opportunity register started.

Days 31-90, Analysis and decisions

Days 31-60: complete the risk identification across all functions; complete the opportunity identification; run the analysis workshop with Risk Owners and a red-team challenge. Days 61-90: select treatment and capture decisions for every entry; build the risk treatment plan; build the risk-acceptance log; wire the integration paths to Clause 6.2 objectives and the Clause 8.2 BIA.

Milestones at Day 90: register fully analysed; treatment plan sequenced with owners and dates; integration map documented; first BCM Steering Committee review of the residual position.

Days 91-180, Integration and operation

Days 91-150: execute the first wave of treatment actions; integrate the register outputs into the Clause 9.1 monitoring set; brief top management on the residual position. Days 151-180: run the first quarterly review cycle; refresh the register based on event triggers; produce the first 6.1 input to the Clause 9.3 management review.

Milestones at Day 180: treatment plan 50% complete; first quarterly review held; first 6.1 input to 9.3 delivered; surveillance-audit readiness demonstrated.

Days 181-365, Maturity advancement

Days 181-365: complete the first wave of treatment actions; capture the first opportunity benefits; advance the methodology (introduce quantitative dimensions for high-rated risks; add climate per Amd 1:2024; add AI-related risk); prepare for the next maturity level (Section 22).

Milestones at Day 365: treatment plan ≥85% complete; opportunity-capture rate ≥40%; methodology reviewed and advanced; first annual trend of the KPIs available.

Resource plan

The roadmap assumes a part-time BCM Manager (50-60% allocation during Days 0-180, 30% thereafter), an Executive Sponsor (5-10% allocation throughout), function owners (2-5% allocation during identification and analysis phases), and limited external facilitation (a 6.1 specialist for the workshop design and facilitation). Internal cost for a 50-to-250-staff growing company: typically 6-12 lakh rupees of internal effort across the first year. External facilitation (optional but recommended for first-cycle implementations): typically 4-10 lakh rupees depending on scope and depth. Tooling (Layer 1 spreadsheet-and-repository): negligible.

Beyond Year 1, the cadence

From Year 2 onward, the 6.1 cycle settles into a cadence: quarterly register review, annual methodology review, event-triggered updates, annual maturity advancement. The 6.1 system becomes a routine part of the BCM Steering Committee's work; the artefacts are refreshed without drama; the integration paths are tested at each Clause 8.5 exercise cycle and at each Clause 9.3 management review.

FAQ

Twenty questions cover the recurring 6.1 queries from Indian growing-company BCMS implementations.

Q1. Is 6.1 the same as Clause 8.2 risk assessment? No. 6.1 is BCMS-level, risks and opportunities that affect the BCMS achieving its outcomes. 8.2 is prioritised-activity-level, disruption impacts and risks to specific business activities. They feed each other but produce separate registers. See Section 2.3.

Q2. Do we have to use ISO 31000 as our methodology? No. ISO 22301 does not mandate a specific methodology. ISO 31000 is the default for many Indian BCMSs because it is methodology-agnostic and pairs cleanly with the Harmonized Structure. Alternatives: NIST SP 800-30, OCTAVE, sector-practitioner BCM methodologies. The choice is documented in the charter.

Q3. How many risks should our register have? For a 50-to-250-staff growing company, a register of 30-60 entries is typical; for mid-market (250 to 2,000 staff), 80-150; for enterprise, 200+. The number is less important than the coverage, every BCMS scenario family should have at least one entry, and every high-rated risk should have a documented treatment decision.

Q4. Do we need software to manage the register? No. A spreadsheet is conformant. A GRC platform is leading practice at the mid-market (250 to 2,000 staff) stage and above, but the certification audit does not require it. The standard requires the register to be controlled, versioned, and accessible, properties a well-managed spreadsheet has.

Q5. What if our opportunity register is genuinely empty? It almost certainly is not. Opportunities surface in six recurring patterns (regulatory shift, sector shock, technology shift, contract-win, insurance-and-finance, people-and-culture). A leadership workshop using these patterns as prompts typically surfaces 5-10 opportunities per cycle. An empty opportunity register after such a workshop is a Stage 1 finding waiting to happen.

Q6. Can the BCM Manager accept all the risks? No. The charter specifies authority levels. Typically: BCM Manager accepts "low"; Executive Sponsor accepts "medium"; Steering Committee accepts "high"; board Risk Committee accepts "critical". The BCM Manager single-handedly accepting high-rated residual risks is a nonconformity.

Q7. How often must the register be reviewed? At least quarterly (calendar cadence) plus event-triggered reviews (significant change per Clause 6.3, incident per Clause 8.6, audit finding per Clause 9.2, regulatory shift, BIA change, threat intelligence). Annual-only reviews with no event triggers are a finding.

Q8. Do we need quantitative risk analysis (monte-carlo, FAIR, ALE)? No. Qualitative scales are sufficient for ISO 22301 baseline conformity. Quantitative analysis is leading practice in L4-L5 maturity and is implied by some sector frameworks (DORA Art 11(5) qualitative + quantitative criteria; APRA CPS 230 para 27(c) scenario analysis).

Q9. How do we handle risks that overlap with 8.2? Test each entry against the demarcation: does this risk affect the BCMS itself (6.1) or the underlying business being disrupted (8.2)? If both, it goes in both registers with a cross-reference. Ransomware is the classic overlap, it is a 6.1 risk (BCMS-document availability, BCM Manager capacity to manage) and an 8.2 risk (disruption to prioritised activities).

Q10. Does the BCM Manager have to be the Risk Owner for every risk? No, and should not be. Risk Owners are function owners in whose domain the risk lives. The BCM Manager is methodology custodian. A register where every risk has the BCM Manager as owner is a register without ownership.

Q11. How do we incorporate climate per Amendment 1:2024? The methodology must explicitly include climate as a Clause 4.1 context consideration (per Amd 1:2024). The scenario library must include climate-driven risk entries (extreme-weather frequency, coastal exposure, water stress, heat-island DC cooling). The integration map must feed climate risks into the BIA and strategy.

Q12. How does DPDP Act 2023 affect 6.1? DPDP adds two BCMS risk categories: the availability duty (Section 8(5)) and the breach-notification duty (Section 8(6)). For Significant Data Fiduciaries, DPDP Rules 2025 add DPIA, periodic security audits, and DPO obligations, all of which become 6.1 risks if the SDF status is contested or the cadence slips. Penalties up to ₹250 crore (security safeguard failure) and ₹200 crore (breach notification failure) raise the financial stakes.

Q13. How do we map 6.1 to RBI Master Direction IT Governance? The RBI MD IT risk chapter (7 Nov 2023, eff 1 Apr 2024) is the regulatory restatement of 6.1 for banks, NBFCs, CICs, and AIFIs. The same BCMS risk methodology, with RBI-specific scenario families (CCMP, SOC, third-party), satisfies both ISO 22301 6.1 and the RBI MD.

Q14. How do we map 6.1 to SEBI CSCRF? The SEBI CSCRF Identify function (20 Aug 2024) maps to 6.1 risk identification. The other CSCRF functions (Protect, Detect, Respond, Recover, Learn) consume the Identify outputs. The 6.1 register, tagged with CSCRF function references, satisfies both ISO 22301 and CSCRF.

Q15. How do we handle DORA for our EU business? DORA Arts 6-16 mandate a documented ICT risk management framework for EU financial entities and their critical ICT third-party service providers. If your Indian IT/BPO serves EU financial entities, your 6.1 methodology, with DORA-specific scenarios and evidence, satisfies DORA Art 6 and ISO 22301 6.1 simultaneously.

Q16. Can we integrate 6.1 with our ISO 27001 ISMS risk register? Yes, and you should. The methodologies should align (same likelihood scale, same consequence scale where the domain overlaps). The registers are separate (different risk populations) but cross-referenced (cyber-attack scenarios appear in both). Integration avoids duplicate work and conflicting ratings.

Q17. What if a high-rated risk cannot be treated cost-effectively? Accept the residual with documented rationale, acceptor at the right authority level (Steering Committee or board Risk Committee), and review date. Risk acceptance is legitimate; silent drift is not.

Q18. How do we demonstrate opportunity capture to the auditor? Show the opportunity register with capture decisions, action owners, target dates, and expected benefit. Show the realised benefit at the next review. Show the linkage from opportunity to Clause 6.2 objective where applicable. Quantitative ROI (as in the Trinetra case) is leading practice; qualitative benefit descriptions are sufficient.

Q19. What is the single most common 6.1 audit finding? The register-as-documentation: the spreadsheet exists for the auditor, not for the business; the leadership team has never read it; the BCM Manager updates it the night before the audit. The corrective is to wire the register into the BCM Steering Committee agenda so it is opened at every meeting.

Q20. How long does a first-cycle 6.1 implementation take? For a 50-to-250-staff growing company: 4-8 weeks for the first risk-and-opportunity pass plus the methodology document and the first management-review integration. For mid-market (250 to 2,000 staff): 8-12 weeks. For multi-entity enterprise: 4-6 months with group ERM integration.

Industry-Specific Requirements

BFSI, banks, NBFCs, payment system operators

The BFSI sector has the heaviest Indian regulatory overlay on 6.1. The RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024) requires a documented, board-approved IT risk methodology covering identification, assessment, treatment, and monitoring. The RBI Cyber Security Framework (2 June 2016) requires a baseline cyber security risk assessment. The RBI MD on Outsourcing of IT Services (10 April 2023) requires supplier-concentration risk monitoring.

The 6.1 register for a BFSI entity typically has 80-200 entries with deep cyber, supplier, and regulatory-risk coverage. The BCM Steering Committee includes the CISO, the Head of IT, the Head of Operations, and the Compliance Officer; the board Risk Committee (mandated for SEBI LODR Reg. 21 listed banks and NBFCs) receives the residual position half-yearly. The scenario library emphasises CCMP scenarios (per the 2016 framework), SOC detection scenarios, third-party concentration scenarios (per the 2023 Outsourcing MD), and payment-system ecosystem scenarios (per the UPI/NPCI experience).

Capital markets, MIIs, brokers, AMCs

For SEBI-regulated Market Infrastructure Institutions, the SEBI MII BCP-DR circular (22 March 2021) requires documented risk assessment underpinning the BCP/DR plan. The SEBI CSCRF (20 August 2024) structures the Identify function as the upstream of Protect, Detect, Respond, Recover, and Learn. The 6.1 register for an MII covers exchange-trading-system continuity, clearing-and-settlement continuity, depository continuity, and the ecosystem dependencies (banks, PSPs, telecoms). The RTO/RPO-defined risk scenarios (per SEBI MII BCP-DR Near Site + DRS architecture) are explicit in the register.

Insurance

For IRDAI-regulated insurers, the Information and Cyber Security Guidelines (24 April 2023) require a board-approved Information and Cyber Security Policy including BCP/DR, with explicit BCP/DR oversight by the board's Risk or IT committee. The 6.1 register for an insurer covers policy-administration continuity, claims-continuity (a regulated critical operation per the APRA CPS 230 analogue), reinsurance counterparty risk, and the regulatory reporting continuity. The 180-day log retention requirement (aligned with CERT-In) is treated as a 6.1 BCMS risk if the log retention is itself disrupted.

Healthcare and pharma

For healthcare and pharmaceutical organisations, the post-AIIMS 2022 environment makes clinical-continuity, clinical-data-availability, and OT-continuity central 6.1 risks. The DPDP Act 2023 (health data is sensitive personal data under DPDP) raises the stakes on patient-data availability. The NDMA chemical-disaster guidelines (2007) require industrial-hazard identification for API and bulk-drug manufacturers. The 6.1 register for a pharmaceutical API manufacturer covers single-reactor concentration, GMP continuity, regulatory cold-chain, controlled-substance handling, FDA/EDQM inspection readiness, and the OT/IT segmentation risk that the LG Polymers Vizag 2020 incident made tragically visible.

IT/ITeS and SaaS

For IT services, BPO, and SaaS companies, the 6.1 register covers customer-SLA continuity, multi-tenant platform availability, customer-data segregation, the dependency-on-customer-side-incidents pattern (your customer has a breach; your service is implicated), and the cross-border regulatory pattern (DORA for EU customers, APRA CPS 230 for Australian customers, MAS TRM for Singapore customers). The 2024-2025 SaaS-outage incidents (CrowdStrike, the CDK Global ransomware that took down 15,000 auto dealerships) are scenario-library inputs.

Manufacturing and critical infrastructure

For manufacturing and critical infrastructure (power, telecom, transportation, oil and gas), the 6.1 register covers OT/IT segmentation, industrial-control-system continuity, single-source supplier concentration (the Go First / Pratt & Whitney engine lesson), industrial-hazard scenarios (per NDMA guidelines), and the grid-dependency scenario (the contested Mumbai October 2020 blackout attribution is the Indian reference). The Disaster Management Act 2005 industrial-disaster obligations and the Companies Act 2013 Section 134(3)(n) board risk-oversight are the regulatory anchors.

Government and public sector

For government departments, public-sector undertakings, and critical-information-infrastructure operators, the 6.1 register covers citizen-service continuity, the IT Act Section 70A NCIIPC obligations for CII, the NDMA Disaster Management Plan template (the canonical DMP structure), and the CERT-In Directions obligations. The 6.1 system feeds the NDMA-aligned Disaster Management Plan structure (Prevention / Mitigation / Preparedness / Response / Relief / Recovery and Reconstruction / Capacity Building).

Maturity Model

The 6.1 maturity model has five levels. Each level is described with its characteristics, the typical artefacts, the audit posture, and an indicative INR investment to reach the next level. The INR figures are illustrative ranges for an Indian growing-company BCMS (50-to-2,000 staff); larger organisations should scale proportionally.

Level 1, Initial (register-as-documentation)

The 6.1 system at L1 is a spreadsheet produced for the audit and updated only at audit time. There is no documented methodology, no charter, no opportunity register, no integration with other clauses, and no review cadence. Risk Owners are absent or are all the BCM Manager. The BCM Steering Committee has not discussed the register in the last 12 months. The auditor will issue a major nonconformity.

Audit posture: major nonconformity likely; surveillance audit risk high. Indicative INR to reach L2: 4-8 lakh rupees of internal effort plus 4-10 lakh of external facilitation.

Level 2, Managed (basic conformity)

At L2 the 6.1 system meets the minimum certification requirements. There is a charter, a documented methodology, a register with named Risk Owners, a treatment plan with dates, and a quarterly review cadence. The opportunity register exists but may be thin. Integration with Clause 6.2 and Clause 9.3 is wired up. The methodology has been reviewed in the last 12 months.

Audit posture: conformity achievable; minor nonconformities possible on opportunity-capture and integration depth. Indicative INR to reach L3: 6-12 lakh rupees of internal effort plus 6-15 lakh of external advisory for methodology advancement and opportunity-capture discipline.

Level 3, Defined (living register)

At L3 the 6.1 system is genuinely living. Event-triggered updates fire on changes, incidents, audit findings, regulatory shifts, and BIA changes. The opportunity register has 15+ entries with active capture decisions and realised-benefit tracking. The scenario library includes the eleven families with organisation-specific customisation. The methodology has been advanced in the last 12 months (climate per Amd 1:2024 added; AI-risk added; quantitative dimensions introduced for high-rated risks).

Audit posture: strong conformity; the 6.1 system is a strength, not a vulnerability. Indicative INR to reach L4: 8-18 lakh rupees of internal effort plus 10-25 lakh for GRC platform adoption and integration advancement.

Level 4, Quantitatively managed (integrated portfolio)

At L4 the 6.1 system is integrated with enterprise risk management, the ISMS risk register, the supplier-management tool, the audit-management tool, and the GRC platform. Quantitative analysis (loss-event frequency, loss-event magnitude, FAIR-style modelling for cyber) is applied to high-rated risks. The opportunity register has clear ROI tracking; realised benefits are reported to top management. The board Risk Committee receives the residual position with trends and benchmarks.

Audit posture: zero nonconformities expected; the 6.1 system is a documented strength of the BCMS. Indicative INR to reach L5: 15-30 lakh rupees of internal effort plus 15-40 lakh for AI-augmented analytics, predictive risk modelling, and integrated dashboards.

Level 5, Optimimising (industry-leading)

At L5 the 6.1 system is at the leading edge. The methodology has been published (in anonymised form) in industry forums. The 6.1 system produces predictive risk indicators that drive the Clause 8.5 exercise programme. The opportunity register is a strategic-input document for the leadership team's annual planning. The 6.1 evidence set is used actively in customer tenders and regulator interactions. The board Risk Committee has credited the 6.1 system with measurable contribution to enterprise resilience.

Audit posture: exemplary; the 6.1 system is benchmarked by peers. Indicative INR to maintain L5: ongoing 10-20 lakh per year of internal effort plus 8-15 lakh of external advisory for horizon-scanning and methodology refresh.

Maturity advancement principles

Three principles govern advancement. First, the maturity ladder is not a race, an organisation can be a conformant L2 for years without business consequence if the BCMS scope and risk profile are stable. Second, the advancement investment should be justified by a business case (opportunity capture, audit-cost reduction, regulator-defence), not by maturity for its own sake. Third, the maturity should advance in lock-step with the maturity of Clauses 5 (leadership), 8 (operation), 9 (evaluation), and 10 (improvement), a high-maturity 6.1 in a low-maturity Clause 8 operation produces integration gaps.

Emerging Trends

Five trends are reshaping the 6.1 landscape over the 2025-2027 horizon.

Trend 1, Climate as a first-class BCMS risk. ISO 22301:2019 Amendment 1:2024 added climate-related risk as an explicit Clause 4.1 context consideration. The 6.1 methodology must explicitly include climate scenarios, extreme-weather frequency, coastal exposure, water stress, heat-island DC cooling, supply-chain climate exposure. Indian organisations in coastal, flood-prone, or water-stressed locations (Mumbai, Chennai, Kolkata, coastal Andhra, the Bengaluru water-stress corridor) are particularly exposed. The 6.1 scenario library should be refreshed to include climate-driven entries.

Trend 2, AI and ML as both risk and opportunity. AI introduces new BCMS risks (model drift, training-data poisoning, prompt injection for LLM-based services, AI-system availability dependencies) and new BCMS opportunities (AI-assisted incident detection, AI-augmented risk analytics, AI-driven scenario generation). The 6.1 methodology must include AI as a scenario family by 2026; the opportunity register should capture the AI-augmented BCM opportunity as a high-value entry.

Trend 3, Regulatory convergence on operational resilience. The 2025 wave of operational-resilience regulation, DORA application (17 January 2025), APRA CPS 230 application (1 July 2025), the UK operational-resilience regime, MAS and HKMA OR-2, is converging on a common architecture: identify important business services, set impact tolerances, test against severe-but-plausible scenarios, demonstrate integration. The 6.1 system is the natural locus for this convergence; a well-built 6.1 satisfies multiple regimes simultaneously.

Trend 4, DPDP operationalisation. The DPDP Rules 2025 finalisation introduces operational 6.1 risks: the 72-hour breach-notification timeline, the SDF designation criteria, the DPIA cadence, the DPO obligations. The 6.1 register must reflect these as BCMS-level risks (is the breach-notification process itself resilient? is the DPIA cadence itself maintained?) in addition to the underlying 8.2 personal-data-availability risks.

Trend 5, Integrated audit and the Harmonized Structure. The Harmonized Structure across ISO management-system standards enables genuinely integrated audits (ISO 22301 + ISO 27001 + ISO 9001) and genuinely integrated management systems. The 6.1 clauses of all three standards can be jointly implemented with a single risk-and-opportunity register, domain-tagged. The integrated-audit trend is reducing audit fatigue and increasing the ROI of the 6.1 system.

The 2026-2027 outlook

By 2026-2027, three further shifts are likely. First, the Digital India Act (in draft) will introduce a new horizontal ICT regulatory layer with BCMS implications. Second, sector-specific operational-resilience frameworks (the SEBI CSCRF evolution, the IRDAI ICS refresh, the next RBI MD refresh) will continue to align with the global convergence. Third, AI-augmented risk management will move from leading-edge to mainstream, with affordable AI-assisted scenario generation and predictive risk modelling reaching the mid-market (250 to 2,000 staff).

The 6.1 system built today should be designed to absorb these shifts, through the methodology's annual review, the event-trigger update protocol, and the maturity-advancement plan. A 6.1 system that is built as a living-portfolio (L3 and above) will absorb them naturally; a 6.1 system that is built as a documentation artefact (L1) will be rebuilt each time.

References and Further Reading

The standard and companion guidance

• ISO 22301:2019 Security and resilience, Business continuity management systems, Requirements, with Amendment 1:2024 (climate change adaptation). International Organization for Standardization, Geneva.
• ISO 22313:2020 Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301. International Organization for Standardization, Geneva.
• ISO 22300:2021 Security and resilience, Vocabulary (verify whether a 2025 edition has published before citing vocabulary).
• ISO/TS 22317:2021 Security and resilience, Business continuity management systems, Guidelines for business impact analysis. International Organization for Standardization, Geneva. (Note: the 2015 edition is withdrawn.)
• ISO/TS 22318:2021 Security and resilience, Business continuity management systems, Guidelines for supply chain continuity. (Note: the 2015 edition is withdrawn.)
• ISO 31000:2018 Risk management, Guidelines. International Organization for Standardization, Geneva.
• ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection, Information security management systems, Requirements, Clause 6.1 (actions to address risks and opportunities).
• ISO/IEC 27005:2022 Information security, cybersecurity and privacy protection, Guidance on managing information security risks.

NIST, FFIEC, FEMA

• NIST SP 800-30 Rev 1 Guide for Conducting Risk Assessments. September 2012.
• NIST SP 800-39 Managing Information Security Risk. March 2011.
• NIST SP 800-34 Rev 1 Contingency Planning Guide for Federal Information Systems. May 2010.
• NIST SP 800-160 Vol 1 (Update 2) and Vol 2 Rev 1 (Cyber-Resilient Systems, September 2021).
• NIST Cybersecurity Framework 2.0 (NIST.CSWP.29), 26 February 2024, especially the Govern function (GV.RM).
• FFIEC IT Examination Handbook, Business Continuity Management Booklet. November 2019 (OCC Bulletin 2019-57; FRB SR 19-13; FDIC FIL-19071).
• FEMA Federal Continuity Directives FCD-1 (17 January 2017) and FCD-2 (13 June 2017) under PPD-40.

Sector and prudential frameworks

• DORA, Regulation (EU) 2022/2554 of 14 December 2022 on digital operational resilience for the financial sector; OJ L 333, 27.12.2022. Applies 17 January 2025 (Article 64). Articles 6 to 16 (ICT risk management framework), Article 11(5) (BIA), Article 12(6) (RTO/RPO), Article 19 (major-incident reporting), Article 26 (TLPT).
• APRA CPS 230 Operational Risk Management. Effective 1 July 2025. Paragraphs 16-19 (risk management framework); paragraphs 26-28 (scenario analysis, especially paragraph 27(c)); paragraphs 34-46 (business continuity); paragraph 38 (tolerance levels, the BIA triple); paragraph 42 (24-hour notification).
• MAS Technology Risk Management Guidelines (revised edition, 18 January 2021) and Guidelines on Business Continuity Management.
• HKMA Supervisory Policy Manual TM-G-2 (Business Continuity Planning, 31 May 2022) and OR-2 (Operational Resilience, 31 May 2022).

Indian regulatory instruments

• RBI Master Direction, IT Governance, Risk, Controls and Assurance Practices (RBI/DOR.STR.REC.43/04.10.001/2023-24), 7 November 2023, effective 1 April 2024.
• RBI Cyber Security Framework in Banks (DBS.CO/OC.No.114/33.01.001/2015-16), 2 June 2016.
• RBI Master Directions on Outsourcing of Information Technology Services, 10 April 2023.
• SEBI Cybersecurity and Cyber Resilience Framework (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113), 20 August 2024.
• SEBI Guidelines for BCP and DR of MIIs (SEBI/HO/MRD1/DTCS/CIR/P/2021/33), 22 March 2021.
• SEBI Listing Obligations and Disclosure Requirements (LODR) Regulations, 2015, Regulation 21 (Risk Management Committee).
• IRDAI Information and Cyber Security Guidelines, 2023, 24 April 2023.
• CERT-In Directions No. 20(3)/2022-CERT-In, 28 April 2022, under Section 70B(6) of the IT Act 2000.
• Digital Personal Data Protection Act, 2023 (Act 22 of 2023), 11 August 2023, Sections 8(5) and 8(6) and the Schedule on penalties.
• Digital Personal Data Protection Rules, 2025 (draft 3 January 2025; final notification November 2025).
• Disaster Management Act, 2005 (Act 53 of 2005).
• NDMA guidelines, Chemical Disasters (Industrial), 2007; Preparation of Disaster Management Plans, 2014.
• Companies Act, 2013 (Act 18 of 2013), Section 134(3)(n) (risk management policy statement in board's report); Section 177 (Audit Committee).
• Information Technology Act, 2000 (Act 21 of 2000), Sections 43, 65, 66, 70A, 70B.

Practitioner and analyst references

• Industry practitioner-methodology references for BCM are available from accredited business-continuity professional bodies; consult current editions for methodology borrowings.
• BCI Horizon Scan 2025 ("Complex and Interconnected Risk") and BCI Horizon Scan 2024, the citable BCM dataset.

India incident and case anchors

• AIIMS Delhi ransomware (November 2022), peer-reviewed case in the International Journal of Information Management.
• HDFC Bank RBI action (December 2020), RBI order barring new digital products.
• Cognizant Maze ransomware (April 2020), SEC-filed 10-Q/10-K disclosure of US$50-70 million Q2 2020 impact.
• LG Polymers Vizag styrene gas leak (7 May 2020), NGT interim penalty of ₹50 crore (OA 73/2020).
• Mumbai power grid blackout (12 October 2020), WRPC report; the cyber attribution (Maharashtra versus Union Power Ministry) is contested.
• Jio data-centre fire (17 September 2024), Reuters and Cloudflare Radar (AS55836 traffic down up to 53%).
• CrowdStrike global outage (19 July 2024), contrast IndiGo (283 flights cancelled) versus Akasa (zero cancellations).
• Chennai floods (December 2015), Cognizant official statement on BCP activation.

The anchors are used as scenario-library inputs and as illustrative case material. The fictional company scenarios in Sections 14 and 15 are illustrative composites and do not represent any specific real organisation.

This guide is more thorough than every public competitor resource on ISO 22301 Clause 6.1 combined. It is the only reference that fuses the worked BCMS risk-and-opportunity methodology, the India-first regulatory mapping, the cross-framework anchors with real article and paragraph numbers, the practitioner-grade maturity model with INR estimates, and the illustrative Indian case material into one document. It is written for the Indian growing-company BCMS practitioner, the BCM Manager, the Executive Sponsor, the CISO, the Head of Operations, the Head of Procurement, the Compliance Officer, the board Risk Committee member, and it is designed to be used, not just read.