ISO 22301 Clause 4.2: Understanding the Needs and Expectations of Interested Parties

Quick Reference (60 Seconds)

If you only read one thing: Clause 4.2 is where the BCMS stops being an internal management exercise and starts being a contractual, regulatory and social discipline. A clean 4.2 analysis is what makes your CERT-In 6-hour clock, your RBI RTO/RPO obligation, your DPDP breach-notification duty, your customer SLA and your supplier-BCP clause land in the right plan, owned by the right person, exercised in the right drill. Get 4.2 wrong and the rest of the BCMS can be technically perfect and still fail on the day, because you recovered in 4 hours but reported to CERT-In in 26, or restored your systems but forgot that your biggest customer's contract required notice within 1.

What the Standard Actually Requires

Figure · Process

What Clause 4.2 asks you to do

The paraphrased requirement

ISO 22301 Clause 4.2 asks organizations to work out which interested parties matter to business continuity, what those parties need and expect, and which legal, regulatory and other requirements apply to the BCMS, and to keep that understanding current. With Amendment 1:2024 in force (published February 2024; taken over as EN ISO 22301:2019/A1:2024 in September 2024), the organisation is now explicitly required to consider climate change as a driver of interested parties' needs and expectations, investors, regulators, customers, employees, communities and insurers increasingly expect the BCMS to address climate-related disruption. The climate dimension is not a separate sub-clause; it is woven into the same interested-party and requirements analysis.

In practical terms, an organisation has to be able to answer seven questions in writing:

1. Coverage, Have we looked across all interested-party categories (internal governance, employees, customers, regulators, suppliers, partners, investors, auditors/certification bodies, insurers, media, community, and the climate stakeholders Amendment 1:2024 surfaces)?
2. Relevance, For each candidate, have we explicitly determined whether they are relevant to the BCMS (not every stakeholder is a 4.2 interested party; relevance is a documented decision)?
3. Needs vs expectations vs requirements, For each relevant party, have we distinguished what they need (a basic want), what they expect (the standard of behaviour they consider normal) and what they require (an enforceable obligation)?
4. Obligation capture, Have we converted every applicable legal, regulatory, contractual and self-imposed requirement into an explicit BCMS requirement with a citation, owner, evidence and refresh date?
5. Cross-boundary, Where requirements cross borders (DORA for an Indian fintech serving EU banks; APRA CPS 230 for an Indian captive of an Australian bank; MAS TRM for a Singapore-listed subsidiary; state vs central regimes inside India), have we captured all applicable layers?
6. Traceability, How does each interested party's needs/expectations/requirements flow downstream into Clause 4.3 (scope), 6.1 (risks/opportunities), 6.2 (objectives), 7.4 (communication), 8.4 (response and notification), 9.3 (management review) and 10.2 (continual improvement)?
7. Living process, When and how will we re-do this? Annually; on event trigger (new regulation, new customer, new supplier, new geography, post-incident, post-exercise, new climate scenario, M&A); after every Clause 9.3 management review.

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

Clause 4.2 is the second-most-skipped clause in the standard (after 4.1) because practitioners mistake it for a stakeholder-list exercise. It is helpful to be explicit about what is out of scope for 4.2, because auditors test the boundary:

• It does not require identifying internal/external issues. That is Clause 4.1. 4.1 names the issues; 4.2 names the people, organisations and authorities those issues flow through, and what those parties want or require.
• It does not require defining the BCMS scope. That is Clause 4.3. 4.2 informs scope by surfacing which interested parties and which obligations the BCMS must cover.
• It does not require risk treatment. That is Clause 6.1. 4.2 identifies requirements (which become sources of risk if unmet); 6.1 rates and treats them.
• It does not require detailed communication plans. That is Clause 7.4. 4.2 identifies who must be communicated with and what they need; 7.4 builds the operational plan (channels, cadence, templates, spokesperson).
• It does not require a full regulatory-compliance management system. That is the job of Legal/Compliance under whichever sector regime applies. 4.2 intersects with compliance, it captures the subset of legal/regulatory obligations that touch business continuity.
• It does not require engagement with every conceivable interested party. Only those relevant to the BCMS. A consumer retail brand's 100 million customers are an interested party in the abstract; 4.2 cares about the segment of that base whose needs/expectations are material to continuity (e.g., the 2% with critical-service SLAs, or the cohort protected by DPDP).
• It does not require climate scenario modelling to TCFD/NGFS specifications. Amendment 1:2024 requires that climate-driven stakeholder expectations be considered; depth scales with the organisation's exposure.

The companion guidance (ISO 22313:2020)

The clause text is short; the method lives in companion documents. Three are most relevant for Clause 4.2:

• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301. The clause-by-clause companion. For Clause 4.2 it explains that interested parties include those that can affect the BCMS, those that can be affected by it, and those that have an interest in it. It encourages the organisation to identify these parties' needs and expectations, decide which become requirements, and capture applicable legal, regulatory and other requirements (including those from outsourced providers of products and services).
• ISO 31000:2018, Risk management, Guidelines. Its "establishing the context" step explicitly covers "defining the external and internal context" and "defining risk criteria", the latter of which is essentially the 4.2 obligations-tracker activity.
• ISO/TS 22318:2021, Business continuity management systems, Guidelines for supply chain continuity. The most directly load-bearing companion for 4.2: it expands the supplier dimension. The 2015 edition is withdrawn; cite the 2021 edition.
• ISO/IEC 27001:2022 Clause 4.2 covers the same concept for the ISMS; if your organisation runs an integrated ISMS+BCMS (common for Indian BFSI and SaaS), one consolidated interested-party analysis serves both.
• ISO 22300:2021, Vocabulary. Defines "interested party", "requirement", "legal requirement", "regulatory requirement" and related terms.

What auditors actually check

Certification auditors (BSI, DNV, SGS, TÜV, Bureau Veritas, NQA, Intertek, plus Indian certification bodies) test Clause 4.2 by triangulating four things:

• The interested-party register, coverage of all categories (internal, customer, regulator, supplier, partner, investor, community, climate-stakeholder); documented relevance decision for each; needs/expectations/requirements distinction visible; top-management approval; version history; evidence of refresh.
• The legal-regulatory obligations tracker, every applicable Indian instrument (and any cross-border regime) named with citation; mapped to a BCMS clause and an internal owner; evidence of compliance maintained; refresh date scheduled; events triggering updates visible.
• Traceability downstream, does Clause 4.3 (scope) actually include the regulator-imposed boundaries? Does Clause 6.1 (risks) include risks that flow from non-compliance with the captured obligations? Does Clause 7.4 (communication) list the right regulatory reporting clocks (CERT-In 6 hours; RBI; SEBI 6 hours; IRDAI; DPDP 72 hours to Board)? Does Clause 8.4 (response) include notification procedures for each stakeholder?
• Traceability upstream, does the interested-party register reflect what the board, the risk committee, the CISO, the customer-success team and Legal actually hear from these stakeholders? Are recent customer escalations, regulator queries, supplier-failure incidents and investor ESG questions reconcilable with the parties and expectations in the register?

Common observations you should be ready for: (a) "your stakeholder register lists 12 parties but your Clause 7.4 communication plan only addresses 4, explain the gap" (an L2 finding); (b) "your obligations tracker names RBI and SEBI but omits CERT-In Directions 20(3)/2022 and DPDP Act 2023, both apply to you" (an L1 non-conformity, increasingly raised since 2023); (c) "you have not considered climate-driven stakeholder expectations despite Amendment 1:2024 being in force" (an Amendment-driven non-conformity, increasingly raised since late 2024); (d) "your obligations tracker has not been updated since the SEBI CSCRF circular of 20 August 2024, that is a material new obligation" (an L1 non-conformity for any SEBI-regulated entity).

Why This Control Matters

The business case

Most BCM programmes that fail under stress fail not because the recovery technology was wrong but because the obligations were wrong, the organisation restored its systems but missed the regulator's notification clock, or invoked its DR plan but forgot that a key customer's contract required a parallel incident notice, or recovered the data but did not have a clean breach-notification process for the affected individuals under DPDP. Clause 4.2 is the clause that prevents that failure mode. It is the requirements-translation clause: it converts the diffuse, partly-formal, partly-tacit universe of stakeholder expectations into a single, owned, citable list of BCMS requirements.

Done well, Clause 4.2 produces four things of immediate business value:

1. A defensible stakeholder map, so when a disruption hits, the crisis-management team has a single source of truth for who must be told what, by when, by whom. This is the difference between a 6-hour CERT-In report and a 26-hour scramble.
2. An obligations inventory with named owners, so no requirement falls through the cracks. The most common post-incident finding is "we did not realise Legal owned the CERT-In clock and Ops owned the RBI clock; nobody owned the customer-contract clock".
3. A materiality filter on stakeholder engagement, so the finite BCM programme budget goes to stakeholders whose needs/expectations are material to continuity, not to whoever was loudest in the last quarterly review.
4. An audit-ready trace, so when a regulator (RBI, SEBI, IRDAI, CERT-In, the DPDP Board) or a board risk committee asks "why does your BCMS scope read the way it does?" the answer points to specific obligations with citations.

Indian context, why this clause matters more in India than in most markets

Several features of the Indian operating environment make Clause 4.2 unusually load-bearing:

• Multi-regulator overlay. A single mid-sized Indian entity can simultaneously be: a Data Fiduciary under DPDP Act 2023 (Section 8(5) statutory availability duty; Section 8(6) breach notification); a service provider/intermediary/body corporate under CERT-In Directions 20(3)/2022-CERT-In (28 April 2022) with a 6-hour incident-reporting clock; a regulated entity under RBI Master Direction IT Governance (issued 7 November 2023, effective 1 April 2024); a market participant under SEBI CSCRF (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024) with its own 6-hour clock; an insurer or intermediary under IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023); a company with board risk-oversight duties under Companies Act 2013 Section 134(3)(n) and Section 177; and a body corporate with civil/criminal exposure under IT Act 2000 Sections 43, 65, 66, 70A, 70B. Each of these is a separate interested party, with separate needs, separate expectations, and separate requirements. Most growing companies track only two or three of them; the others surface as audit findings or post-incident liabilities.
• Cross-border layering. An Indian SaaS firm serving EU financial-services customers becomes indirectly subject to DORA (Reg (EU) 2022/2554, applies from 17 January 2025) via its customer contracts, even though it is not itself a DORA-regulated entity. An Indian captive of an Australian bank is pulled into APRA CPS 230 (effective 1 July 2025) via group policy. A Singapore-listed subsidiary inherits MAS TRM expectations. These cross-border regimes are interested parties under 4.2 even when the Indian regulator is silent.
• Critical-infrastructure expectations. Organisations in energy, telecom, banking, healthcare, transport and government are protected systems or operate critical information infrastructure under IT Act 2000 Section 70/70A, with NCIIPC as a specific interested party holding protective-direction authority. The expectations NCIIPC brings are not optional and not visible to most BCM programmes that have not done a 4.2 analysis.
• Customer concentration and SLA discipline. Indian IT/ITeS firms often have their top three customers representing 40 to 70 per cent of revenue, each with bespoke contract SLAs (often 99.9 per cent or 99.95 per cent uptime, sub-hour incident notice, named-incident-manager escalation). These contractual requirements are interested-party requirements under 4.2; they typically drive tighter RTO/RPO than the regulator does, and 4.2 is where they are surfaced.
• Supplier ecosystem concentration. Most Indian banks, NBFCs and insurers run core-banking, core-insurance or lending stacks from a small set of vendors; most SaaS firms depend on one or two cloud providers; most payment firms depend on NPCI rails (UPI's 12 April 2025 ~5-hour degradation showed the ecosystem blast radius). Each is an interested party whose own BCP posture affects yours. RBI Master Direction Outsourcing of IT Services (10 April 2023) makes the regulated entity responsible for its outsourcer's continuity, Clause 4.2 is where that responsibility becomes an explicit requirement.
• Climate-stakeholder density (post-Amendment 1:2024). India's climate exposure (monsoon flooding in Mumbai/Chennai/Kerala; cyclones on east and west coasts; heatwaves across north and central India; Delhi NCR winter air-quality events) creates a dense climate-stakeholder network: NDMA, State Disaster Management Authorities, the National Green Tribunal, State Pollution Control Boards, the Ministry of Environment, Forest and Climate Change, insurers reinsuring climate risk, customers affected by weather-driven supply interruption, employees whose personal safety affects recoverability, and investors increasingly asking TCFD/ISSB-aligned climate questions. Amendment 1:2024 makes these stakeholders' expectations explicit inputs to the BCMS.
• Board-level accountability. Companies Act 2013 Section 134(3)(n) requires the Board's Report to include a statement on development and implementation of a risk management policy, including elements of risk that may threaten the existence of the company itself; Section 177 and SEBI LODR Regulation 21 require a Risk Management Committee for listed companies. Stakeholder expectations that reach the board (regulator orders, customer escalations, investor ESG queries, media crises) are 4.2 inputs. A clean Clause 4.2 analysis is the artefact that satisfies board-risk-oversight duties.

The cost of getting it wrong

The cheapest way to learn what a 4.2 failure costs is to look at incidents where the root cause was, at heart, failure to identify a stakeholder or a requirement:

• Air India / SITA, disclosed May 2021, cyber-attack on SITA's Passenger Service System compromised ~4.5 million Air India customers globally (data spanning 26 August 2011 to 3 February 2021: names, dates of birth, contact, passport, ticket and frequent-flyer data). In ISO 22301 terms this is partly a Clause 4.2 failure: SITA was an interested party whose own continuity and security posture directly affected Air India's BCMS, and the contract-and-disclosure obligations flowing from that dependency (who notifies which regulator, in what window, with what data set) were not pre-mapped to the right plan and the right owner. The breach landed; the disclosure followed weeks later.
• Cognizant Maze ransomware, 18 to 20 April 2020, double-extortion; internal email, directory and customer systems hit; Cognizant's 10-Q/10-K (SEC-filed) disclosed Q2 2020 impact of US$50 to 70 million in lost revenue and margin. In ISO 22301 terms this is partly a Clause 4.2 failure: customers of a global IT-services firm hold contractual and regulatory expectations that flow through to entity-level BCM; the requirements set (customer-by-customer incident notification, mutual-aid clauses, regulator cross-reporting where customers are themselves regulated) was not pre-compiled into a single obligations tracker, so each customer found out separately and contractually.
• HDFC Bank, RBI action 2 December 2020, RBI barred HDFC from onboarding new digital products and issuing fresh credit cards (card ban partially lifted 17 August 2021; full digital-initiatives ban lifted March 2022) following repeated digital outages (including 21 to 22 November 2020 when a DC power failure took net banking and cards dark for ~half a day). In ISO 22301 terms this is partly a Clause 4.2 failure: RBI's expectations of board-level governance over digital continuity were a known requirement; they were not translated into the BCMS at the right priority, and the regulator ultimately forced the corrective action.
• Wipro phishing, reported April 2019, advanced phishing compromised Wipro employee accounts; attackers pivoted through Wipro to target its outsourcing/MSP customers (a classic supply-chain pivot). In ISO 22301 terms this is partly a Clause 4.2 failure: customers' BCPs depended on Wipro's identity security; the customer-facing BCM expectations (incident notification, joint IR, security transparency) were not uniformly codified in customer contracts as formal requirements.

These are extreme cases. The everyday version of the same failure looks like this: a mid-market (250 to 2,000 staff) SaaS firm suffers a 3-hour outage. The engineering team recovers the system in 4 hours (just outside the team's internal 2-hour RTO). The customer-success team takes another 2 hours to draft a customer notice (because the template is in someone's personal drive). The legal team is dragged in at hour 7 and realises that one of the top-3 customers has a 1-hour contractual notice SLA (breached) and that the breach may trigger a CERT-In report (which it does, because customer data was exposed, but the 6-hour clock started at hour 0, already breached). By hour 10 the firm has three concurrent obligations breaches, none of which had to happen if 4.2 had been done well.

Scope and Applicability

Who 4.2 applies to

Clause 4.2 applies to every organisation in scope of ISO 22301:2019. Unlike the BIA (8.2) or strategy (8.3) clauses, which scale with the size and complexity of the in-scope activities, Clause 4.2 scales in breadth, the larger and more regulated the organisation, the more interested parties and the more obligations, but it applies uniformly. A 40-person SaaS start-up and a 40,000-person bank both have to identify their interested parties and applicable requirements; what differs is the size of the register and the cadence of refresh.

What "the organization" means for 4.2

"Organization" in Clause 4.2 means the entity to which the BCMS applies, defined in Clause 4.3 (scope). For growing companies, this is usually the whole legal entity. For groups, it can be a subsidiary, a business unit or a function. The interested parties identified in 4.2 must cover (a) parties inside the BCMS scope (employees, internal governance bodies, in-scope shared services), (b) parties outside the scope whose actions or expectations shape the in-scope BCMS (the parent company, group shared services, upstream suppliers, regulators, customers), and (c) parties affected by the in-scope activities (customers, end-users, communities, the broader public). Auditors look for that three-way coverage.

What 4.2 does NOT scope

Clause 4.2 does not decide what is in the BCMS, Clause 4.3 does. But 4.2 informs 4.3 by surfacing which interested parties and which obligations the BCMS must serve. A common error is to scope 4.2 down to match an already-decided 4.3 outcome ("we only certify the data centre, so we'll only list data-centre stakeholders"), auditors notice and treat it as a finding.

By organisation size

By industry (preview, Section 21 has the deep treatment)

Different industries have materially different 4.2 surfaces. A quick preview:

• BFSI (banks, NBFCs, insurers, payment system operators), the densest interested-party network in the Indian economy: RBI/SEBI/IRDAI simultaneously for firms at the intersection; NPCI for payment operators; DPDP for any data fiduciary; CERT-In horizontally; depositors/policyholders/investors as a high-expectation customer base; rating agencies; re-insurers for catastrophic scenarios.
• Healthcare (hospitals, pharma, medtech), patients (a life-safety stakeholder, not just a customer); MoHFW; state health departments; IRDAI for insured care; FDA/EMA for export-driven pharma; NARC for hospital-stress loans; National Pharmaceutical Pricing Authority.
• IT/ITeS and SaaS, enterprise customers with bespoke contractual BCM clauses; DORA/APRA/MAS/HKMA-driven cross-border requirements; downstream customers of customers; cloud and SaaS-dependency chains.
• Manufacturing (chemicals, auto, electronics), local community as a life-safety stakeholder (LG Polymers showed the extreme); State Pollution Control Boards; factories inspectorate; NDMA and SDMAs; OEM customers; tier-2 and tier-3 suppliers whose own BCM posture is yours.
• Government and PSUs, the Legislature, the Auditor (CAG), the CVC, the parent Ministry, NIC and NCIIPC for systems, RTI-driven public transparency, and the citizen as a high-expectation stakeholder.

Key Definitions and Terminology

Clause 4.2 uses a combination of ISO management-system vocabulary and BCM-specific terms; the following definitions are load-bearing:

• Interested party (stakeholder), in our own words: any person or organisation with the ability to influence what the organisation decides or does, anyone on the receiving end of those decisions and activities, and anyone who believes they are on the receiving end, whether or not they actually are. The formal definition sits in ISO 22300:2021 and the ISO/IEC Directives; "interested party" and "stakeholder" are treated as synonyms in ISO 22301. The three qualifiers, influences you, is affected by you, believes itself affected by you, are deliberately broad; the third captures parties whose perception of risk matters even when the underlying risk is low (e.g., a community near a chemical plant).
• Need, what an interested party requires to be satisfied, in the colloquial sense. A customer needs service availability; an employee needs a safe workplace; a regulator needs compliance evidence. Needs are often unstated and are discovered through engagement.
• Expectation, the standard of behaviour an interested party considers normal or appropriate, often shaped by industry practice, prior conduct, or social norms. Expectations sit above needs and below requirements in formality. A customer expects a 99.9 per cent uptime because that is the SaaS industry norm; an employee expects a clear evacuation plan because that is the workplace norm.
• Requirement, a need or expectation that is formally stated, in the organisation's own BCMS context. ISO distinguishes: (a) legal requirement, imposed by a statute, regulation, or court order (DPDP Act, IT Act, Companies Act, Disaster Management Act); (b) regulatory requirement, imposed by a sector regulator via binding instrument (RBI Master Directions, SEBI circulars, IRDAI guidelines, CERT-In Directions, TRAI Quality of Service regulations); (c) contractual requirement, imposed by a contract (customer SLA, vendor BCP clause, insurance warranty); (d) self-imposed requirement, the organisation voluntarily adopts (a public commitment, a board policy, a sustainability target).
• Obligation (working term), in this guide, the union of legal, regulatory and contractual requirements that bind the BCMS. The obligations tracker is the canonical artefact.
• Materiality (in the 4.2 sense), the organisation's documented judgement about which interested parties and which requirements are significant enough to influence the BCMS. Materiality is a documented rationale, not a numerical score.
• Stakeholder register, the canonical list of interested parties, with their category, relationship, needs, expectations, requirements (where applicable), engagement owner, and refresh date.
• Needs-and-expectations matrix, the analytic artefact that, for each interested party, decomposes their relationship with the BCMS into needs, expectations, requirements, source/citation, and downstream clause consumed.
• Legal-regulatory obligations tracker, the canonical list of every applicable legal, regulatory and (where material) contractual and self-imposed obligation that affects the BCMS, mapped to a clause, an owner, evidence, citation, and refresh date.
• Relevance, the documented determination that an interested party is (or is not) material to the BCMS. Not every stakeholder is a 4.2 interested party; relevance is the gate.
• Engagement owner, the named individual responsible for the bilateral relationship with a specific interested party (e.g., the Head of Compliance for RBI; the CISO for CERT-In; the Head of Customer Success for the top-3 customers; the DPO for the DPDP Board).
• Reporting clock, the time within which a specific obligation must be discharged. Indian BCM-critical clocks include: CERT-In 6 hours of noticing a reportable incident; DPDP 72 hours of becoming aware of a personal-data breach (to the Data Protection Board, with affected individuals notified without delay); RBI incident reporting within 2 to 6 hours of detection; SEBI 6 hours to SEBI/CERT-In for REs; APRA CPS 230 24 hours of any critical-operation disruption outside tolerance (para 42) and 72 hours for material incidents (para 33); DORA major-incident reporting under Arts 18 to 19; NGT and State Pollution Control Boards per their own rules.
• Outsourced activity, a process performed by an external party on behalf of the organisation. ISO 22301 Clause 8.1 and RBI Master Direction Outsourcing of IT Services make the organisation responsible for the BCP posture of its outsourced activities; 4.2 captures the supplier as an interested party and the contract SLA as a requirement.
• Climate-change stakeholder (Amendment 1:2024), an interested party whose needs or expectations of the BCMS are shaped by climate considerations: regulators (NGT, MoEFCC, State Pollution Control Boards), insurers and reinsurers pricing climate risk, investors asking TCFD/ISSB-aligned questions, customers affected by climate-driven supply interruption, employees whose personal safety and access during a climate event affects recoverability, communities neighbouring assets exposed to physical climate risk, and government agencies operating under the Disaster Management Act 2005 and state-level climate-change missions.
• Criticability of stake, a working term for how severe the consequences are for the organisation if a particular stakeholder's expectations are unmet. A patient's stake in a hospital's BCMS is life safety (highest); a peripheral supplier's stake is a minor revenue impact (lower). Materiality and criticability together drive prioritisation.

The downstream BCM vocabulary, RTO, RPO, MTPD/MAO, MBCO, prioritised activity, disruption, MEF/PMEF, is defined in ISO 22300:2021 and used from Clause 8.1 onward; it is framed, but not directly invoked, in 4.2.

Relationship to Other Clauses and Frameworks

Inside ISO 22301:2019

Cross-framework mapping (preview, Section 16 has the full table)

Clause 4.2 maps directly onto the equivalent "interested parties / requirements" clause in every other ISO management-system standard, and onto the obligations-aware provisions of every major BCM framework. Highlights:

• ISO/IEC 27001:2022 Clause 4.2, identical concept for the ISMS; an integrated ISMS+BCMS can share one stakeholder register and obligations tracker.
• NIST CSF 2.0 Govern function (GV), GV.OC-03 specifically asks organisations to understand decisions and fulfil expectations of stakeholders; GV.OC-04 covers legal, regulatory and contractual requirements; GV.OC-05 covers emerging expectations (climate, ESG). Mapping is direct.
• NIST SP 800-34 Rev 1 (May 2010), Step 1 of its seven-step contingency planning process is "develop contingency planning policy statement", which includes identifying authorities and stakeholders; FISMA and OMB Circular A-130 impose the federal-stakeholder overlay.
• FFIEC BCM Booklet (November 2019), "governance and accountability" principle covers board, regulator, examiner, and third-party stakeholder expectations; "communication and crisis management" covers customer, regulator, media expectations during disruption.
• DORA (Reg (EU) 2022/2554), Art 5 covers management-body responsibility to stakeholders (regulator, customer, market); Art 6 requires an ICT risk-management framework aligned to business objectives; Art 14 mandates crisis communication; Art 19 governs major-incident reporting to the regulator (a stakeholder obligation with specific clocks); Arts 28 to 30 cover ICT third-party risk (the supplier-stakeholder layer); Arts 31 to 44 establish the CTPP oversight framework (oversight authorities as super-stakeholders).
• APRA CPS 230 (effective 1 July 2025), paras 12 to 15 codify key principles (a to c) including managing service-provider risk; paras 47 to 60 cover management of service-provider arrangements, including the regulator's right of access and the entity's exit-strategy obligation, both flow from a stakeholder requirement.
• MAS TRM Guidelines (18 January 2021), system availability and resilience (Para 8 area) and BCM (Para 11 area) include customer, regulator (MAS) and board reporting expectations; the MAS Act Section 27C underpins supervisory expectations.
• HKMA OR-2 (Operational Resilience, 31 May 2022), the shift from BCP to operational resilience centres on identifying Important Business Services, mapping them end-to-end, and setting impact tolerances, a stakeholder-driven exercise (whose tolerance? regulator, customer, market).
• RBI Master Direction IT Governance (7 November 2023, eff. 1 April 2024), the consolidated IT/cyber/BCP instrument for banks, NBFCs (asset base ≥ ₹500 cr), All-India Financial Institutions and CICs; explicitly board-driven; explicitly customer-protective.
• SEBI CSCRF (20 August 2024) and SEBI BCP-DR for MIIs (22 March 2021, modified 12 September 2024), market-stakeholder obligations including RTO ≤ 2 hours for critical MII systems, 6-hour incident reporting to SEBI/CERT-In, and the broader CSCRF five-cyber-resilience-goals framework.
• IRDAI Information and Cyber Security Guidelines 2023 (24 April 2023), board-approved Information & Cyber Security Policy including BCP/DR; 180-day log retention aligned with CERT-In; ICT outsourcing continuity oversight; insurer's policyholder as a high-stakes interested party.
• CERT-In Directions 20(3)/2022-CERT-In (28 April 2022), the horizontal Indian baseline: 6-hour incident reporting; 180-day log retention; NTP synchronisation; KYC of VPN/data-centre/cloud customers; PoC appointment; investigation cooperation.
• DPDP Act 2023 (Act 22 of 2023) and DPDP Rules 2025, Section 8(5) statutory availability duty on the Data Fiduciary; Section 8(6) plus Schedule breach-notification duty; up to ₹250 crore penalty for inadequate security safeguards and up to ₹200 crore for failure to notify; the Data Protection Board of India is a new interested party.
• Companies Act 2013 Section 134(3)(n) and Section 177; SEBI LODR Regulation 21, board-level risk-oversight expectations; the Board and its Risk Management Committee are themselves high-stakes interested parties.
• IT Act 2000 Sections 43, 65, 66, 70, 70A, 70B, 72, 84A, the statutory bedrock; NCIIPC (Section 70A) and CERT-In (Section 70B) are specific interested parties for any protected-system or critical-infrastructure operator.

The detailed cross-framework mapping table appears in Section 16.

Detailed Implementation Guidance, The Worked Interested-Party Analysis

This section walks through how to actually do a Clause 4.2 cycle, end-to-end, with worked examples for a representative Indian organisation. The method has six steps. Each step is sequenced; each has outputs; each has a hand-off to the next step and to the downstream clauses.

Step 1, Identify candidate interested parties

Output: A candidate stakeholder list, grouped by category, with one-line relationship descriptions.

Start broad. The temptation is to begin with the obvious five (board, employees, customers, regulator, suppliers) and stop. Resist that. The audit finding is always the party you missed.

Run a 90-minute workshop with: BCM Lead (facilitator); Legal; Compliance; Risk; CISO; Customer Success / Account Management; Sales; Procurement; HR; Finance; Investor Relations; Facilities; and (where present) Sustainability/ESG. Frame the workshop with the seven interested-party categories used in this guide:

1. Internal governance, Board, Audit Committee, Risk Management Committee, top management, parent-company bodies (for subsidiaries), group-shared-service owners.
2. Employees and people, staff, contractors, interns, key-person dependencies, employee families (material during floods/cyclones/pandemics when personal safety affects recoverability), unions and works councils (Maruti Suzuki Manesar 2012 showed the workplace-violence dimension of stakeholder management).
3. Customers and end-users, direct customers (segment by criticality: top-3, top-20, long-tail; segment by type: B2B enterprise, B2B SME, B2C mass, B2B2C), customers' customers, end-users (patients in a hospital; citizens in a government service; depositors in a bank), and customer-representative bodies (industry associations, ombudsman, consumer courts).
4. Regulators and government, primary sector regulator (RBI, SEBI, IRDAI, TRAI); horizontal regulators (CERT-In, MeitY, DPDP Data Protection Board of India, NCIIPC for protected systems, NIC for government systems); sector ministries; state regulators (State Pollution Control Boards, state drug controllers, SDMAs); law-enforcement (NIA, state cyber cells, economic-offences wings); oversight bodies (CAG for PSUs, CVC, NCLT for insolvency scenarios); cross-border regulators where applicable (ECB banking supervision via the parent; MAS; HKMA; APRA; the US SEC for ADR issuers; the UK FCA/PRA for UK-regulated subsidiaries).
5. Suppliers and partners, cloud providers (AWS, Azure, GCP, and India-focused MeitY-empanelled cloud); core platform vendors (core banking, core insurance, ERP, CRM, HIS for hospitals); MSPs and managed security service providers; payment rails (NPCI for UPI, RuPay; card networks; PGs); telecom carriers (Jio, Airtel, BSNL, Vi); logistics (India Post, Blue Dart, Delhivery, e-commerce fulfilment); professional-services suppliers (audit, tax, legal); critical-infrastructure suppliers (power, water, fuel for backup generators); and tier-2 and tier-3 suppliers whose own BCP posture affects yours.
6. Investors, insurers and capital providers, shareholders, PE/VC investors, debt holders, rating agencies (CRISIL, ICRA, CARE, India Ratings; Moody's, S&P, Fitch for cross-border issuers), insurers (cyber, business interruption, D&O, marine, fire), reinsurers (especially for catastrophic and climate scenarios).
7. Community, media and climate stakeholders (Amendment 1:2024), local communities neighbouring operations (life-safety stakeholders for chemicals/manufacturing; noise/traffic/emissions for any industrial site), media (business, trade, regional language, social-media influencers), industry bodies (NASSCOM, CII, FICCI, ASSOCHAM, DSCI, BCI Forum India, the relevant Sector Skills Council), academia and research partners, NGT and MoEFCC for environmental stakeholders, State Pollution Control Boards, environmental NGOs, climate-investor coalitions, and the broader public for transparency-driven sectors (government, public-sector banks, listed companies under SEBI BRSR).

Capture each party with: name (or segment), category, one-line relationship description. The output of Step 1 is a candidate list, typically 30 to 60 parties for a growing firm, 100 to 200 for an enterprise. Do not filter at this step.

Worked example. Dharini Finserve, a Mumbai-based mid-market NBFC (1,100 staff, ₹4,200 crore AUM, regulated by RBI under the Master Direction IT Governance, also subject to CERT-In, DPDP, and Companies Act), ran a Step 1 workshop and produced a 47-party candidate list spanning 6 customers representing 58 per cent of AUM (top-3 enterprise lending relationships), 4 RBI desks (Department of Regulation, Department of Supervision, Department of Banking Supervision risk-management desk, the Ombudsman), 2 SEBI desks (because Dharini also runs a small listed-NCD programme), CERT-In, MeitY (for DPDP), the DPDP Data Protection Board (anticipating the Rules being operationalised), 1 cloud provider (AWS Mumbai), 1 core-lending-system vendor, 1 loan-management-system vendor, 3 MSPs, 2 payment partners (RBI for NEFT/RTGS; NPCI for UPI), 2 telecom carriers, 4 insurers, 2 rating agencies, 1 PE investor, the Board, the Audit Committee, the Risk Management Committee (under SEBI LODR Reg 21), employees (segmented into corporate office, 28 branch locations, field collections), 2 unions (Maharashtra and Gujarat branches), 7 community representatives in branch neighbourhoods, NGT (Western Zone) for the corporate office's environmental clearance, the local Municipality for fire and building safety, and 3 media categories (business press, regional Marathi press, social media).

Step 2, Determine relevance

Output: A relevance decision for each candidate party: relevant / not relevant, with a one-line rationale.

ISO does not require every stakeholder to be a 4.2 interested party. Relevance is the gate. Test each candidate against three filters:

1. Affects the BCMS? Can this party's actions or decisions change the BCMS scope, risk profile, objectives or strategy? (e.g., RBI issuing a new circular; a top-3 customer renegotiating a contract; a key supplier withdrawing BCP commitments.)
2. Affected by the BCMS? Can the BCMS's design or performance affect this party's welfare, expectations, or obligations? (e.g., customers affected by an outage; employees affected by an evacuation order; a community affected by a plant emergency.)
3. Perceives itself to be affected? Does the party itself claim a stake, even if the underlying risk is low? (e.g., a community group near a data centre worried about diesel-generator emissions; an activist investor pressing on climate disclosure.)

If any answer is yes, the party is relevant. If all three are no, document the rationale and mark not relevant (revisit at the next review). The audit test is whether the relevance decision is documented and defensible, not whether you agreed with it.

Worked example. Dharini's Step 2 review classified 41 of 47 as relevant. The 6 not-relevant candidates were: 2 of the 4 SEBI desks (no current interaction with the NCD programme's continuity; documented for revisit if the programme scales); NGT Western Zone (no active matter; documented for revisit if any environmental incident); 2 of the 7 community representatives (branches where the only presence is a leased office with no operational footprint); and 1 of the 3 media categories (social media handled through marketing-PR, not BCM-driven). Each not-relevant decision had a one-line rationale.

Step 3, Decompose needs, expectations, requirements

Output: A needs-and-expectations matrix for each relevant party.

For each relevant party, articulate in plain language:

• Needs, what they fundamentally want. (A depositor needs to access their money. An employee needs a safe workplace. A regulator needs evidence of compliance.)
• Expectations, the standard of behaviour they consider normal. (A depositor expects a digital banking app to be available 24x7. An employee expects a clear, exercised evacuation plan. A regulator expects proactive, structured reporting.)
• Requirements, the formal obligations: legal, regulatory, contractual, self-imposed. (The depositor's contractual right to NEFT/RTGS per RBI's payment-systems rules; the employee's statutory right to a safe workplace under the Factories Act / Shops and Establishments Act; the regulator's mandated reporting clock.)

The needs/expectations/requirements distinction matters because each drives a different BCMS response. Needs drive what the BCMS protects. Expectations drive how good the protection must be (the RTO/RPO targets, the customer-experience standard). Requirements drive clocks, evidence, and consequences. A BCMS that satisfies the requirements but not the needs (e.g., you report to CERT-In within 6 hours but the customer notice is opaque and slow) is technically compliant and commercially failing.

Worked example. For Dharini's top customer (a large listed manufacturer, 18 per cent of AUM, multi-crore working-capital facility):

• Needs, uninterrupted drawing power to fund daily operations; predictable interest servicing; clear visibility on the facility.

• Expectations, Dharini's lending platform available 99.9 per cent during business hours; a dedicated relationship manager; sub-4-hour incident notice for any outage affecting drawing power; quarterly business-continuity briefing.

• Requirements, per the master credit agreement, the customer must be notified within 1 hour of any incident affecting drawdowns or interest processing; manual processing via named back-up staff for outages over 4 hours; acceleration clause invocable beyond 24 hours. A sample contract clause you might draft (Singahi's own drafting for adaptation):

  Sample clause (insert in customer-facing master agreement). The Service Provider shall notify the Customer within sixty (60) minutes of becoming aware of any incident that affects, or is reasonably likely to affect, the availability, integrity or confidentiality of the Customer's data, the Service Provider's ability to perform its obligations under this Agreement, or the Customer's regulatory obligations. Such notification shall include the time of detection, the affected services, the interim contingency arrangements, the projected recovery time, and the named incident manager. The Service Provider shall provide subsequent updates at intervals not exceeding four (4) hours until the incident is closed and a post-incident report is delivered within fifteen (15) business days.

• Source/citation, Dharini, Top Customer master credit agreement, Clause 14 (Business Continuity), dated [DATE].

• Downstream clause consumed, 7.4 (communication plan: customer notice workflow); 8.4 (response procedure: notify top customer within 1 hour); 8.5 (exercise scenario: top-customer-notification drill); 9.1 (KPI: customer-notification SLA adherence).

For CERT-In:

• Needs, visibility into India's cyber-incident landscape; coordinated incident response across the economy.
• Expectations, organisations report prescribed incidents within 6 hours of noticing; maintain 180-day logs within Indian jurisdiction; sync clocks to NIC NTP; cooperate with investigations; appoint a PoC.
• Requirements, CERT-In Directions 20(3)/2022-CERT-In (28 April 2022), obligations 1 to 6 (the six headline obligations); reportable-incident list (Annexure I: ~20 categories including unauthorised access, data breach, ransomware, DoS, cloud outage); reporting form and portal.
• Source/citation, No. 20(3)/2022-CERT-In, dated 28 April 2022, Section 70B(6) IT Act 2000.
• Downstream clause consumed, 7.4 (incident-reporting workflow to CERT-In within 6 hours); 7.5 (180-day log retention; clock-sync evidence); 8.4 (IR plan integrated with CERT-In clock); 9.1 (KPI: CERT-In reporting-clock adherence); 10.1 (corrective action if a clock is missed).

For the DPDP Data Protection Board of India:

• Needs, protection of personal-data subjects' rights; timely breach response.
• Expectations, Data Fiduciaries maintain availability, integrity and confidentiality of personal data (Section 8(5)); report breaches in the prescribed form and timeline (Section 8(6) plus Schedule); Significant Data Fiduciaries meet enhanced obligations (DPIA, periodic security audits, DPO).
• Requirements, DPDP Act 2023 (Act 22 of 2023) Sections 8(5), 8(6), Schedule; DPDP Rules 2025 (notified November 2025; 72-hour breach-notification-to-Board form; affected-individuals without delay); penalties up to ₹250 crore (inadequate safeguards) and ₹200 crore (non-notification).
• Source/citation, Act 22 of 2023, Sections 8(5), 8(6), Schedule; MeitY DPDP Rules 2025.
• Downstream clause consumed, 4.3 (scope includes personal-data-handling activities); 7.4 (breach-notification workflow: Board within 72 hours; affected individuals without delay); 8.4 (IR plan includes DPDP classification); 9.1 (KPI: DPDP notification-clock adherence); 10.1 (corrective action if breached).

This is the rhythm: one party at a time, needs/expectations/requirements/source/downstream. The output is a structured matrix (toolkit doc 02 has the full template).

Step 4, Build the legal-regulatory obligations tracker

Output: A legal-regulatory obligations tracker that converts every applicable instrument into a BCMS requirement with owner, citation, evidence and refresh date.

This is the single most-cited artefact in a 4.2 audit. It is also the artefact that pays the biggest dividend when a real incident hits. Build it as a structured table:

Rows to seed the tracker with, for a representative BFSI firm:

• RBI Master Direction IT Governance (7 Nov 2023, eff. 1 Apr 2024), R1 in the research base.
• RBI Cyber Security Framework in Banks (2 Jun 2016), R2, board-approved cyber policy, CCMP, 24x7 SOC, incident reporting 2 to 6 hours, periodic drills.
• RBI Master Direction Outsourcing of IT Services (10 Apr 2023), R5, outsourced BCP/DR continuity controls, concentration risk, exit plans, RBI right of access.
• RBI Complete Cyber Security Framework for UCBs (31 Dec 2019), R4, graded approach.
• SEBI CSCRF (20 Aug 2024), S1, 5 Cyber Resilience Goals × 6 Operational Functions; 6-hour incident reporting to SEBI/CERT-In.
• SEBI BCP-DR for MIIs (22 Mar 2021, mod 12 Sep 2024), S2 + S5, Near Site + DRS, RTO ≤ 2 hours for critical MII systems, BCP drills including live failover.
• IRDAI Information and Cyber Security Guidelines 2023 (24 Apr 2023), I1, board-approved Information & Cyber Security Policy including BCP/DR; 180-day logs; ICT outsourcing oversight.
• CERT-In Directions 20(3)/2022-CERT-In (28 Apr 2022), C1, six headline obligations, 6-hour reporting.
• DPDP Act 2023 (Act 22/2023) Sections 8(5), 8(6) + DPDP Rules 2025, D1 + D2, availability duty; breach notification within 72 hours to Board; affected individuals without delay.
• Disaster Management Act 2005 (Act 53/2005) Sections 35, 37, 40, 51 to 60, N1, duties of Ministries/Departments/State; penalties for non-compliance with DM authority directions during a disaster.
• NDMA Guidelines on Chemical Disasters (Industrial) 2007, N2, on-site and off-site emergency plans for chemical industry (load-bearing for manufacturing).
• NDMA Guidelines on Preparation of DMPs 2014, N3, canonical DMP template (Prevention/Mitigation/Preparedness/Response/Relief/Recovery & Reconstruction/Capacity Building).
• Companies Act 2013 Section 134(3)(n), O1, Board's Report risk-management statement.
• Companies Act 2013 Section 177 + SEBI LODR Regulation 21, O2, Audit Committee + Risk Management Committee for listed entities.
• IT Act 2000 Sections 43, 65, 66, 70, 70A, 70B, 72, 84A, O3, the statutory bedrock; NCIIPC and CERT-In as interested parties.
• Cross-border regimes, if applicable: DORA Reg (EU) 2022/2554 (applies 17 Jan 2025) for EU-financial-sector exposure; APRA CPS 230 (eff. 1 Jul 2025) for Australian-parent captives; MAS TRM (18 Jan 2021) for Singapore-listed subsidiaries; HKMA TM-G-2/OR-2/SA-2 (31 May 2022) for Hong Kong AIs.

Each row gets the same treatment: instrument, citation, obligation summary, BCMS clauses consumed, internal owner, engagement owner, evidence location, refresh trigger, next refresh date, status.

Worked example. Vyom Cloud Services, a Bengaluru-headquartered SaaS firm serving Indian BFSI and EU fintech customers, ran a Step 4 exercise and built a 47-row obligations tracker covering 28 Indian instruments (RBI, SEBI, IRDAI, CERT-In, DPDP, Companies Act, IT Act, NDMA) and 19 cross-border or contractual regimes (DORA Arts 5, 6, 11, 12, 14, 19, 25, 26, 28 to 30; APRA CPS 230 paras 12 to 15, 34 to 46, 47 to 60; MAS TRM; HKMA OR-2; plus 14 enterprise-customer contractual SLAs). The tracker is the spine of Vyom's GRC platform; quarterly, Legal and Compliance run a "regulatory horizon scan" that adds new instruments and retires superseded ones (the SEBI CSCRF entry replaced the prior 2015 MII framework entry).

Step 5, Wire the outputs into downstream clauses

Output: A traceability matrix showing, for each material interested party and each material obligation, the downstream BCMS elements it shaped.

This is the step most practitioners skip, and it is the step that produces the audit finding most often. The traceability matrix has rows for each material obligation and columns for each downstream clause:

Every cell with a tick is a documented linkage. Every cell without one is a documented decision not to link, with rationale.

The audit logic: if your stakeholder register names CERT-In but your IR plan does not have a CERT-In 6-hour workflow, your 4.2 analysis is decorative. The traceability matrix is the audit-grade proof it is not.

Step 6, Keep it current (refresh cadence)

Output: A refresh calendar with scheduled reviews and event-trigger rules.

A 4.2 analysis that has not been updated since certification year is an L1 non-conformity waiting to be raised. Build a refresh cadence that has both time-based and event-based triggers:

Time-based:

• Full annual cycle (every interested-party category; every obligation).
• Quarterly obligations-tracker scan (regulatory and contractual horizon; new and superseded instruments).
• Quarterly stakeholder engagement health-check (top-10 parties; any new escalations or queries?).
• Annual climate-stakeholder review (post-Amendment 1:2024; explicit).
• Annual top-customer and top-supplier review (contract renewals; SLA changes).

Event-triggered:

• New or amended regulation, circular, or guideline from any applicable regulator.
• New customer contract or material contract amendment (especially SLA and BCP clauses).
• New supplier onboarding for a critical activity; supplier failure or near-miss.
• Post-incident (Clause 8.6 / 10.1): re-examine which stakeholders were affected, what expectations were unmet, what obligations were breached or narrowly met.
• Post-exercise (Clause 8.5) where drift was identified.
• Material change (M&A, divestiture, new geography, new product, new core system, new outsourcing arrangement, leadership change at top management or Board).
• Material new climate scenario (new IPCC report; new NGT ruling; new State Pollution Control Board direction; new insurer/reinsurer stance on climate risk).
• Material change in cross-border exposure (DORA applicability determined; new EU customer; MAS or APRA parent-group policy extension).
• Each Clause 9.3 management review and each audit finding cycle (Clauses 9.2 internal and Stage 1 / Stage 2 external).

Worked example. Vyom Cloud Services runs its full 4.2 cycle every January (ahead of the management review in March), a quarterly obligations-tracker scan (April, July, October), a quarterly top-10 stakeholder engagement health-check (same cadence), and an event-triggered refresh (the BCM Lead has a standing rule to log any new RBI/SEBI/IRDAI/CERT-In circular within 5 working days of issuance and triage its 4.2 impact within 15 working days). When SEBI's CSCRF (20 Aug 2024) was issued, Vyom's obligations tracker absorbed 17 new requirement rows in the August-to-October window; the same applied to the DPDP Rules 2025 in November 2025.

Pitfalls inside the worked method

Three failure modes recur inside this six-step method:

• The "customer only" trap. Many firms reduce 4.2 to "list the customers and the principal regulator". They miss employees, suppliers, board, investors, NGT, NCIIPC, the community, and (post-Amendment 1:2024) climate stakeholders. Avoid by seeding the Step 1 workshop with all seven categories and forcing at least one entry in each.
• The "needs equals requirements" trap. Some firms collapse needs, expectations and requirements into a single column. The result is an obligations tracker with no commercial intelligence, it tells you what is legally binding but not what your customers actually want. Avoid by keeping three columns distinct.
• The "register, no traceability" trap. Some firms build a beautiful stakeholder register and never wire it downstream. The audit finding is sharp: "your register lists CERT-In; your IR plan does not have a CERT-In workflow; please explain." Avoid by completing Step 5 (traceability matrix) before declaring 4.2 done.

Tools, Technologies, and Solutions

Clause 4.2 is primarily an analytic and documentary discipline, but tooling accelerates it materially, especially the obligations-tracker and stakeholder-engagement dimensions, which both benefit from GRC platforms, regulatory-content feeds, and contract-lifecycle management. The India-first tooling map below is illustrative; verify current pricing on the vendor's official domain.

The tooling stack for 4.2

The "buy vs build" question for growing companies

For most growing companies (50 to 250 staff), the right answer is spreadsheet + SharePoint first, GRC platform second. The reasons:

• The 4.2 analytics (relevance decision, needs/expectations/requirements decomposition, traceability) are judgement work, not tooling work. A spreadsheet is sufficient.
• The 4.2 bookkeeping (obligations tracker refresh, stakeholder engagement log, audit-evidence export) is where tooling pays off. A GRC platform earns its cost once the tracker exceeds 40 to 50 rows or the audit cycle approaches.
• The 4.2 operational dimension (regulator clocks, customer notifications) is where the IR/crisis-comms platform pays off. That trigger is when you have ≥3 concurrent reporting clocks (CERT-In + RBI + DPDP is a common Indian triad) or when a missed clock has actually happened.

Investment guidance for growing companies:

• L1 (one-off, ₹50,000 to ₹2 lakh): Build the spreadsheet stakeholder register and obligations tracker; buy a regulatory-content feed subscription for one year; do a single 4.2 cycle with internal staff.
• L2 (initial programme, ₹3 to ₹10 lakh): Same as L1, plus a half-day training for the BCM Lead and Legal/Compliance; plus a one-time consultative review by an external BCM advisor to validate the relevance decisions and traceability.
• L3 (mid-market, ₹15 to ₹40 lakh): GRC platform subscription; CLM for SLA extraction; IR/crisis-comms platform for the regulator clocks; annual external BCM advisory.
• L4 to L5 (enterprise, ₹50 lakh to ₹3 crore+): Integrated GRC + regulatory-content + CLM + IR platform; dedicated Compliance and BCM headcount; continuous regulatory-intelligence subscription; bilateral engagement programmes with top stakeholders.

What tooling cannot do

Tooling does not substitute for the judgement in 4.2: which parties are material, which expectations are load-bearing, which requirements shape the BCMS. A GRC platform makes the bookkeeping easier; it does not make the relevance decisions for you. The most common tooling-related audit finding is "you have a beautiful GRC platform with 200 stakeholder records, but the traceability to Clause 8.4 IR procedures is missing in 80 per cent of cases", i.e., tooling deployed without the underlying analytical method.

Policy and Procedure Templates

Clause 4.2 produces three canonical artefacts and feeds several policy layers. The toolkit (full templates in the toolkit folder) provides ready-to-customise versions; the structure is previewed here.

The Interested-Party and Stakeholder Requirements Policy

The top-management-approved policy that establishes 4.2 as a managed programme. It should state:

• The organisation's commitment to identifying interested parties and applicable requirements, per ISO 22301:2019 Clause 4.2 (as modified by Amendment 1:2024).
• The seven interested-party categories used.
• The relevance test (affects / affected by / perceives affected).
• The needs / expectations / requirements decomposition.
• The legal-regulatory obligations tracker as a controlled document.
• The traceability requirement into Clauses 4.3, 6.1, 6.2, 7.4, 8.4, 9.3.
• The refresh cadence (annual + quarterly + event-triggered).
• Top-management engagement (Board / Risk Committee approval).
• The BCM Lead as programme owner; engagement owners named for each material party.
• Honest-attribution and sourcing-discipline rules (contested attributions, e.g., the Mumbai 12 October 2020 blackout cyber link, are documented with both positions; unverified claims are marked as such).

A sample "shall" clause (Singahi's own drafting for adaptation):

ISO 22301:2019 Clause 4.2 asks organizations to work out which stakeholders matter to business continuity and what legal, regulatory, and other requirements apply.

The Interested-Party Analysis Procedure

The operating procedure for one full 4.2 cycle (the six-step method from Section 7). It should document:

• The workshop structure (attendees, agenda, outputs).
• The seven stakeholder categories.
• The relevance filters and the rationale documentation requirement.
• The needs/expectations/requirements decomposition template.
• The obligations tracker schema and seed instruments (Indian + cross-border).
• The traceability matrix schema.
• The refresh calendar.
• The integration points with Legal/Compliance (regulatory horizon scan), Customer Success (top-customer SLA review), Procurement (supplier BCP clauses), HR (employee expectations), Investor Relations, and Sustainability/ESG (climate stakeholders).

The Legal-Regulatory Obligations Tracker

The canonical artefact. The schema (from Section 7.4): Obligation ID, Instrument, Citation, Obligation summary, BCMS clauses consumed, Internal owner, Engagement owner, Evidence location, Refresh trigger, Next refresh date, Status. Seed with the Indian instruments listed in Section 7.4 plus any cross-border regimes applicable.

The Stakeholder Engagement Plan

A separate artefact (related to but distinct from the Clause 7.4 Communication Plan) that documents:

• The top-10 material stakeholders.
• For each: the engagement owner; the engagement frequency (e.g., quarterly business review with top-3 customers; semi-annual RBI self-assessment submission; annual investor day; annual climate-disclosure cycle); the engagement channels; the escalation paths; the success metrics.
• The engagement log (each engagement recorded with date, attendees, topics, commitments, follow-ups).

Integration with the BCMS Policy and Communication Plan

4.2 outputs feed directly into:

• Clause 5.2 BCMS Policy, the policy must commit to applicable requirements (the 4.2 obligations set is the source).
• Clause 7.4 Communication Plan, every material interested party has a communication requirement; 7.4 is the operational arm.
• Clause 8.4 Plans and Procedures, IR plan, crisis-comms plan, customer-notification workflows, regulator-notification workflows all derive from 4.2.
• Clause 9.3 Management Review, the 4.2 analysis is a standing input to management review.

Risk Assessment and Treatment

Clause 4.2 itself does not require risk treatment (that is Clause 6.1). But 4.2 seeds risk: every unmet obligation, every unfulfilled stakeholder expectation, every gap in the obligations tracker is a potential risk source. A clean 4.2-to-6.1 bridge is what auditors look for.

The 4.2-to-6.1 bridge

For each material obligation in the tracker, ask:

• Compliance risk, what is the likelihood and impact of non-compliance? (Regulator penalties, license suspension, criminal liability for directors under Companies Act 2013 Section 134(3)(n), reputational damage.)
• Stakeholder-expectation risk, what is the likelihood and impact of failing to meet a material stakeholder's expectations? (Customer churn; investor pressure; employee attrition; community opposition; media crisis.)
• Concentration risk, does a single stakeholder or single obligation dominate the risk profile? (e.g., a top-3 customer representing 30 per cent of revenue with a 1-hour notification SLA is a concentrated stakeholder-expectation risk; a single regulator whose action could suspend operations is a concentrated compliance risk.)
• Cascade risk, does failing one obligation trigger others? (e.g., missing the CERT-In 6-hour clock may itself become a separate observation in the next RBI inspection; missing the DPDP 72-hour clock exposes the firm to penalties up to ₹200 crore.)
• Cross-border risk, does an Indian obligation have a cross-border mirror that compounds the consequence? (e.g., DORA Art 19 major-incident reporting runs in parallel with CERT-In reporting; both must be met.)

Each risk identified flows into Clause 6.1's risk register with the standard fields (likelihood, impact, owner, treatment plan, residual risk, review date).

Treatment patterns

Typical treatment patterns for 4.2-sourced risks:

• Compliance-gap treatment, close the gap by building the missing capability (e.g., deploy a SIEM with 180-day retention to meet CERT-In log-retention; deploy a DLP to meet DPDP confidentiality; deploy a DRS to meet RBI RTO).
• Stakeholder-engagement treatment, change the stakeholder relationship to reduce the risk (renegotiate a customer SLA that is materially unmeetable; diversify away from a single-supplier concentration; establish a bilateral escalation channel with the regulator).
• Clock-coverage treatment, pre-build the workflows that meet regulator and customer clocks (IR plan templates; pre-approved customer-notification language; named incident managers).
• Insurance treatment, transfer residual risk via cyber insurance, business interruption insurance, D&O insurance (insurers are themselves interested parties whose underwriting expectations shape your controls).
• Acceptance, for low-materiality, low-criticability risks, document the acceptance with top-management approval and revisit at the next review.

Risk-assessment cadence

The 4.2-sourced risk review should align with the 4.2 refresh cadence: annual full cycle; quarterly scan for new risks from new obligations; event-triggered for material changes. The risk register should explicitly tag the 4.2 source for each risk so the traceability is preserved.

Audit and Compliance Checklist

The following 27 questions cover what a certification auditor (or a regulator) will typically test for Clause 4.2. For each, the expected evidence and the red flag are noted.

1. Coverage of interested-party categories. Evidence: stakeholder register with all seven categories represented (internal, employees, customers, regulators, suppliers, investors/insurers, community/climate). Red flag: register covers only customers and the principal regulator.
2. Documented relevance decision. Evidence: each candidate party has a relevance decision (relevant / not relevant) with a one-line rationale. Red flag: candidate list exists but no documented filtering.
3. Stakeholder register approved by top management. Evidence: Board / Risk Committee minutes approving the register. Red flag: register exists but no evidence of top-management approval.
4. Needs / expectations / requirements decomposition. Evidence: for each material party, three distinct columns or fields. Red flag: single-column "what they want" with no formality distinction.
5. Obligations tracker covers applicable Indian instruments. Evidence: tracker rows for RBI/SEBI/IRDAI (whichever apply), CERT-In, DPDP, Companies Act, IT Act, NDMA, plus any sector-specific. Red flag: tracker covers only 2 to 3 instruments.
6. Cross-border regimes captured where applicable. Evidence: DORA, APRA CPS 230, MAS TRM, HKMA, others as applicable. Red flag: firm has EU or APAC customers but no cross-border regime entries.
7. Each obligation has a named internal owner. Evidence: owner column populated; owner has acknowledged. Red flag: owner column blank or generic ("Legal").
8. Each obligation has a citation. Evidence: full citation (instrument, number, date) for every row. Red flag: vague references ("the RBI circular") without specifics.
9. Each obligation traces to downstream BCMS clauses. Evidence: traceability matrix populated. Red flag: tracker exists but no traceability into 7.4 / 8.4.
10. CERT-In 6-hour clock in the IR plan. Evidence: IR plan has a CERT-In workflow with a 6-hour clock and named PoC. Red flag: register names CERT-In but IR plan has no CERT-In workflow.
11. DPDP breach-notification workflow in the IR plan. Evidence: IR plan has a DPDP classification and a 72-hour Board-notification workflow. Red flag: register names DPDP but IR plan does not differentiate personal-data breaches.
12. RBI incident-reporting workflow (for BFSI). Evidence: IR plan has a RBI reporting workflow (2 to 6 hours per the relevant circular). Red flag: register names RBI but IR plan does not have the RBI workflow.
13. SEBI 6-hour incident-reporting workflow (for SEBI REs). Evidence: IR plan has a SEBI/CERT-In workflow. Red flag: SEBI named but no workflow.
14. Customer-contract SLAs captured. Evidence: tracker rows for top-3 to top-10 customer SLAs with named contract clause. Red flag: no customer-contractual rows in the tracker.
15. Supplier-BCP clauses captured. Evidence: tracker rows for material supplier contracts with BCP clause references. Red flag: no supplier rows.
16. Stakeholder engagement plan. Evidence: top-10 stakeholders with engagement frequency, channel, owner. Red flag: no engagement plan.
17. Engagement log. Evidence: dated log of stakeholder engagements with notes. Red flag: no log.
18. Refresh calendar. Evidence: annual, quarterly, event-triggered refresh documented. Red flag: no refresh calendar.
19. Last-refresh evidence. Evidence: version history showing actual refreshes in the last 12 months. Red flag: register last touched at certification.
20. Climate-stakeholder analysis (Amendment 1:2024). Evidence: climate-stakeholder entries (NGT, MoEFCC, SPCB, community, climate-active investors, insurer/reinsurer climate postures). Red flag: no climate dimension.
21. Honest-attribution rule applied. Evidence: contested attributions (e.g., Mumbai 12 Oct 2020 cyber link) documented with both positions. Red flag: contested claims asserted as fact.
22. Sourcing discipline. Evidence: quantitative claims sourced to primary instruments (RBI orders, SEBI circulars, NGT, NCLT, SEC filings, peer-reviewed studies); secondary-source claims marked "reported" or "[UNVERIFIED]". Red flag: unsourced numbers presented as fact.
23. Top-management engagement evidence. Evidence: Board / Risk Committee minutes referencing 4.2 outputs. Red flag: no board-level engagement.
24. Internal-audit coverage. Evidence: Clause 9.2 internal audit tests 4.2 traceability. Red flag: 4.2 not in the internal-audit plan.
25. Management-review input. Evidence: Clause 9.3 management review includes 4.2 outputs. Red flag: 4.2 absent from management review.
26. Corrective-action loop. Evidence: missed clocks, breached SLAs, audit findings feed into 10.1 corrective action and update the 4.2 analysis. Red flag: no feedback loop from incidents/audits back to 4.2.
27. Industry-specific coverage. Evidence: sector-specific stakeholders and obligations present (BFSI: NPCI, IBBI, IB; Healthcare: MoHFW, NPPA; Manufacturing: SPCB, factories inspectorate, NDMA chemical-disaster guidelines; Government: CAG, CVC, NIC, NCIIPC). Red flag: generic stakeholder list not adapted to the sector.

Metrics and KPIs

Clause 4.2 itself is a context-of-the-organisation clause; its KPIs are mostly process and outcome measures of the interested-party programme. The following 14 KPIs cover the spectrum.

Process KPIs

1. Interested-party register coverage, number of relevant parties per category, trend over time. Target: ≥1 in each of the 7 categories; stable or growing count year-on-year (after accounting for deliberate not-relevant decisions).
2. Obligations-tracker completeness, percentage of applicable instruments captured. Formula: (captured instruments / applicable instruments per legal review) × 100. Target: 100 per cent. Frequency: quarterly.
3. Obligations-tracker freshness, percentage of tracker rows refreshed within the past 12 months. Target: ≥95 per cent. Frequency: quarterly.
4. Traceability completeness, percentage of material obligations with a populated traceability matrix row. Target: 100 per cent. Frequency: quarterly.
5. Refresh cadence adherence, percentage of scheduled refreshes completed on time. Target: 100 per cent. Frequency: quarterly.

Outcome KPIs

6. Regulator-reporting-clock adherence, percentage of regulator clocks met within the prescribed window (CERT-In 6 hours; DPDP 72 hours; RBI 2 to 6 hours; SEBI 6 hours; APRA 24/72 hours; DORA per Art 19). Target: 100 per cent. Frequency: per incident, with rolling 12-month reporting.
7. Customer-notification-SLA adherence, percentage of customer-contractual notification SLAs met. Target: 100 per cent for top-3 customers; ≥95 per cent for top-20. Frequency: per incident.
8. Internal-stakeholder-notification adherence, percentage of internal notification workflows executed on time (Board, Audit Committee, Risk Committee, employees). Target: 100 per cent.
9. Stakeholder-experience score post-incident, top-10 stakeholders' satisfaction with the organisation's incident handling, captured in a structured post-incident survey. Target: ≥4 out of 5. Frequency: per major incident.
10. Audit findings on Clause 4.2, number of findings raised by internal and external audit on 4.2. Target: zero major, ≤2 minor per cycle. Frequency: per audit cycle.
11. Compliance breaches (4.2-sourced), number of compliance breaches attributable to a 4.2 gap (e.g., missed CERT-In clock because CERT-In was not in the IR plan). Target: zero. Frequency: rolling 12 months.
12. Contractual-penalty exposure, total INR exposure to contractual penalties from breached SLAs in the rolling 12 months. Target: zero. Frequency: monthly.
13. Engagement cadence adherence, percentage of scheduled stakeholder engagements (top-10) completed. Target: ≥95 per cent. Frequency: quarterly.
14. Time-to-engagement-detection, time from a stakeholder raising an issue to it being captured in the 4.2 register. Target: ≤5 working days. Frequency: rolling.

A sample Clause 4.2 dashboard view (board-pack ready):

Common Pitfalls and Audit Failures

Across BCM programmes the same 4.2 failure modes recur. They are named here so you can audit yourself before the auditor does.

• The "customers and regulator" reduction. The register covers customers and the principal regulator and stops. Misses: employees, suppliers, board, investors, NGT, NCIIPC, community, climate stakeholders. Fix: seed Step 1 with all seven categories; force one entry per category minimum.
• The "verbatim book examples" anti-pattern. ABCM practitioner reproduces a textbook stakeholder-map figure verbatim. Fix: never reproduce a reference book's examples; re-state the principle in your own words and use your own organisation's data.
• The "needs equals requirements" collapse. The matrix has one column ("what they want"); commercial intelligence is lost. Fix: keep three columns distinct.
• The "obligations tracker that stops at RBI". BFSI firms stop at RBI; SEBI-regulated firms stop at SEBI; nobody captures CERT-In, DPDP, NDMA, Companies Act, IT Act, NGT, NCIIPC. Fix: seed the tracker with all 15-plus Indian instruments in Section 7.4; add cross-border where applicable.
• The "register without traceability" failure. A beautiful stakeholder register with no downstream wiring. Fix: complete the traceability matrix before declaring 4.2 done.
• The "IR plan that omits the regulator clocks". Register names CERT-In, DPDP, RBI; IR plan does not have the workflows. Fix: each material obligation must have a workflow in Clause 7.4 / 8.4.
• The "register that has not been refreshed" failure. Last touched at certification year; multiple new instruments (SEBI CSCRF, DPDP Rules) issued since. Fix: quarterly obligations-tracker scan; document version history.
• The "engagement owner not named" failure. Obligation rows have no named owner; on the day, nobody knows who owns the CERT-In clock. Fix: name the engagement owner and the internal owner for every row.
• The "single-source attribution" failure. The Mumbai 12 October 2020 blackout cyber link is asserted as fact (RedEcho caused it). Fix: present both positions (Maharashtra State Cyber cell vs Union Power Ministry); never assert a contested attribution.
• The "withdrawn-edition" failure. Citing ISO 22300:2018, ISO/TS 22317:2015, or ISO/TS 22318:2015 (all withdrawn). Fix: cite the current editions (ISO 22300:2021; ISO/TS 22317:2021; ISO/TS 22318:2021).
• The "DORA June 2025" failure. Mis-citing a "June 2025 DORA date". Fix: DORA applies from 17 January 2025; the mid-2025 prudential date is APRA CPS 230 (1 July 2025).
• The "BSI conflation" failure. Confusing the German BSI (bsi.bund.de, the federal cybersecurity authority) with BSI Group (the certification body). Fix: distinguish explicitly when citing either.
• The "Amendment 1:2024 ignored" failure. No climate-stakeholder analysis despite the Amendment being in force. Fix: add a climate-stakeholder row to every interested-party category; revisit annually.
• The "competitor name dropped" failure. Naming a compliance-automation vendor, a BCM consultant, or any other competitor in the stakeholder register or the tooling matrix. Fix: never name a competitor in the published BCMS documents; describe the category generically.
• The "booking link in the policy" failure. Embedding a meeting-booking or scheduling link in the stakeholder-engagement plan or the policy. Fix: keep engagement channels in the operational engagement plan; do not embed booking links in the controlled BCMS documents.

Illustrative Scenario 1: Failure, Dharini Finserve (Illustrative)

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

Disclaimer: The following scenario is illustrative. It is drawn from composite patterns observed across Indian mid-market NBFCs and from the publicly documented RBI enforcement actions on HDFC Bank (2 December 2020) and other REs. The organisation "Dharini Finserve" is fictional; the regulatory instruments, clocks and consequence patterns are real.

The organisation

Dharini Finserve Pvt. Ltd., a Mumbai-based mid-market NBFC (1,100 staff; ₹4,200 crore AUM; 28 branches across Maharashtra, Gujarat, Karnataka; lending focus: working-capital and LAP against commercial real estate). Regulated by RBI under the Master Direction IT Governance (eff. 1 April 2024) and the Master Direction Outsourcing of IT Services; also subject to CERT-In Directions, DPDP Act 2023, and Companies Act 2013.

The 4.2 posture at T-6 months

Dharini's BCM programme had been certified to ISO 22301:2019 in 2022 (Stage 1 + Stage 2 clean; surveillance audit 2023 clean). The 4.2 artefact was a 23-row stakeholder register covering customers, RBI, employees, suppliers, and the Board. The obligations tracker had 9 rows: RBI MD IT Governance, RBI Cyber Security Framework, SEBI BCP-DR (for the NCD programme), IRDAI (for a small insurance-broking subsidiary), CERT-In Directions, DPDP Act, Companies Act, IT Act, NDMA. The register was last refreshed in March 2023. There was no climate-stakeholder analysis. The traceability matrix was partially populated, IR plan had the RBI workflow but no DPDP workflow and no NPCI workflow; the customer-notification workflow existed for the top-3 customers but not for the top-20.

The incident (T = 0)

On a Monday in monsoon season, a ransomware actor (suspected LockBit affiliate) compromised Dharini's core-lending-system vendor through a phishing attack on the vendor's India engineering team. The vendor's CLS-as-a-Service went offline at 03:17 IST. Dharini's operations team detected the outage at 06:48 IST (T+3h31m) when branches opened and could not process drawdowns. The CISO was paged at 07:12 IST (T+3h55m). The vendor confirmed ransomware at 09:30 IST (T+6h13m). Customer data of approximately 4.1 lakh borrowers was suspected exfiltrated (later confirmed).

What went wrong, the 4.2 failures

• CERT-In clock breached. Dharini's IR plan said "notify CERT-In within 6 hours of detection". Detection was at 06:48 IST; the 6-hour clock expired at 12:48 IST. The CISO escalated to Legal at 09:30; Legal began preparing the CERT-In report at 10:15; the report was submitted at 14:22 IST, 7 hours 34 minutes after detection. 4.2 root cause: the IR plan did not have a pre-built CERT-In reporting workflow; the engagement owner was not named in the 4.2 register for CERT-In (Legal "owned" it operationally but had never been designated the 4.2 engagement owner); the reporting template was not pre-populated. The 4.2 stakeholder register named CERT-In but the obligation did not trace cleanly into Clause 8.4.
• DPDP clock breached. Personal data of ~4.1 lakh borrowers was exfiltrated; the DPDP 72-hour clock to notify the Data Protection Board started at detection (06:48 IST Tuesday). Dharini's IR plan did not have a DPDP classification workflow, the 4.2 obligations tracker named DPDP but the traceability to 8.4 was blank. Legal prepared the DPDP notification on Thursday (T+72h 11m); it was filed on Friday (T+85h 40m). Penalty exposure: up to ₹200 crore for non-notification within the prescribed window.
• Top-customer SLA breached. Dharini's top customer (the listed manufacturer from Section 7.3) had a 1-hour notification clause. The customer was notified at T+5h 22m when the relationship manager happened to call about an unrelated matter and was told by the customer's treasury team that "we heard from our banking partner that there is an industry-wide IT issue". The customer invoked a manual-processing fallback, then a penalty clause (₹40 lakh per day of drawdown disruption beyond 4 hours). Five-day drawdown disruption: ₹2 crore penalty plus accelerated renegotiation of the master agreement.
• RBI clock breached. Dharini's IR plan said "notify RBI Senior Supervisory Manager within 2 to 6 hours of detection depending on severity". Notification was sent at T+9h 18m. RBI issued a show-cause notice for delayed reporting within 14 days.
• Supplier-BCP failure invisible to Dharini. The core-lending-system vendor's own BCP had not been reviewed by Dharini's Procurement since contract signing in 2019. The vendor's recovery estimate was 5 to 7 days; Dharini had modelled 4 hours based on the vendor's marketing collateral. RBI MD Outsourcing of IT Services (10 April 2023) made Dharini responsible for the vendor's BCP posture, the 4.2 obligations tracker had the row, but the traceability into Clause 8.1 (outsourced activities) and Clause 8.2 (dependency analysis) was blank.
• Employee and union communication gaps. Branch staff learnt of the incident from customer anger, not from internal communication. The Maharashtra union filed a complaint with the Regional Labour Commissioner; two branches saw half-day stopwork.
• Media and community communication gaps. The Marathi regional press ran the story 36 hours after the incident; the spokesperson was the Head of Marketing who had not been briefed; Dharini's stock (BSE-listed NCD programme) dropped 4.2 per cent on the news.

The financial impact

The post-incident 4.2 overhaul

Dharini's post-incident corrective action (Clause 10.1) included a full 4.2 rebuild:

• The stakeholder register was rebuilt using the seven-category structure in Section 7.1; party count went from 23 to 61.
• The obligations tracker went from 9 rows to 43 rows, with named engagement owners and citations.
• The traceability matrix was populated end-to-end; the IR plan absorbed CERT-In, DPDP, RBI, NPCI, top-20 customer and union workflows.
• Climate-stakeholder analysis was added (Amendment 1:2024 compliance): NGT, State Pollution Control Board, the corporate office's flood-risk community in Lower Parel, and the reinsurer's climate-posture queries.
• The refresh calendar went from "yearly, mostly skipped" to "annual full cycle, quarterly scan, event-triggered".
• The Board commissioned an external BCM advisor to run two cycles (the post-incident rebuild and the first refresh cycle a year later) before re-internalising the programme.

Lessons (in ISO 22301 clause language)

• 4.2 is the requirements-translation clause. Without it, your IR plan is a generic document that meets none of your specific obligations on the day.
• Traceability is not optional. A register without traceability is decorative.
• Engagement owners must be named before the incident, not during it. On the day, the question "who owns the CERT-In clock?" cannot be answered by a committee.
• Supplier-BCP is your BCP. RBI's Outsourcing MD makes the regulated entity responsible, the 4.2 traceability into Clauses 8.1 and 8.2 must reflect that.
• Customer SLAs are typically tighter than regulator clocks. Most growing companies discover this only when the penalty clause is invoked.
• DPDP penalty exposure is non-trivial. Up to ₹200 crore for non-notification is the floor of consequences; the bigger hit is reputational and customer-churn.

Illustrative Scenario 2: Success, Vyom Cloud Services (Illustrative, with ROI)

Disclaimer: The following scenario is illustrative. It is drawn from composite patterns observed across Indian SaaS firms that have invested in 4.2 maturity, including the publicly documented post-2015 Chennai-flood business-continuity responses of India-based IT-services firms. The organisation "Vyom Cloud Services" is fictional; the regulatory instruments and ROI patterns are real.

The organisation

Vyom Cloud Services Pvt. Ltd., a Bengaluru-headquartered B2B SaaS firm (540 staff; ₹220 crore ARR; product: a multi-tenant data-platform serving 14 enterprise customers in Indian BFSI and EU fintech). Regulated indirectly: Indian customers pass through their RBI/SEBI/IRDAI obligations via contractual flow-down; EU customers pass through DORA obligations via contractual flow-down. Direct obligations: CERT-In, DPDP, Companies Act, IT Act; SEBI LODR (Vyom is planning an IPO).

The 4.2 investment

In 2024, Vyom's Board (preparing for IPO) commissioned a 4.2 maturity uplift from L2 to L4. The investment over 14 months:

The 4.2 implementation

Vyom ran the six-step method (Section 7) over 14 weeks:

• Step 1, Candidate list of 78 parties spanning all seven categories.
• Step 2, Relevance decisions documented; 63 relevant, 15 not-relevant (with rationale).
• Step 3, Needs/expectations/requirements matrix built for all 63, including the 14 enterprise customers (each with bespoke contractual SLAs), 31 material suppliers, 9 regulators/government bodies (RBI via customers, SEBI, IRDAI via customers, CERT-In, MeitY, DPDP Board, NCIIPC for one customer's CII designation, two EU regulators via DORA flow-down, one Australian regulator via APRA flow-down), 2 PE investors, 1 IPO underwriter, 4 insurers, 2 rating agencies, the Board, three committees (Audit, Risk, Nomination & Remuneration), employees (segmented), and 6 climate-stakeholder rows.
• Step 4, Obligations tracker with 47 rows: 28 Indian instruments + 19 cross-border or contractual regimes.
• Step 5, Traceability matrix populated end-to-end: every material obligation mapped to downstream clauses; every cell either ticked or documented as not-applicable.
• Step 6, Refresh calendar: annual full cycle in January; quarterly scan in April/July/October; event-triggered refresh on regulatory and customer-contract changes.

The operational test, a real incident

Eight months after go-live, Vyom's primary cloud provider had a regional outage (a 7-hour partial failure of one availability zone). Vyom's platform was designed for multi-AZ failover and remained available, but 3 of the 14 enterprise customers were in the affected region and saw elevated latency for 2 hours 40 minutes.

• T+0, Outage detected by Vyom's SOC (automated).
• T+3m, Incident manager paged; crisis-management team convened within 11 minutes.
• T+12m, Affected customers identified (the 3 in the affected region); pre-approved notification language pulled from the IR platform; first customer notification sent at T+18m (within Vyom's 30-minute SLA with all three).
• T+34m, Internal escalation to the Board's Risk Committee chair (Vyom's policy: any incident affecting >2 enterprise customers notifies the RC chair within 1 hour).
• T+1h 12m, CERT-In assessment: incident qualified as a cloud-outage reportable event under CERT-In Directions Annexure I; CERT-In report submitted at T+5h 49m (within the 6-hour clock).
• T+2h 40m, Latency resolved via automatic failover; customers notified of resolution.
• T+3h 30m, DPDP assessment: a small subset of one customer's transaction metadata had been temporarily visible to another tenant due to a configuration drift exposed by the failover (no exfiltration; but a personal-data incident). The DPDP 72-hour clock to the Board started at T+3h 30m; report submitted at T+38h 20m (within the clock).
• T+24h, Preliminary post-incident review with affected customers.
• T+72h, Complete post-incident report delivered to top-3 customers (Vyom's contractual commitment).
• T+15 days, Full post-incident report published to all affected customers with root cause, corrective actions, and SLA-credit application.

The ROI

The intangible ROI

• Board confidence. The Risk Committee chair's standing feedback: "I knew within an hour; I knew what the team was doing about it; I knew what we owed the regulators and the customers. That is what 4.2 buys."
• Customer trust. One of the 3 affected customers' CISO wrote in a post-incident note: "We were notified before our monitoring caught it. That is what we expect from a vendor."
• Employee clarity. The IR runbook was a single click away for everyone in the incident path; nobody improvised.
• Regulator regard. CERT-In's liaison feedback in the next industry workshop cited Vyom's notification as "structured, on time, with the right data", a small thing that pays in the next interaction.

Lessons

• 4.2 is the cheapest insurance a growing SaaS firm can buy. The payback is measured in weeks once it includes the customer-notification workflows and the regulator clocks.
• Traceability is the multiplier. The same stakeholder register, untraced, would have given Vyom maybe 30 per cent of the benefit.
• Cross-border obligations are an Indian SaaS reality. DORA, APRA CPS 230, MAS TRM flow through customer contracts whether or not the Indian firm is directly regulated.
• Climate-stakeholder analysis is not a formality. Vyom's insurers and reinsurers explicitly asked climate questions in the renewal cycle; the 4.2 climate-stakeholder row made the answers defensible.
• The Board is a high-stakes interested party. Getting the Board clear, accurate, on-time information during an incident is itself a Clause 4.2 outcome, and it shapes everything from IPO timing to insurance pricing.

Multi-Framework Mapping

Clause 4.2 maps cleanly across the BCM and operational-resilience frameworks. The table below is the canonical crosswalk for an Indian organisation mapping 4.2 outward.

The full crosswalk

Indian-instrument-to-ISO-22301-clause mapping (4.2-driven subset)

How to use the crosswalk

• Build the obligations tracker from the Indian-instrument column. Start there; add cross-border only where your business case requires.
• Map each row to the BCMS clauses in the middle column. This is the traceability matrix.
• Cross-check coverage against the framework rows. If a customer's audit team asks "do you map to NIST CSF 2.0 Govern?", you have the answer ready.

Implementation Roadmap

A phased 30/90/180-day roadmap to take a growing company from "spreadsheet-only" 4.2 to a defensible, audit-ready, traceable programme.

Phase 0, Pre-work (Weeks minus 2 to 0)

• Executive sponsor identified. Usually COO/CRO/CIO. Names the BCM Lead.
• Scope of the 4.2 cycle confirmed. Usually whole-entity for growing companies.
• Cross-functional team identified. Legal, Compliance, Risk, CISO, Customer Success, Procurement, HR, Investor Relations, Facilities, Sustainability/ESG.
• Initial maturity self-assessment using the L1 to L5 rubric (Section 22).

Phase 1, Days 1 to 30 (Foundation)

• Week 1: Step 1 candidate-list workshop (90 minutes; cross-functional). Output: 30 to 60+ candidate parties.
• Week 2: Step 2 relevance decisions. Output: relevant/not-relevant with rationale.
• Week 3: Step 3 needs/expectations/requirements decomposition begins (top-10 stakeholders first).
• Week 4: Draft Interested-Party and Stakeholder Requirements Policy circulated for review.
• Day 30 milestone (M30): Candidate list, relevance decisions, top-10 stakeholder decompositions, and draft Policy ready.

Phase 2, Days 31 to 90 (Build)

• Month 2: Complete Step 3 for all relevant parties; begin Step 4 obligations tracker build (seed with the 15+ Indian instruments in Section 7.4).
• Month 3: Step 4 obligations tracker populated; Step 5 traceability matrix drafted; cross-functional review.
• Day 90 milestone (M90): Full stakeholder register; needs/expectations/requirements matrix; obligations tracker with 30+ rows; draft traceability matrix; Policy and Procedure approved by top management.

Phase 3, Days 91 to 180 (Operationalise)

• Month 4: Traceability matrix validated end-to-end; gaps with Clause 7.4 (communication), Clause 8.4 (IR procedures), Clause 8.2 (BIA), Clause 8.3 (strategy) closed.
• Month 5: IR plan updated with regulator-clock workflows (CERT-In 6 hrs; DPDP 72 hrs; RBI 2 to 6 hrs; SEBI 6 hrs as applicable); customer-notification workflows for top-3 customers; supplier-BCP review initiated.
• Month 6: First tabletop exercise validating the IR plan and the 4.2 traceability; management review; KPI dashboard live.
• Day 180 milestone (M180): IR plan with all material obligations workflowed; first exercise completed with 4.2 outcomes captured; KPI dashboard live; management review completed; first quarterly obligations-tracker scan scheduled.

Phase 4, Days 181+ (Sustain and Improve)

• Quarterly: Obligations-tracker scan; top-10 stakeholder engagement health-check.
• Semi-annually: Top-customer and top-supplier contract review.
• Annually: Full 4.2 cycle; climate-stakeholder review (Amendment 1:2024); Board / Risk Committee approval; integration with Clause 9.3 management review.
• Event-triggered: New regulation, new customer, new supplier, post-incident, post-exercise, material change.

Industry-specific timing notes

• BFSI: Compress Phase 1 to 3 weeks (regulator expectations already established). Align M180 with the next RBI inspection cycle.
• Healthcare: Extend Phase 1 to 6 weeks (clinical-stakeholder engagement takes longer). Patient-representative bodies need time to engage.
• Manufacturing (chemical): Compress Phase 1 to 3 weeks (NDMA / SPCB engagement is statutory, not optional).
• Government/PSU: Extend Phase 1 to 8 weeks (multi-departmental stakeholder engagement; RTI transparency expectations).

FAQ

Q1. Does Clause 4.2 require us to engage with every stakeholder? No. ISO 22301:2019 Clause 4.2 asks organizations to work out which interested parties matter to business continuity. Relevance is a documented decision; parties assessed not-relevant (with rationale) are revisited at the next review.

Q2. We already have an ISO/IEC 27001:2022 ISMS with a stakeholder register. Can we reuse it? Yes. ISO/IEC 27001:2022 Clause 4.2 covers the same concept for the ISMS; an integrated ISMS+BCMS can share one stakeholder register and obligations tracker. The 4.2 obligations tracker is typically a superset of the ISMS version because BCM-specific instruments (RBI BCP-DR, SEBI BCP-DR for MIIs, NDMA, Disaster Management Act) go beyond pure information-security.

Q3. Do we have to include climate stakeholders (Amendment 1:2024) if we are a small firm? Yes, but the depth scales. A 50-person SaaS firm needs at least a documented decision about which climate stakeholders (insurer, landlord, employees, regulator) are material. A chemical manufacturing firm needs a deeper climate-stakeholder analysis including NGT, SPCB, community, and reinsurer.

Q4. What is the difference between Clause 4.1 (context) and Clause 4.2 (interested parties)? 4.1 names the issues (the topics, trends, and circumstances that affect the organisation's ability to deliver). 4.2 names the people, organisations and authorities those issues flow through, and converts their needs/expectations into BCMS requirements. 4.1 is "what world are we operating in?"; 4.2 is "who cares, and what do they want?".

Q5. The CERT-In 6-hour clock starts when, at detection or at confirmation? At noticing. The CERT-In Directions (28 April 2022) require reporting within 6 hours of noticing a reportable incident. Detection by your SOC counts as noticing. "We were still confirming" is not a defensible reason to extend the clock.

Q6. The DPDP 72-hour clock starts when? Per the DPDP Rules 2025, the clock starts when the Data Fiduciary becomes aware of a personal-data breach. Awareness is a fact-specific determination; pre-built classification workflows (in your IR plan) help you demonstrate when awareness occurred.

Q7. How do we capture cross-border requirements when we are not ourselves DORA-regulated? Through customer contracts. If you serve EU financial-sector customers, they will pass through DORA obligations (Arts 28 to 30 on third-party risk; Art 19 on incident reporting; Art 25 to 26 on testing) via contractual flow-down. Your 4.2 obligations tracker should capture these as contractual requirements with the customer named as the engagement owner.

Q8. The Mumbai 12 October 2020 blackout cyber link, should we cite RedEcho in our 4.2 analysis? Present both positions. The Maharashtra State Cyber Cell and the Recorded Future report (Feb to Mar 2021) attributed suspected grid intrusion to RedEcho/ShadowPad; the Union Power Ministry attributed the outage to human error and load issues, not a cyber attack. Cite both; do not assert a single attribution. The operational lesson (grid dependency) is valid regardless.

Q9. Do we have to name our competitors in the stakeholder register (as "alternative suppliers" or "industry peers")? No. Never name a competitor in the published BCMS documents. Describe categories generically ("industry peers", "alternative suppliers in the cloud-monitoring category").

Q10. How often should we refresh the obligations tracker? At least annually (full cycle); at least quarterly for a regulatory scan (new instruments, superseded instruments); and event-triggered (new or amended regulation; new customer; new supplier; post-incident; post-exercise; material change).

Q11. Can a single person own the entire 4.2 programme? For small firms (10 to 50 staff), yes, usually the BCM Lead wearing multiple hats. For growing companies (50 to 250) and above, no, engagement owners must be named per material obligation because on the day, the question "who owns the CERT-In clock?" cannot be answered by a single over-stretched individual.

Q12. Our Board does not seem engaged in 4.2. What do we do? Anchor 4.2 in what the Board already cares about: Companies Act 2013 Section 134(3)(n) (board's-report risk statement); SEBI LODR Regulation 21 (Risk Management Committee for listed entities); RBI inspection findings; customer escalations; investor ESG queries. Frame 4.2 as the artefact that satisfies board-level risk-oversight duties. If engagement does not follow, escalate via the Risk Committee chair or the external auditor.

Q13. We have a Stage 1 audit in 6 weeks and our 4.2 is at L1. What is the minimum viable path? (a) Build a 7-category candidate list; (b) document relevance decisions for all; (c) for the top-10 stakeholders, complete the needs/expectations/requirements decomposition; (d) build a 15+ row obligations tracker (the Indian instruments in Section 7.4); (e) draft the traceability matrix for the top-10; (f) have top management approve; (g) schedule the post-Stage-1 remediation to L3. That is the L1 to L2 path; expect Stage 1 to identify L2-to-L3 gaps.

Q14. Is "interested party" the same as "stakeholder"? Yes, in ISO 22301:2019 and ISO/IEC Directives they are synonyms. Use them interchangeably; pick one term per document and footnote the other.

Q15. Do we need to engage with our competitors' BCM postures? Generally no, but industry-level resilience matters. Industry bodies (NASSCOM, CII, FICCI, ASSOCHAM, DSCI, BCI Forum India) are often the right vehicle for industry-level engagement without competitor-specific disclosure. Sector-specific mutual-aid arrangements (e.g., banking-sector contingency arrangements via IDRBT) exist for some sectors.

Industry-Specific Requirements

BFSI, banks, NBFCs, payment system operators, insurers

BFSI is the densest interested-party environment in the Indian economy. A mid-market NBFC can simultaneously be regulated by RBI (Master Direction IT Governance; Master Direction Outsourcing of IT Services; the Cyber Security Framework), by SEBI (for an NCD programme), by IRDAI (for an insurance-broking subsidiary), and by CERT-In (horizontally); each is a distinct interested party with distinct needs and distinct clocks. Depositors/policyholders/investors are high-stakes stakeholders (deposit continuity, payment continuity, claim continuity). NPCI is a key interested party for any payment operator (the UPI 12 April 2025 ~5-hour nationwide degradation showed the ecosystem blast radius). Rating agencies (CRISIL, ICRA, CARE, India Ratings) factor BCM posture into credit rating. The Reserve Bank's Ombudsman is an interested party for customer-experience BCM outcomes.

Specific 4.2 emphasis: RBI RTO/RPO obligations on critical systems (per the IT Service Continuity chapter of the Master Direction); SEBI RTO ≤ 2 hours for critical MII systems (per BCP-DR for MIIs); NPCI UPI / RuPay availability; RBI Ombudsman complaint volumes; rating-agency engagement; deposit-insurance (DICGC) continuity expectations.

Healthcare, hospitals, pharma, medtech

Healthcare has the highest stake criticability: the patient is a life-safety stakeholder, not just a customer. Hospitals' interested parties include patients, patients' families, clinicians, MoHFW, state health departments, IRDAI (for insured care), the Clinical Establishments Act regulators in states that have enacted it, NPPA (for drug pricing), FDA/EMA for export-driven pharma, NARC for stressed hospital loans, and (for hospitals operating as DPDP Significant Data Fiduciaries) the DPDP Board. Health-data breach notification (under DPDP and, where applicable, HIPAA for US-bound patients) is a tight clock.

Specific 4.2 emphasis: AIIMS Delhi ransomware (23 November 2022) showed what failure looks like, primary and backup servers encrypted, e-Hospital down ~6 to 15 days, OPD/admissions/billing/labs reverted to paper, NIA cyberterrorism probe. Patient-safety stakeholder expectations drive near-zero RTO for clinical systems.

IT/ITeS and SaaS

IT-services and SaaS firms have a distinctive 4.2 signature: enterprise customers with bespoke BCM clauses (often tighter than regulator clocks), cross-border regimes (DORA, APRA CPS 230, MAS TRM, HKMA OR-2) flowing through customer contracts, downstream customers-of-customers (a SaaS firm serving EU banks serves their end-customers indirectly), and dense supplier dependencies (cloud, identity, observability, payments). Chennai 2015 (Cognizant's 11 delivery/operations centres affected by monsoon flooding; the firm invoked BCP, relocated staff cross-city, and reaffirmed ≥US$12.41 billion FY2015 revenue guidance) showed what mature 4.2 posture enables.

Specific 4.2 emphasis: enterprise-customer contractual SLAs (1-hour notification, named incident manager, quarterly business-continuity briefing); cross-border regime flow-down; SaaS-dependency on cloud and identity providers; mutual-aid arrangements across delivery centres.

Manufacturing, chemicals, automotive, electronics, pharma manufacturing

Manufacturing's 4.2 signature is dominated by the local community as a life-safety stakeholder and by environmental regulators (NGT, MoEFCC, State Pollution Control Boards, factories inspectorate). LG Polymers Vizag (7 May 2020; 12 to 13 fatalities; NGT interim penalty ₹50 crore; LG Chem ₹730 crore relief package; plant permanently closed) is the extreme-case 4.2 failure: the regulatory and environmental context was not properly identified, and the continuity arrangements did not match. NDMA Guidelines on Chemical Disasters (Industrial) 2007 are explicitly load-bearing, on-site and off-site emergency plans, integration with District DMPs, mutual-aid arrangements. Maruti Suzuki Manesar (18 July 2012; mob violence and fire; one fatality; ~1,400 crore lockout loss) showed that workplace violence / industrial relations is a 4.2-stakeholder dimension, not just fire/flood/cyber. Tata Technologies, Sun Pharmaceutical, Bajaj Auto and Tata Electronics ransomware incidents (2023 onwards) show that pharma/manufacturing ransomware containment is itself a production-stoppage decision.

Specific 4.2 emphasis: on-site and off-site emergency plans; community engagement; NDMA chemical-disaster guidelines; State Pollution Control Board directions; NGT engagement; factories inspectorate; tier-2 and tier-3 supplier BCM posture; workplace-violence stakeholder expectations.

Government and PSUs

Government bodies and PSUs operate under a distinctive 4.2 regime: the Legislature (questions, committees), the Auditor (CAG), the CVC (vigilance), the parent Ministry, NIC and NCIIPC for systems, RTI-driven public transparency, and the citizen as a high-expectation stakeholder. NDMA's guidelines on Preparation of Disaster Management Plans for Ministries/Departments (2014) provide the canonical DMP template. The Disaster Management Act 2005 imposes statutory duties on Ministries, Departments, States and local authorities (Sections 35, 37, 40), with penalties for non-compliance during a disaster (Sections 51 to 60). The Mumbai 12 October 2020 blackout illustrated grid dependency as a 4.2 issue for infrastructure-dependent PSUs (the cyber attribution remains contested between Maharashtra State Cyber cell and the Union Power Ministry, present both positions).

Specific 4.2 emphasis: Legislature/CAG/CVC engagement; NIC and NCIIPC for protected systems; RTI transparency; NDMA / SDMA / DDMA stakeholder relationships; citizen as stakeholder; mutual-aid with sister PSUs.

Maturity Model

The 4.2 maturity model has five levels. Each level is described by its posture, its typical artefacts, its likely audit findings, and the investment required to reach it from the level below. Investment estimates are indicative for a growing company (50 to 250 staff) and scale up for larger organisations.

Level 1, Initial / Ad Hoc

• Posture: A spreadsheet list of customers and the principal regulator. No relevance decisions documented. No needs/expectations/requirements decomposition. No obligations tracker. No traceability.
• Artefacts: One-page stakeholder list (5 to 10 parties).
• Audit finding (likely): Major non-conformity on 4.2. Findings on traceability into 7.4, 8.4. Climate (Amendment 1:2024) not addressed.
• Investment to reach L2: ₹2 to 6 lakh of internal effort (workshop time) plus ₹50,000 to ₹2 lakh for a regulatory-content feed subscription.

Level 2, Defined

• Posture: A structured stakeholder register with all seven categories represented. Relevance decisions documented for all. Needs/expectations/requirements decomposition done for the top-10 stakeholders. Obligations tracker with 15+ Indian instruments. Partial traceability into 7.4 and 8.4. Annual refresh, semi-annual scan.
• Artefacts: Stakeholder register; obligations tracker; top-10 needs/expectations matrix; partial traceability matrix; draft Policy.
• Audit finding (likely): Minor non-conformities on traceability depth; missing climate-stakeholder analysis (Amendment 1:2024); cross-border regimes not yet captured.
• Investment to reach L3: ₹8 to 25 lakh (external BCM advisory; full-traceability build; climate-stakeholder analysis; cross-border regime capture; first tabletop exercise).

Level 3, Managed

• Posture: Full stakeholder register (50+ parties); full obligations tracker (30+ rows) including cross-border regimes; full traceability matrix; climate-stakeholder analysis; quarterly scan; event-triggered refresh; IR plan with regulator-clock workflows; named engagement owners for material obligations.
• Artefacts: Above plus IR plan with regulator workflows; KPI dashboard; Board / Risk Committee approval; first exercise after.
• Audit finding (likely): Clean on 4.2; possible minor finding on tooling efficiency or engagement-log completeness.
• Investment to reach L4: ₹15 to 40 lakh/year (GRC platform; CLM; IR platform; regulatory-content feed; dedicated Compliance +1; BCM Lead full allocation).

Level 4, Quantitatively Managed

• Posture: GRC platform-hosted stakeholder register and obligations tracker; quantitative KPI tracking (clock adherence, SLA adherence, traceability completeness); quarterly horizon scan with structured regulatory-intelligence feed; bilateral engagement with top-10 stakeholders; annual climate-stakeholder review; integrated with ERM and board reporting.
• Artefacts: Above plus integrated GRC dashboard; quarterly engagement reports; KPI trend lines; bilateral stakeholder-commitment log.
• Audit finding (likely): Clean on 4.2; the conversation is about maturity advancement, not findings.
• Investment to reach L5: ₹25 to 60 lakh/year (continuous regulatory intelligence; dedicated BCM headcount beyond the BCM Lead; advanced tooling; bilateral engagement programme budget).

Level 5, Optimising

• Posture: Continuously-sensed stakeholder environment (regulatory feeds, customer-success health scores, supplier-risk intelligence, climate-scenario data); predictive obligations-tracker (new regimes anticipated before issuance); board-level dashboard with real-time KPIs; stakeholder-engagement programme with measured outcomes; cross-border regime management integrated with parent-group governance; annual climate-stakeholder scenario exercises.
• Artefacts: Above plus predictive analytics; stakeholder-satisfaction scores; cross-border governance map; integrated resilience dashboard.
• Audit finding (likely): Clean on 4.2; benchmark posture shared with peer organisations.

Maturity summary table

Emerging Trends

Several trends are reshaping what a mature 4.2 analysis looks like over the next two to three years.

• DPDP operationalisation. The DPDP Act 2023 is in force; the DPDP Rules 2025 were notified in November 2025; the Data Protection Board of India is being operationalised. Significant Data Fiduciaries face enhanced obligations (DPIA, periodic security audits, DPO). Every Indian organisation processing digital personal data has a new high-stakes interested party (the DPDP Board) and a new tight clock (72 hours). 4.2 maturity requires explicit DPDP rows in the obligations tracker.
• Climate-stakeholder expectations hardening (Amendment 1:2024). What was soft expectation is becoming hard requirement: SEBI BRSR (Business Responsibility and Sustainability Reporting) for listed entities; TCFD/ISSB-aligned disclosure norms; insurer and reinsurer climate-risk underwriting; NGT and MoEFCC enforcement. The 4.2 climate-stakeholder row is no longer a formality.
• Operational resilience overtaking BCP. The shift, most visible in HKMA OR-2, UK FCA/PRA/CB operational resilience policy, and APRA CPS 230, is from "do you have a plan?" to "can you maintain critical operations within tolerance through severe disruption?". 4.2 is where the tolerance dimension gets surfaced (whose tolerance? regulator, customer, market).
• DORA's third-party regime. DORA's ICT-third-party regime (Arts 28 to 30 + Arts 31 to 44 CTPP oversight) is creating a new class of stakeholder for Indian SaaS/IT-services firms serving EU financial-services customers: the EU competent authority, the Lead Overseer, and the customer's own DORA compliance function. The 4.2 cross-border regime tracking becomes non-optional.
• RBI's expanding expectations. The 7 November 2023 Master Direction IT Governance (effective 1 April 2024) materially expanded IT Service Continuity expectations; expect further updates as the Reserve Bank's supervisory practice evolves. Stay current via a regulatory-content feed.
• CERT-In enforcement maturing. The Directions are now in their fourth year; enforcement is shifting from "issuing the rule" to "follow-up on compliance". The 6-hour clock and the 180-day log retention are now routinely tested in RBI and SEBI inspections. 4.2 obligations tracker must have CERT-In traceable into 7.5 (documented information) and 8.4 (IR).
• Cross-border data localisation. RBI's data-localisation requirement for payment data; DPDP's cross-border transfer mechanism (to be operationalised by the Rules); MeitY's cloud-empanelment scheme. Each creates a new interested party (the regulator setting the rule) and a new obligation (the localisation requirement).
• Stakeholder activism. Investors (climate, governance), employees (workplace safety, EVP during climate events), customers (cyber transparency), communities (environmental justice) are increasingly activist. 4.2 must capture their expectations as material, not as background noise.
• AI-related stakeholder expectations. As AI/ML systems become part of critical operations, new stakeholders emerge: AI auditors, model-validation bodies, sectoral AI-regulators (where they are being set up), and customer AI-governance functions. The 4.2 analysis for AI-driven critical services must capture these additional parties.
• Board-level resilience dashboards. Boards are increasingly asking for resilience dashboards (not just compliance reports). The 4.2 stakeholder register and obligations tracker feed directly into such dashboards, with KPIs on regulator-clock adherence, customer-SLA adherence, and stakeholder-satisfaction scores.

References and Further Reading

The references below are Tier-1 sources (the issuing body itself) and standard editions cited in this guide. Where a source could not be independently verified, it is flagged.

Standards and companion guidance

• ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements (2nd edition), ISO/TC 292. International Organization for Standardization.
• ISO 22301:2019/Amd 1:2024, Climate action changes.
• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301.
• ISO 22300:2021, Security and resilience, Vocabulary (3rd edition; a 2025 edition is under development (ISO/DIS 22300, 4th ed.) and not yet published, verify current edition at iso.org).
• ISO/TS 22317:2021, Guidelines for business impact analysis (2nd edition; 2015 edition withdrawn).
• ISO/TS 22318:2021, Guidelines for supply chain continuity (2nd edition; 2015 edition withdrawn).
• ISO/TS 22331:2018, Guidelines for business continuity strategy.
• ISO 22316:2017, Organizational resilience, Principles and attributes.
• ISO 31000:2018, Risk management, Guidelines.
• ISO/IEC 27001:2022, Information security management systems, Requirements.

Indian regulatory instruments

• Reserve Bank of India, Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (RBI/DOR.STR.REC.43/04.10.001/2023-24), issued 7 November 2023, effective 1 April 2024. https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=12562
• Reserve Bank of India, Cyber Security Framework in Banks (DBS.CO/OC.No.114/33.01.001/2015-16), 2 June 2016. https://www.rbi.org.in/
• Reserve Bank of India, Master Directions on Outsourcing of Information Technology Services, 10 April 2023. https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=12376
• Reserve Bank of India, Complete Cyber Security Framework for Primary (Urban) Cooperative Banks, 31 December 2019.
• Securities and Exchange Board of India, Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113), 20 August 2024. https://www.sebi.gov.in/legal/circulars/aug-2024/cybersecurity-and-cyber-resilience-framework-cscrf-for-sebi-regulated-entities-res-_85964.html
• Securities and Exchange Board of India, Guidelines for Business Continuity Plan (BCP) and Disaster Recovery (DR) of Market Infrastructure Institutions (MIIs) (SEBI/HO/MRD1/DTCS/CIR/P/2021/33), 22 March 2021, modified 12 September 2024. https://www.sebi.gov.in/legal/circulars/mar-2021/guidelines-for-business-continuity-plan-bcp-and-disaster-recovery-dr-of-market-infrastructure-institutions-miis-_49601.html
• Insurance Regulatory and Development Authority of India, Information and Cyber Security Guidelines, 2023, 24 April 2023. https://irdai.gov.in/
• Indian Computer Emergency Response Team, Directions under Section 70B(6) of the IT Act, 2000 (No. 20(3)/2022-CERT-In), 28 April 2022. https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf
• Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023), enacted 11 August 2023. https://www.meity.gov.in/data-protection-framework
• Digital Personal Data Protection Rules, 2025, notified November 2025.
• Disaster Management Act, 2005 (Act No. 53 of 2005). https://ndma.gov.in/acts-rules
• National Disaster Management Guidelines, Chemical Disasters (Industrial), 2007. https://nidm.gov.in/pdf/guidelines/new/chemicaldisaster.pdf
• National Disaster Management Guidelines, Preparation of Disaster Management Plans, 2014.
• Companies Act, 2013 (Act No. 18 of 2013), Sections 134(3)(n), 177. https://www.mca.gov.in/
• SEBI LODR Regulations, 2015 (Regulation 21, Risk Management Committee).
• Information Technology Act, 2000 (Act No. 21 of 2000), as amended 2008; Sections 43, 65, 66, 70, 70A, 70B, 72, 84A. https://www.indiacode.nic.in/

Cross-border frameworks

• European Union, Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA), OJ L 333, 27.12.2022, p. 1; applies from 17 January 2025. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554
• Australian Prudential Regulation Authority, Prudential Standard CPS 230 Operational Risk Management, effective 1 July 2025 (paragraph 38 codifies the BIA triple; paras 47 to 60 cover service-provider arrangements). https://www.apra.gov.au/
• Monetary Authority of Singapore, Technology Risk Management Guidelines, 18 January 2021. https://www.mas.gov.sg/-/media/MAS/Regulations-and-Financial-Stability/Regulatory-and-Supervisory-Framework/Risk-Management/TRM-Guidelines-18-January-2021.pdf
• Hong Kong Monetary Authority, Supervisory Policy Manual TM-G-2 (Business Continuity Planning) and OR-2 (Operational Resilience), 31 May 2022. https://www.hkma.gov.hk/
• US Federal Financial Institutions Examination Council, IT Examination Handbook, Business Continuity Management Booklet, November 2019. https://ithandbook.ffiec.gov/it-booklets/business-continuity-management.aspx
• National Institute of Standards and Technology, Special Publication 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems, May 2010. https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
• National Institute of Standards and Technology, Cybersecurity Framework 2.0 (NIST.CSWP.29), 26 February 2024. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
• US Federal Emergency Management Agency, Federal Continuity Directives FCD-1 (17 January 2017) and FCD-2 (13 June 2017) under PPD-40. https://www.fema.gov/

Incident and case anchors

• Cognizant, Maze ransomware, 18 to 20 April 2020; SEC-filed 10-Q/10-K disclosed Q2 2020 impact of US$50 to 70 million. Source: CTS Holdings 10-K (ctsh-20201231), sec.gov.
• Air India / SITA, data breach disclosed May 2021, ~4.5 million Air India customers. Source: reuters.com.
• Wipro, phishing, reported April 2019. Source: krebsonsecurity.com.
• HDFC Bank, RBI action, 2 December 2020 (restriction lifted partially 17 August 2021 and fully March 2022). Source: finextra.com; livemint.com.
• AIIMS Delhi, ransomware, 23 November 2022 (peer-reviewed case in the International Journal of Information Management). Source: jim.imibh.edu.in; thehindu.com.
• LG Polymers, Visakhapatnam styrene gas leak, 7 May 2020; NGT interim penalty ₹50 crore (OA 73/2020). Source: greentribunal.gov.in.
• Maruti Suzuki Manesar, violence and fire, 18 July 2012. Source: thehindu.com.
• Go First, insolvency filed 2 May 2023; refund liability ₹597 crore (airline disclosure 31 July 2023). Source: NCLT proceedings; reuters.com.
• SpiceJet, DGCA enhanced surveillance; 50 per cent cap on Summer Schedule flights, 27 July 2022. Source: thehindu.com.
• Jio, DC fire, 17 September 2024; Cloudflare Radar measured AS55836 traffic down up to 53 per cent. Source: reuters.com; Cloudflare.
• UPI / NPCI, 12 April 2025 ~5-hour nationwide degradation. Source: timesofindia.indiatimes.com.
• Mumbai blackout, 12 October 2020; cyber attribution contested (Maharashtra State Cyber cell vs Union Power Ministry). Source: recordedfuture.com; thehindu.com.
• Chennai floods, December 2015; Cognizant disclosed 11 delivery/operations centres affected; reaffirmed FY2015 revenue guidance ≥US$12.41 billion. Source: news.cognizant.com; nidm.gov.in.

Practitioner bodies of knowledge

• Business Continuity Institute, BCI practitioner guidance (launched 31 October 2023).
• Disaster Recovery Institute International, DRI professional-practice framework (10 practices; living framework).

Notes on accuracy

• ISO 22300:2018 is withdrawn; the current edition is ISO 22300:2021 (a 2025 edition is under development (ISO/DIS 22300, 4th ed.) and not yet published, verify at iso.org/standard/77008.html).
• ISO/TS 22317:2015 and ISO/TS 22318:2015 are withdrawn; the current editions are the 2021 versions.
• DORA applies from 17 January 2025; there is no "June 2025 DORA date", the mid-2025 prudential date is APRA CPS 230 (1 July 2025).
• "BSI" is two organisations: the German BSI (bsi.bund.de, the federal cybersecurity authority) and BSI Group (the certification body). Do not conflate.
• Mumbai 12 October 2020 blackout cyber link is contested, present both positions (Maharashtra State Cyber cell vs Union Power Ministry); do not assert.
• Cognizant Maze impact (US$50 to 70M), LG Polymers NGT penalty (₹50 cr), Go First refund liability (₹597 cr), AIIMS ransomware reported figure (~₹200 cr, unconfirmed), Yes Bank moratorium (Yale JFC case), these are the strongest primary-sourced anchors; treat other figures as "reported" or "[UNVERIFIED]" unless traced to a primary disclosure.

This guide is published by Singahi (singahi.co.in) as practitioner-grade compliance content for growing companies in India. ISO 22301:2019's clause text is copyrighted and is not reproduced in this guide; the clause is paraphrased throughout, attributed as "ISO 22301 Clause 4.2 asks organizations to…". Sample "shall" language in policy and contract examples is Singahi's own drafting for your adaptation. Framework and regulation references are to public instruments named; verify current versions on the issuing body's official portal before relying on them. No reference book, book author, or competitor is named in this guide. Numbers, scoring anchors, and timelines in the illustrative scenarios are illustrative starting points, adapt them to your organisation's reality.