ISO 22301 Clause 4.1: Understanding the Organization and Its Context

Quick Reference (60 Seconds)

If you only read one thing: Clause 4.1 is the foundation of ISO 22301. Get this clause right and 4.2–4.4, 6.1, and the analytic spine of Clause 8 fall into place; get it wrong and your BIA will be mis-scoped, your risks mis-prioritised, your strategy mis-aligned, and your BCMS certificate will rest on a faulty base. Indian regulators, RBI, SEBI, IRDAI, CERT-In, increasingly expect exactly the kind of evidence 4.1 produces, and Amendment 1:2024 (climate) makes the environmental and climatic dimensions non-optional.

What the Standard Actually Requires

Figure · Process

What Clause 4.1 asks you to do

The paraphrased requirement

ISO 22301 Clause 4.1 asks organizations to identify the internal and external issues that affect their ability to deliver products and services at the intended level and that shape the design of the Business Continuity Management System, 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 one of those issues, both as a source of disruption and as a driver of stakeholder expectations. The climate dimension is not a separate sub-clause; it is woven into the same "internal and external issues" analysis.

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

1. Coverage, Have we looked outward (regulation, market, technology, climate, geopolitics, suppliers, threat actors) and inward (governance, culture, competence, finance, prior incidents, dependency concentration)?
2. Materiality, Which of those issues actually affect our ability to deliver products and services at the intended level, or shape the BCMS we should build?
3. Time-horizon, Which issues are urgent (regulatory deadline this quarter), which are emerging (climate-driven supply relocation over five years), and which are slow-burn (skills shortage, demographic shift)?
4. Uncertainty, How confident are we about each issue's direction and magnitude? Where do we need scenarios rather than point forecasts?
5. Traceability, How does each material issue flow downstream: into 4.2 interested parties, 4.3 scope, 6.1 risks and opportunities, 6.2 objectives, and 8.3 strategy?
6. Living process, When and how will we re-do this? Annually; on event trigger (major change, M&A, new product, post-incident, new regulation, new climate scenario); after every Clause 9.3 management review and every Clause 8.5 exercise that surfaces drift.

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

Clause 4.1 is often treated as a box-ticking "context statement" and dispatched in a single paragraph. That is a misreading. It is helpful to be explicit about what is out of scope for 4.1, because auditors test the boundary:

• It does not require identifying interested parties and their requirements. That is Clause 4.2. 4.1 names the issues; 4.2 names the people and organisations those issues flow through.
• It does not require defining the BCMS scope. That is Clause 4.3. 4.1 feeds scope decisions; it is not the scope statement.
• It does not require risk treatment. That is Clause 6.1. 4.1 frames risks and opportunities; it does not rate or treat them.
• It does not require quantifying impact over time. That is Clause 8.2 (BIA). 4.1 is the qualitative "what world are we operating in?" upstream of the BIA's quantitative "what happens if X stops?".
• It does not require a particular tool or framework. PESTLE, STEEPLED, SWOT, ISO 31000's "establishing the context" step, the COSO ERM "external/internal environment" lens, any defensible structured method is acceptable. PESTLE is the most common in BCM practice because it surfaces the climate and regulatory dimensions naturally.
• It does not require climate scenario modelling to TCFD/NGFS specifications. Amendment 1:2024 requires that climate be considered as an issue; the depth of climate analysis scales with the organisation's exposure.

The companion guidance (ISO 22313:2020)

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

• 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.1 it explains that "issues" should include relevant legal, regulatory and other requirements; the organisation's capabilities and culture; its products, services and activities; and the broader external environment (technological, economic, political, environmental, climatic, demographic). It encourages the organisation to use any well-known context-analysis technique and to keep the output current.
• ISO 31000:2018, Risk management, Guidelines, with its "establishing the context" step. ISO 31000's framework is the most widely-used reference for what a context analysis looks like; ISO 22301's Clause 4.1 is essentially the BCMS-specific application of that step.
• ISO 22316:2017, Organizational resilience, Principles and attributes. Useful for the internal-issues half of Clause 4.1, because it lists the attributes (leadership, culture, adaptive capacity, networks and relationships, awareness, etc.) that determine whether an organisation can absorb disruption.
• ISO 22300:2021, Vocabulary. The normative source of terms like "disruption", "business continuity", "prioritised activity" (used downstream but framed in 4.1).

What auditors actually check

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

• The context document itself, coverage of internal and external categories, evidence of a structured method (PESTLE or equivalent), each issue's source and time-horizon noted, top-management approval, version history, evidence of refresh.
• Traceability downstream, does Clause 4.2 (interested parties) name the stakeholders each issue touches? Does Clause 4.3 (scope) actually reflect the boundary the issues imply? Does Clause 6.1 (risks/opportunities) include risks that map to material issues? Does Clause 8.3 (strategy) reflect the threat/dependency/climate picture from 4.1?
• Traceability upstream, does the context analysis reflect what the board, the risk committee and senior management actually worry about? Are board-risk-committee minutes from the last 12 months reconcilable with the issues in the context document?

Common observations you should be ready for: (a) "your context document lists 12 issues but your Clause 6.1 risk register covers only 4 of them, explain the gap" (an L2 finding); (b) "your context analysis was done 24 months ago and has not been refreshed despite two new RBI circulars and the SEBI CSCRF" (an L1 non-conformity); (c) "you have not considered climate change as an issue despite Amendment 1:2024 being in force" (an Amendment-driven non-conformity, increasingly raised since late 2024).

Why This Control Matters

The business case

Most BCM programmes that fail under stress fail not because the plan was wrong but because the scope was wrong, the organisation analysed the wrong activities, mapped the wrong dependencies, exercised the wrong scenarios, and recovered the wrong systems first. Clause 4.1 is the clause that prevents that failure mode. It is the framing clause: it forces the organisation to deliberately decide what world it is operating in before it builds a system to survive disruption in that world.

Done well, Clause 4.1 produces three things of immediate business value:

1. A shared, written picture of the operating environment, so the CFO, the CIO, the COO, the CISO and the Head of Operations are looking at the same reality when they argue about budget and priorities.
2. A materiality filter, so the finite BCM budget goes to the issues that actually affect product/service delivery, not to whatever the last incident made salient.
3. A defensible trace, so when a regulator (RBI, SEBI, IRDAI, CERT-In) or a board risk committee asks "why is your BIA scoped the way it is?" the answer does not start with "I think…".

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

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

• Regulatory density and pace. RBI's Master Direction on IT Governance, Risk, Controls and Assurance Practices (issued 7 November 2023, effective 1 April 2024) consolidated and materially expanded continuity expectations for banks, NBFCs (asset base ≥ ₹500 cr), All-India Financial Institutions and Credit Information Companies. SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF, circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, dated 20 August 2024) replaced the 2015 MII framework and extended graded continuity obligations across brokers, AMCs, AIFs, RTAs, KYC RAs and portfolio managers. IRDAI's Information and Cyber Security Guidelines 2023 (24 April 2023) rewrote insurer expectations. CERT-In Directions (No. 20(3)/2022-CERT-In, 28 April 2022) impose a 6-hour incident-reporting clock across the entire economy. DPDP Act 2023 (Act 22 of 2023) creates a statutory availability duty (Section 8(5)) and breach-notification duty (Section 8(6)). No organisation with an Indian footprint is short of regulatory issues to identify in its 4.1 analysis, but most do not enumerate them systematically.
• Climate exposure. India is among the most-exposed major economies to climate-related disruption: monsoonal flooding (Chennai 2015, Kerala 2018, urban flooding in Mumbai, Bengaluru, Hyderabad, Delhi-Gurugram), cyclones (east and west coasts), heatwaves (the 2024–2025 cycle saw extended red-alert heat across north and central India), air-quality events (Delhi NCR every winter), and drought-driven agricultural stress that hits rural-facing BFSI and FMCG. Amendment 1:2024 makes climate a required consideration; for Indian firms, ignoring it now produces a non-conformity and a real operational gap.
• Concentration of critical technology on a small set of suppliers. Indian banks, NBFCs, insurers, brokers, hospitals, SaaS firms and government bodies run their core on a small number of core-banking, core-insurance, exchange-trading, hospital-information and cloud stacks. Many are single-vendor. The Wipro phishing incident (2019, reported) and the Air India/SITA breach (2021, ~4.5 million customers) are reminders that a single upstream supplier can become your continuity event. Clause 4.1 is where that concentration is supposed to be flagged.
• Critical-infrastructure dependency. The Mumbai blackout of 12 October 2020, officially attributed by the Union Power Ministry to human error and load issues, with a parallel attribution by Maharashtra's state cyber cell and the Recorded Future report (Feb–Mar 2021) to suspected RedEcho/ShadowPad grid intrusion, illustrates that grid power (and its possible cyber compromise) is upstream of every other BC plan. The attribution remains contested; the operational lesson does not. Power, telecom (the Jio 17 September 2024 DC fire, Reuters; Cloudflare Radar measured AS55836 traffic down up to 53%), payments rail (UPI's 12 April 2025 ~5-hour nationwide degradation), and cloud ( CrowdStrike 19 July 2024 global outage) are all context issues for an Indian BCM programme.
• People and skills concentration. The Akasa Air pilot exodus of 2023 (43 pilots resigning in a single month, ~600–800+ flights cancelled, losses reported at ~₹3 cr/day at peak) shows that people continuity, key-person risk, cross-training, enforceable notice, geographic concentration of talent, is a first-class 4.1 issue in India's tight skilled-labour market.
• Board-level accountability. Companies Act 2013 Section 134(3)(n) requires the Board's Report to include a statement on the development and implementation of a risk management policy, including 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. BCM-grade risks fall squarely in this scope. A clean Clause 4.1 analysis is the artefact that satisfies board-risk-oversight duties.

The cost of getting it wrong

The cheapest way to learn what a 4.1 failure costs is to look at incidents where the root cause was, at heart, failure to identify the operating context:

• LG Polymers, Visakhapatnam, 7 May 2020, runaway polymerisation in the M6 styrene tank during the COVID-19 lockdown; 12–13 fatalities; hundreds to thousands exposed; ~2,500–3,000 evacuated from a 3 km radius; NGT interim penalty ₹50 cr (OA 73/2020, deposited); LG Chem announced a ₹730 cr relief package; the plant was permanently closed. The NGT Joint Monitoring Committee report flagged that the unit had operated for years without a proper environmental clearance. In ISO 22301 terms this is a Clause 4.1 failure: the organisation did not properly identify its regulatory and environmental context, and therefore did not scope or design its continuity arrangements to match.
• Go First, filed insolvency 2 May 2023, the Wadia-group airline blamed Pratt & Whitney PW1100G engine failures (contaminated powdered metal, A320neo fleet) for grounding ~half its fleet; flights cancelled from 3 May 2023, never resumed; the lessor-driven CoC moved toward liquidation; refund liability ₹597 cr owed to ~15.5 lakh (1.55 million) passengers per the airline's own 31 July 2023 disclosure. In ISO 22301 terms this is a Clause 4.1 failure on the supplier-concentration axis: a single engine OEM was the continuity dependency for the entire business, and no alternative was modelled or pre-positioned.
• AIIMS Delhi ransomware, 23 November 2022, suspected LockBit (Chinese-origin actors also suspected); five physical servers hosting the NIC-built e-Hospital application encrypted, including primary and backup servers; OPD, admissions, billing and labs reverted to paper for ~6–15 days; ~50 servers compromised; media-reported ransom ~₹200 cr (~US$25 m), not confirmed by AIIMS or Delhi Police; NIA opened a cyberterrorism probe. In ISO 22301 terms this is partly a Clause 4.1 failure: the threat landscape (ransomware actors targeting Indian healthcare) and the dependency on a single application with untested, online-only backups were not properly identified as issues that should shape the BCMS.

These are extreme cases. The everyday version of the same failure looks like this: a mid-market (250–2,000 staff) NBFC builds its BCM around the assumption that "our main risk is the core banking system going down", because that was the last incident. The actual context, concentration on one DC, one core-banking vendor, dependence on a small UPI TPAP, an outsourced SOC with a 24-hour SLA, an ageing HQ building in a flood-prone zone, and a regulatory environment that just changed three times in 18 months, never gets written down. The BIA is scoped wrong. The exercises drill the wrong scenarios. The first real disruption finds the gaps.

Scope and Applicability

Who 4.1 applies to

Clause 4.1 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.1 scales in depth but applies uniformly. A 40-person SaaS start-up and a 40,000-person bank both have to identify their internal and external issues; what differs is the depth, cadence and tooling.

What "the organization" means for 4.1

"Organization" in Clause 4.1 means the entity to which the BCMS applies, defined later 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 most common scoping decisions are:

• Whole-entity scope, the BCMS covers the entire company. Most growing companies pick this because it matches their regulatory perimeter.
• Subsidiary or business-unit scope, common when one subsidiary is regulated (e.g., a bank subsidiary within a fintech group) and the others are not.
• Geographic scope, common for Indian IT/ITeS firms certifying per delivery centre or per client-engagement.
• Service-line scope, common for SaaS firms certifying per product line, or for payment system operators certifying per payment rail.

Clause 4.1's analysis must cover the issues affecting the in-scope organisation, but it must also flag issues originating outside the scope that affect the in-scope entity (parent-company decisions, group-shared services, upstream suppliers). That cross-boundary visibility is what auditors look for.

What 4.1 does NOT scope

Clause 4.1 does not decide what's in the BCMS, Clause 4.3 does. But 4.1 informs 4.3 by surfacing the issues that make one scoping choice better than another. A common error is to scope 4.1 down to match an already-decided 4.3 outcome ("we only certify the data centre, so we'll only analyse data-centre issues"), auditors notice and treat it as a finding.

By organisation size

Key Definitions and Terminology

Clause 4.1 uses the ISO management-system vocabulary more than BCM-specific terms; the following definitions are load-bearing for this clause:

• Context (of the organization), the combination of internal and external issues that can affect the organisation's purpose, the achievement of its objectives and its ability to deliver products and services at the intended level. Source: ISO management-system vocabulary; ISO 22313:2020 §4.1.
• Issue, a point of matter, a topic for consideration, or a changing circumstance that can affect the organisation. "Issue" is deliberately broad: it covers risks, opportunities, constraints, dependencies, obligations and trends. ISO does not require issues to be "negative"; climate change, for example, is an issue that includes both disruption risk and adaptation opportunity.
• Internal issue, an issue arising from within the organisation: governance, structure, culture, competence, financial resilience, prior incidents, strategy, dependencies on single people or vendors, technology posture, geographic concentration of assets or people.
• External issue, an issue arising from outside the organisation: regulation, market structure, technological change, climate and environment, geopolitics, supplier ecosystem, threat actors, demographic trends, social licence, infrastructure (power, telecom, payments, transport).
• Materiality (in the 4.1 sense), the organisation's judgement about which issues are significant enough to influence the BCMS. Materiality is not a numerical score; it is a documented rationale.
• Time-horizon, the period over which an issue is expected to manifest: immediate (this quarter), near-term (12 months), medium-term (1–3 years), long-term (3–10 years). Climate issues typically span all four; regulatory issues are usually immediate; demographic issues are long-term.
• Uncertainty, the degree to which an issue's direction or magnitude is unknown. High-uncertainty issues call for scenario analysis rather than point estimates.
• Climate-change adaptation (per Amendment 1:2024), the consideration of climate change as both a source of disruption (acute: cyclones, floods, heatwaves; chronic: sea-level rise, water stress, agricultural shift) and a driver of stakeholder expectations (regulators, investors, customers, employees).
• PESTLE, a context-analysis taxonomy covering Political, Economic, Social, Technological, Legal and Environmental dimensions. Common in BCM practice; not mandated by ISO.
• STEEPLED, PESTLE extended with Demographic and Ethics dimensions. Useful for large enterprises; over-engineered for most growing companies.
• Scenario analysis, a structured method for exploring how issues might evolve and interact under different plausible futures. Required for high-uncertainty issues (climate, geopolitics, technology regulation).
• Traceability (4.1 → 4.2/4.3/6.1/6.2/8.3), the documented link from each material issue to the downstream BCMS elements it shaped. The absence of traceability is the single most common 4.1 finding.

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

Relationship to Other Clauses and Frameworks

Inside ISO 22301:2019

Cross-framework anchors (the non-ISO regimes 4.1 connects to)

A growing company holding ISO 22301 will inevitably face questions from other regimes that map to Clause 4.1. The mapping is detailed in Section 16, but in summary:

• ISO 27001:2022 Clause 4 ("Context of the organization") is near-identical in structure to ISO 22301 Clause 4, a single context-analysis artefact usually satisfies both standards.
• ISO 27001:2022 Clause 5.9 (inventories of information and other associated assets) and Clause 8.26 (application security requirements) flow from a context-driven view of what assets matter.
• NIST Cybersecurity Framework 2.0 (released 26 February 2024) introduced a sixth function, Govern (GV), whose GV.OC (Organizational Context) category explicitly asks the organisation to understand its mission, stakeholders, and dependencies. GV.OC is essentially the US government's restatement of ISO 22301 Clause 4.1.
• NIST SP 800-34 Rev 1 (May 2010), the seven-step contingency-planning process begins with "develop contingency planning policy statement" and Step 2 "conduct Business Impact Analysis", both of which presuppose an understanding of organisational context.
• FFIEC BCM Booklet (November 2019, OCC 2019-57 / FRB SR 19-13 / FDIC FIL-19071), its "governance" and "business impact analysis" chapters explicitly require a board-level understanding of the operating environment, which is the US banking supervisor's Clause 4.1 equivalent.
• DORA (Regulation (EU) 2022/2554, applies 17 January 2025), Article 8 ("Identification") requires financial entities to identify, document and classify ICT-supported business functions, information assets and ICT dependencies. Article 11(5) requires a BIA. Article 6(8) requires a digital operational resilience strategy including impact tolerance for ICT disruptions. Together, these are DORA's analogue of Clause 4.1's identification of internal and external issues.
• APRA CPS 230 (effective 1 July 2025), paragraphs 7–11 require an organisation to identify "material risks" arising from internal and external sources; paragraph 38 codifies the BIA triple (maximum disruption period, maximum data loss, minimum service levels). Sections 7–11 are the Australian prudential regulator's Clause 4.1 equivalent.
• RBI Master Direction IT Governance (7 Nov 2023, eff. 1 Apr 2024), the Governance chapter requires board and senior-management understanding of the IT environment, including dependencies on outsourced IT, critical third parties and critical infrastructure.
• SEBI CSCRF (20 Aug 2024), the Identify function requires REs to identify assets, dependencies, business processes and risks. CSCRF's Identify is the SEBI Clause 4.1 equivalent.
• IRDAI Information & Cyber Security Guidelines 2023 (24 Apr 2023), requires board-approved policies grounded in a documented understanding of the insurer's risk environment.
• CERT-In Directions (28 Apr 2022), impose the 6-hour reporting clock, 180-day log retention, NTP sync and KYC obligations across the Indian economy; identifying these as a 4.1 issue is foundational.
• DPDP Act 2023, Section 8(5) availability duty and Section 8(6) breach-notification duty apply to every "Data Fiduciary"; for organisations handling significant volumes of personal data, DPDP is a first-order 4.1 issue.
• Companies Act 2013 §134(3)(n) and §177; SEBI LODR Regulation 21, board-level risk-oversight duties, satisfied in part by a strong 4.1 analysis.

Detailed Implementation Guidance, The Worked Context Analysis

This section walks through a complete Clause 4.1 cycle using a PESTLE + internal-capability method. It is the method Singahi uses with clients; it is also the structure of Toolkit Document 02. The numbers, examples and scenarios are illustrative.

The five-phase method

Total: 9–17 weeks for a first cycle (growing companies), 3–6 months for a mid-market (250–2,000 staff) firm building the discipline from scratch.

Phase A, Framing

The frame is the most-skipped and most-valuable phase. Decisions taken here determine whether the rest of the analysis is credible.

Decide what "the organization" is. If the BCMS scope is the whole legal entity, this is straightforward. If the scope is a subsidiary, a BU or a service line, define it explicitly and note that issues from the parent or sister entities can flow into the in-scope entity.

Appoint a context-analysis lead. Usually the BCM Manager; in a small firm, the COO or an external advisor. The lead is responsible (R); the executive sponsor is accountable (A); cross-functional heads are consulted (C); the wider org is informed (I).

Agree the method. PESTLE is the recommended default. STEEPLED adds demographics and ethics (useful for consumer-facing or ESG-heavy organisations). SWOT can be added later as a synthesis view but should not replace PESTLE because SWOT collapses external issues into "Opportunities/Threats" and loses the time-horizon dimension.

Agree the time-horizons. Four are typical:

• Immediate, this quarter (current regulation, current incident).
• Near-term, 12 months (regulation in draft, evolving threat).
• Medium-term, 1–3 years (climate adaptation, supplier consolidation, new tech adoption).
• Long-term, 3–10 years (climate scenarios, demographic shift, energy transition).

Gather prior analyses. ERM risk register; ESG/Sustainability report; TCFD/NGFS disclosures (if any); last BIA; last ISO 27001 Statement of Applicability; SOC 2 Type 2 report; recent board-risk-committee minutes; recent regulatory inspection reports (RBI / SEBI / IRDAI); recent audit reports; recent incident postmortems. These are inputs, you are not redoing them, you are aggregating them.

Phase B, Gathering issues

Three workshops, conducted in this order, capture most of the issues:

Workshop 1, CXO / Board (90 minutes). Ask: What keeps you awake at night about the organisation's ability to keep delivering? What's changed in the last 12 months? What do you expect to change in the next 36 months? Capture verbatim. Map each statement to a PESTLE category after the workshop.

Workshop 2, Cross-functional operations (3 hours). Attendees: COOs of each business unit; IT, Information Security, HR, Procurement, Legal, Compliance, Finance, Facilities, Sales/Revenue, Customer Support, R&D/Product. Ask each function head to list, for their function: What are the issues, internal and external, that could affect our ability to deliver? What dependencies are we most exposed to? What regulation are we watching?

Workshop 3, Site / BU / Geography leads (60 minutes each, may run in parallel). Required where the organisation has multiple sites, BUs or geographies in scope. Site-specific context (flood exposure, single-DC risk, vendor-staff concentration, regulatory variation) surfaces here.

Desk research in parallel:

• Regulatory horizon scan. Pull the last 12 months of relevant RBI, SEBI, IRDAI, CERT-In, MeitY, NDMA, TRAI circulars (and cross-border: EU DORA RTS/ITS, US SEC cyber, UK FCA/PRA operational-resilience, MAS, HKMA). Tag each one as in force, in draft, consultation.
• Climate and environmental. Reference the Ministry of Earth Sciences' "Assessment of Climate Change over the Indian Region" (2020) for monsoon, heat, sea-level projections; NDMA guidelines for cyclone, flood, heatwave, chemical-disaster, industrial-disaster; the NGFS climate scenarios for financial-sector implications; TCFD/ISSB framework for disclosure expectations.
• Threat landscape. CERT-In's annual report; the BCI Horizon Scan 2025 (cyber ranked the #1 organisational risk for 2026; safety incidents ranked 14.64 on the risk index; around half of respondents reported they had thwarted a cyber-attack in the prior year); the Indian Computer Emergency Response Team advisories; sector ISAC feeds (FS-ISAC, H-ISac).
• Supplier ecosystem. Concentration analysis: how many critical activities depend on one OEM, one cloud, one TPA, one MSP, one captive. Lock-in indicators (data gravity, proprietary formats, switching cost). Single points of failure.

Phase C, Synthesis: the PESTLE + Internal matrix

Cluster the raw issues into the following structure (this is the format used in Toolkit Document 02):

For each cluster, write a one-paragraph narrative summary. Do not just leave a list of bullets, auditors look for the analysis, not the inventory.

Phase D, The traceability matrix

The traceability matrix is the artefact that turns a PESTLE list into a Clause 4.1 deliverable. For each material issue, document:

A worked example (illustrative; for a Bengaluru-based SaaS firm serving EU customers):

A mid-market (250–2,000 staff) organisation typically has 20–40 material issues in its traceability matrix; a growing company usually 8–15; an enterprise may have 100+ aggregated to a 25-issue board summary.

Phase E, Approval and operationalisation

Top-management review. Present the analysis to the executive sponsor, the Risk Committee and (where one exists) the Board Risk Management Committee. The discussion should focus on materiality, time-horizon and the traceability implications, not on the full PESTLE.

Approval. Capture approval in committee minutes; sign and date the context analysis document; record the version.

Communication. Communicate a summary to the wider organisation: "Here is what we think our operating environment looks like; here are the material issues; here is what they mean for how we build our BCMS." This is also a Clause 7.3 (awareness) input.

Integration. Wire the analysis into:

• Clause 4.2, refresh the interested-parties register.
• Clause 4.3, review scope; document any scope changes.
• Clause 6.1, refresh the risk register; remove risks no longer material; add newly-material ones.
• Clause 6.2, refresh the continuity objectives.
• Clause 8.1 / 8.2 / 8.3, re-scope operational plans, BIA priorities and strategy selection.
• Clause 8.5, update the exercise programme to drill the new material scenarios.
• Clause 9.3, feed the next management review with the refreshed context.

Refresh calendar. Schedule:

• Annual full refresh.
• Quarterly regulatory + climate horizon scan.
• Event-triggered refresh: major change (M&A, new product, new geography, new core system, new outsourcing); post-incident (Clause 8.6 / 10.1); post-exercise drift (Clause 8.5); new material regulation; new climate scenario.

The climate-change dimension (Amendment 1:2024)

Amendment 1:2024 (Climate action changes), published February 2024 and taken over as EN ISO 22301:2019/A1:2024 in September 2024, modifies Clauses 4.1 and 4.2. For Clause 4.1 it adds an explicit expectation that the organisation consider climate change among its issues. Operationally, this means three things in the Indian context:

1. Acute physical climate risk must appear in the environmental category. Cyclones (east coast: Tamil Nadu, Andhra, Odisha, West Bengal; west coast: Gujarat, Maharashtra, Goa, Karnataka), monsoon flooding (urban and riverine, Chennai 2015, Kerala 2018, Mumbai recurrent, Bengaluru 2022, Hyderabad 2020), heatwaves (the 2024–2025 red-alert cycle was exceptional in duration and severity), thunderstorms and lightning (the single most lethal meteorological hazard in India by fatalities), and industrial-chemical incidents amplified by heat (LG Polymers 2020 is the canonical example).
2. Chronic physical climate risk must appear. Sea-level rise (coastal data centres in Mumbai, Chennai, Visakhapatnam); water stress (Bengaluru, Chennai); air-quality events (Delhi NCR every winter); vector-borne disease range shifts; agricultural-cycle disruption (relevant for agri-tech, rural BFSI, FMCG sourcing).
3. Transition risk + stakeholder expectations must appear. Regulators (RBI's Discussion Paper on Climate Risk and Sustainable Finance, 2024; SEBI's Business Responsibility and Sustainability Report, mandated for top-1000 listed entities) are elevating climate as a supervisory topic. Investors (PE/VC due diligence increasingly includes climate), customers (EU customers importing CBAM, CSRD), and employees (younger workforce expects climate-engaged employers) all read your climate posture. BCM programmes that ignore this fail the spirit of Amendment 1:2024 even where they barely pass the letter.

A defensible climate-issues section for an Indian firm typically runs to 1–2 pages, references the Ministry of Earth Sciences' climate assessment, names the firm's physical exposure (sites, suppliers, customer geographies), and identifies the scenarios used for stress-testing (typically NGFS Net Zero 2050, Delayed Transition, Current Policies, and a hot-house world).

Tools, Technologies, and Solutions

Clause 4.1 is mostly a thinking clause, not a tooling clause, but at higher maturity, tooling helps. Three categories are worth knowing.

Context-analysis and ERM platforms

The integrated risk-management platforms, spanning enterprise IRM suites, growing GRC SaaS, BCM-specialist platforms, and third-party-risk-management platforms, include context/risk modules that can host a 4.1 register and link it to the BIA, risk register and exercise programme. Indicative India pricing (verify on vendor's official domain; tiers vary widely): a SaaS IRM subscription for a mid-market (250–2,000 staff) firm usually starts around ₹18–40 lakh per year and scales with user count and modules.

Regulatory and horizon-scanning feeds

For the regulatory-monitoring dimension of 4.1, three Indian sources are essential:

• RBI, SEBI, IRDAI, CERT-In, MeitY, NDMA, TRAI official portals, free; authoritative; check weekly.
• PrimeInfoBase, Taxscan, INDIA Briefing, PSA半月刊-style compliance digests, paid; useful aggregation.
• The Big Four / law-firm regulatory alerts (KPMG, EY, Deloitte, PwC, Khaitan, Cyril Amarchand, AZB, Trilegal, Nishith Desai), free; high quality; read with their bias in mind.

For cross-border regulatory monitoring: DORA RTS/ITS finalisation tracker (EBA, ESMA, EIOPA), US SEC cyber disclosure (Item 1.05 of Form 8-K), UK FCA/PRA operational resilience policy papers, MAS/HKMA circulars, APRA CPS 230 guidance materials (effective 1 July 2025).

Climate and threat-intelligence feeds

• Climate: Ministry of Earth Sciences' "Assessment of Climate Change over the Indian Region" (2020); NDMA guidelines (cyclone, flood, heatwave, chemical, industrial, hospital safety); India Meteorological Department alerts; NGFS climate scenarios (for financial-sector implications); TCFD/ISSB IFRS S2 disclosure framework.
• Threat intel: CERT-In's annual report and weekly advisories; sector ISACs (FS-ISAC for BFSI; H-ISac for healthcare); commercial feeds (recorded future, mandiant, crowdstrike), usually overkill for growing companies; vendor threat-intel included with SOC/SIEM subscriptions.

What growing companies should actually buy

For most growing companies in India (50–2,000 staff), the right answer is not to buy a dedicated 4.1 tool. Use:

• A spreadsheet for the PESTLE + traceability matrix (Toolkit Document 02 has a ready template).
• The ERM or GRC tool you already own (most growing companies in the 250–2,000 band have something for ISO 27001 or SOC 2, reuse it).
• A compliance calendar tool (or even shared calendars) for refresh scheduling.
• Free regulatory portals and email alerts; pay for one aggregator only if the regulatory surface is wide.

Reserve dedicated tooling spend for L3+ maturity where the volume of issues, the cadence of refresh, and the integration with ERM/BIA justify the ₹18–40 lakh/year starting ticket.

Policy and Procedure Templates

The toolkit accompanying this guide (see Section 19) contains 17 ready-to-customise documents. The two most important for Clause 4.1 are:

Context Analysis Policy (Toolkit 01), sample statements

These are Singahi's own drafting for you to adapt. The standard's own clause text is copyrighted and is not reproduced here.

• The Organisation shall identify and document the internal and external issues that can affect its ability to deliver products and services at the intended level and that shape the design of the BCMS, in alignment with ISO 22301:2019 Clause 4.1 (as modified by Amendment 1:2024).
• The context analysis shall explicitly consider climate change, both as a source of disruption and as a driver of stakeholder expectations, and shall reference the climate scenarios used for stress-testing.
• The context analysis shall use a recognised structured method (PESTLE or equivalent) and shall cover the dimensions of political, economic, social, technological, legal, environmental and internal capability.
• Each material issue shall be linked to one or more interested parties (Clause 4.2), scope decisions (Clause 4.3), risks and opportunities (Clause 6.1), objectives (Clause 6.2) and strategy selections (Clause 8.3) via a documented traceability matrix.
• The context analysis shall be reviewed at least annually and refreshed on event trigger, including material change, post-incident, post-exercise, new regulation, and new climate scenario.
• Top management (or its Risk Committee) shall approve the context analysis and any material updates.

Context Analysis Procedure (Toolkit 02), outline

1. Frame the in-scope organisation; appoint the lead; agree method and time-horizons; gather prior analyses.
2. Run CXO workshop; capture verbatim.
3. Run cross-functional operations workshop; capture by function.
4. Run site/BU/geography workshops in parallel; capture by site.
5. Run desk research: regulatory horizon scan; climate scan; threat landscape; supplier ecosystem.
6. Cluster issues into PESTLE + Internal; assign time-horizon, uncertainty, BCMS-impact; flag materiality.
7. Build the traceability matrix.
8. Top-management review and approval.
9. Integrate outputs into Clauses 4.2, 4.3, 6.1, 6.2, 8.3.
10. Communicate summary to the organisation (Clause 7.3 input).
11. Schedule refresh calendar (annual + quarterly + event-triggered).
12. Capture lessons learned in the next management review (Clause 9.3).

Risk Assessment and Treatment

Clause 4.1 frames risk; Clause 6.1 treats it. But a defensible 4.1 cycle produces a first-pass view of risk that the Clause 6.1 cycle then refines. The risk-management concepts are anchored in ISO 31000:2018.

Risk sources surfaced by 4.1

Treatment paths

For each material risk flowing out of 4.1, treatment falls into one of four paths (ISO 31000 / Clause 6.1 language):

• Mitigate, reduce likelihood or impact via controls (e.g., multi-region deployment to mitigate single-region outage).
• Transfer, shift the financial impact (insurance) or the operational impact (outsourced DR).
• Avoid, exit the activity or geography (e.g., wind down a high-risk product line).
• Accept, consciously retain the risk, with documented rationale and top-management sign-off.

The 4.1 analysis does not pick the treatment; it surfaces the risk so that 6.1 can pick it.

Audit and Compliance Checklist

The following 25 questions are the ones an external certification auditor (Stage 1 or Stage 2) or an internal auditor is most likely to ask about Clause 4.1. For each, the expected evidence is noted.

Sector-specific audit emphases

Metrics and KPIs

Clause 4.1 is not naturally a metrics-heavy clause, but a small set of well-chosen KPIs keeps the discipline alive. The following 12 are the ones Singahi recommends to clients; track them quarterly and report to the Risk Committee.

Two outcome-oriented KPIs worth tracking as the programme matures:

Common Pitfalls and Audit Failures

Across dozens of ISO 22301 engagements, the following 4.1 anti-patterns recur. Each is named, the failure mode explained, and the fix given.

"The boiler-plate context statement"

Symptom: A 4.1 document that reads "The Organization operates in the Indian financial-services sector and is subject to applicable laws and regulations. The Organization's main risks are cyber, operational, and regulatory." Failure mode: No PESTLE; no time-horizons; no traceability; no top-management engagement. Fix: Run the full Phase A–E method; produce a 4–10-page analysis; force a trace to each downstream clause.

"The meeting-room list"

Symptom: The 4.1 list was generated in one CXO meeting; nobody below CXO was asked. Failure mode: Missing operational realities (e.g., the fact that 70% of staff can't reach the office in a flood); missing supplier/sub-tier dependencies. Fix: Always run a cross-functional workshop; never rely on CXO-only input.

"The forgotten refresh"

Symptom: 4.1 was done in certification year and never touched again. Failure mode: Material new regulations (RBI MD, SEBI CSCRF, IRDAI 2023, CERT-In Directions, DPDP) are absent; auditor raises an immediate non-conformity. Fix: Build a refresh calendar with quarterly scans and event triggers; assign a named owner.

"Climate-blind"

Symptom: The environmental section says "We monitor weather and have an emergency contact." Failure mode: Non-conformity under Amendment 1:2024. Fix: Run a real climate-issues assessment referencing Ministry of Earth Sciences data, NDMA guidelines and NGFS scenarios.

"No traceability"

Symptom: 4.1 is a 6-page document; the Clause 6.1 risk register is a different 8-page document; nobody has cross-referenced them. Failure mode: Auditor asks "show me how this risk came from this issue", answer: silence. Fix: Build the traceability matrix (Toolkit Doc 02); audit it annually.

"Scope-narrowing"

Symptom: "We only certify the data centre, so we only analyse data-centre issues." Failure mode: Cross-boundary dependencies (group HR, shared finance, upstream cloud, regulator) invisible. Fix: Always analyse issues affecting the in-scope entity including those originating outside it.

"Regulatory rote"

Symptom: A long list of every regulation ever enacted, with no materiality filter. Failure mode: Auditor cannot tell what actually matters; analysis is decorative. Fix: Apply a materiality filter; document the rationale.

"Vendor-as-black-box"

Symptom: Critical SaaS vendor named once as "we use [vendor]"; no concentration analysis, no exit assessment, no sub-tier visibility. Failure mode: Supplier dependencies invisible (cf. Go First P&W; SITA/Air India; Wipro phishing pivot). Fix: Run a supplier-concentration analysis; flag single-vendor critical paths; require BCP/BC evidence from critical suppliers (RBI MD Outsourcing of IT Services, 10 Apr 2023).

"Both-positions failure"

Symptom: Single-source assertion on a contested attribution (e.g., "Mumbai 2020 blackout was a cyberattack" or "Mumbai 2020 blackout was human error"). Failure mode: Credibility loss; auditor trained on the contested case will catch it. Fix: Present both positions (Maharashtra vs Union Power Ministry) and note the disagreement.

"Numbers without sources"

Symptom: "Cyber-attacks cost Indian firms ₹X cr on average." Failure mode: Source cannot be traced; number is contested; auditor asks for the citation. Fix: Cite primary sources (RBI orders, SEBI circulars, SEC filings, NGT, NCLT, DGCA, peer-reviewed studies); mark anything else as "[UNVERIFIED]" or "reported".

"Politics-free zone"

Symptom: The political section is empty because "politics doesn't affect us." Failure mode: Misses material issues, DPI dependence, state-vs-Centre regulatory divergence, election-cycle spending, geopolitical supply-chain risk. Fix: A 4.1 analysis that does not engage with the political environment of an Indian business is incomplete.

"The board-never-saw-it"

Symptom: 4.1 was approved by the BCM Lead alone; the Risk Committee has never discussed it. Failure mode: Companies Act §134(3)(n)/§177 exposure; auditor raises governance finding. Fix: Always take 4.1 to the Risk Committee; minuted approval; integrate with the enterprise risk register.

Illustrative Scenario 1: Failure, Taranga Finserve (Illustrative)

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

Disclaimer: This is an illustrative scenario. Taranga Finserve is a composite fictional entity; details are drawn from the publicly-documented patterns of Indian NBFC (250–2,000 staff) outages and RBI enforcement. Numbers are illustrative and do not represent any specific company.

The organisation

Taranga Finserve Pvt. Ltd. is a Pune-based Non-Banking Financial Company with ₹2,000 crore Assets Under Management, ~620 staff, focused on used-commercial-vehicle loans across Maharashtra, Gujarat, and Karnataka. The firm holds a single DC in Pune ( Hinjewadi), runs a single-vendor core lending platform (on-premises), uses one UPI TPAP for collections and disbursements, and has its back-office (HR, finance, payroll) on a single SaaS vendor. Taranga's BCM "programme" before 2024 was a 14-page BCP document authored by the IT Head in 2019, refreshed once by search-and-replace in 2022.

The 4.1 gap

Taranga's last context analysis was a single-page attachment to the 2019 BCP that read, in full: "Taranga operates in the Indian NBFC sector and is subject to RBI regulation. Taranga's main risks are system downtime, fire, and staff attrition." No PESTLE; no climate; no interested parties; no supplier-concentration analysis; no traceability. The board had never discussed it. The IT Head had been the de-facto owner since 2019; the COO had not seen the document in three years.

The actual context (which a proper 4.1 cycle would have surfaced):

• RBI Master Direction IT Governance (eff. 1 Apr 2024) applied to Taranga (asset base ≥ ₹500 cr), with detailed IT Service Continuity / BCM expectations.
• RBI Master Direction Outsourcing of IT Services (10 Apr 2023) required inherited continuity standards from the core-lending vendor and the SaaS back-office vendor.
• CERT-In Directions (28 Apr 2022) imposed the 6-hour reporting clock, 180-day log retention, NTP sync, Taranga's logging was 30-day, no NTP, no PoC.
• DPDP Act 2023 applied, borrower data, KYC data, geotagged collection data. Section 8(5) availability duty and Section 8(6) breach-notification duty bound Taranga as a Data Fiduciary.
• Single-DC, single-vendor concentration: The entire lending platform was in one Pune DC; the core-lending vendor had no contractual RTO/RPO; there was no DR site.
• Climate exposure: Pune's Hinjewadi area flooded in September 2019 and September 2022; the DC itself was on the ground floor of a building that had taken on water in 2022 (Taranga had sandbagged, not relocated).
• Workforce concentration: 78% of critical operations staff lived within 25 km of the Pune HQ; in a regional flood or unrest event, operations would halt.
• Cyber threat: NBFCs had been a documented ransomware target through 2022–2024; Taranga had no SOC, no MFA on the lending platform's admin console, no immutable backups.

The disruption

On a Friday morning in October 2024, a ransomware actor, initial access via a phishing email to a collections agent, lateral movement through the unsegmented lending-platform LAN, encrypted the lending platform and the back-office SaaS integration servers. The single DC's backups were online and reachable from the infected LAN segment; they were also encrypted. Taranga went dark: no loan disbursements, no collections, no customer service, no regulatory reporting.

The 4.1 consequence

The post-incident review (conducted under Clause 8.6 / 10.1 with the regulator's interest) traced the scale of the impact directly back to the 4.1 failure:

• Materiality miss: Taranga had never identified NBFC-sector ransomware as a material issue. The 2019 BCP's "system downtime" scenario assumed a 4-hour outage, not a 7–10-day encrypted-platform recovery.
• Climate miss: The flood exposure was known but not in the context analysis; flood-mitigation investment had been deferred.
• Regulatory miss: CERT-In's 6-hour clock was missed because no PoC was appointed and no IR plan existed; CERT-In was notified on Day 4 by a partner bank, not by Taranga. RBI was notified on Day 5. DPDP breach notification was filed on Day 9. Each was a separate regulatory exposure.
• Supplier-concentration miss: The core-lending vendor's T&Cs were revealed post-incident to disclaim continuity; the BCP's assumption that the vendor would recover "in a few hours" was unfounded.
• Board-oversight miss: The Risk Committee had not seen the 4.1 analysis; the Board's Report under Companies Act §134(3)(n) had been filed on a template.

The impact

• Operational: 9 days of platform outage; ~₹11 cr in lost disbursements and deferred collections.
• Regulatory: RBI inspection observation; prescribed remediation including a board-approved IT/BCP framework, external IT audit, and a 90-day DC-remediation plan; estimated ₹3 cr remediation cost.
• Customer: ~14% attrition of the borrower base over the following six months; estimated ₹9 cr in lifetime-value loss; two class-action complaints under DPDP.
• Reputational: Press coverage of the outage and the regulatory action.
• Insurance: Cyber-insurance recovery capped at ₹5 cr (sub-limited), against ~₹23 cr of total loss.
• Total impact: ~₹23 cr direct + ₹9 cr lifetime-value = ~₹32 cr.

The lessons (in 4.1 terms)

1. A 4.1 analysis that is a single page and has not been refreshed in five years is not a 4.1 analysis. It is a compliance artefact from a different decade of regulation.
2. Materiality is the whole job. A 4.1 analysis that names twenty issues but misses the three that actually drive continuity outcomes (NBFC ransomware, single-DC concentration, 6-hour clock) is worse than useless, it provides false assurance.
3. Supplier-concentration analysis is non-negotiable for a mid-market (250–2,000 staff) financial firm. The RBI Master Direction on Outsourcing of IT Services has been in force since April 2023.
4. The climate dimension is not optional. Amendment 1:2024 is in force; the Pune flood exposure was a known issue ignored.
5. Board engagement is the audit trail. Companies Act §134(3)(n) requires the Board to have considered the elements of risk that may threaten the existence of the company; a 4.1 analysis the Board has never seen does not satisfy that duty.

Illustrative Scenario 2: Success, Sarayu SaaS Labs (Illustrative, with ROI)

Disclaimer: This is an illustrative scenario. Sarayu SaaS Labs is a composite fictional entity; details are drawn from publicly-documented patterns of Indian B2B SaaS firms operationalising DORA and multi-region resilience. Numbers are illustrative and do not represent any specific company.

The organisation

Sarayu SaaS Labs Pvt. Ltd. is a Bengaluru-based B2B SaaS firm (300 staff; ~₹110 crore ARR) providing a treasury-management platform to mid-market (₹500–5,000 crore AUM) financial institutions in India, the EU, and the UK. The platform handles cash positioning, payments orchestration, and reconciliation. Roughly 38% of ARR comes from EU/UK customers, including three Tier-2 banks and two PSPs.

The 4.1 cycle

In January 2024, Sarayu's CEO and COO commissioned a full Clause 4.1 cycle ahead of an ISO 22301 certification Stage 1 audit scheduled for Q3. The cycle was led by the newly-hired BCM Lead (Priya Sharma) with external advisory support.

Phase A, Frame. The in-scope entity was the whole company. The BCM Lead appointed a context-analysis team: COO, CTO (Rahul Iyer), CISO, Head of Compliance, Head of Customer Success, Head of HR, and a board observer. The method chosen was PESTLE + internal capability, with a STEEPLED extension for the demographic dimension. Time-horizons were defined as immediate / 12-month / 1–3-year / 3–10-year.

Phase B, Gather. Three workshops:

• CXO workshop surfaced the EU/UK customers' DORA conversations (DORA applies 17 January 2025); the AI-adoption pressure on product roadmap; the perceived cyber-insurance hardening; and the Bengaluru-office flood risk (2022 floods had taken out two days of operations).
• Cross-functional workshop surfaced the single-cloud concentration (~92% AWS ap-south-1 + a small EU region for two customers), the 3-engineer bus-factor on the payments module, the absence of an exit strategy from the core platform vendor, and theCERT-In 6-hour reporting gap (no PoC, no tested IR plan).
• Site/BU workshop surfaced the Bengaluru-Hyderabad secondary site that existed but was used only for DR tests, and the Chennai satellite office that handled customer support and was cyclone-exposed.

Desk research identified: DORA Arts 8, 11(5), 12(6), 26 (TLPT every 3 years for Tier-1 ICT service providers, potentially applicable), 30 (exit strategies); RBI MD IT Governance (for the Indian customers); SEBI CSCRF (for the SEBI-regulated customers); DPDP Act 2023 (full applicability); CERT-In Directions; APRA CPS 230 (one Australian customer); NGFS climate scenarios; Ministry of Earth Sciences climate projections for Karnataka/Tamil Nadu.

Phase C, Synthesise. The PESTLE + Internal matrix yielded 28 material issues, distilled to 11 priority issues for board-level visibility. The top three: DORA exposure; single-cloud concentration; Bengaluru flood + workforce-concentration risk.

Phase D, Trace. The traceability matrix mapped each of the 28 issues to interested parties, scope decisions, risks, objectives, and strategy. DORA exposure traced to: customers' compliance teams (4.2); scope expansion to include the EU/UK customer-facing platform (4.3); a "DORA-audit-failure" risk and a "DORA-ready differentiation" opportunity (6.1); an objective "100% EU-revenue critical paths DORA-aligned by Q3" (6.2); and a strategy of active-active EU + India regions, segregated backups, and tested exit strategy per DORA Art 30 (8.3).

Phase E, Approve and operationalise. The Risk Committee (chaired by an independent director) reviewed and approved the analysis in March 2024; the Board noted it. The analysis was communicated to all staff in April. The refresh calendar was set (annual full + quarterly regulatory + event-triggered).

The investment

Driven by the 4.1 trace, Sarayu made a set of investment decisions through 2024:

• Multi-region active-active for Tier-1 services, AWS ap-south-1 (Mumbai) + eu-west-1 (Ireland), with multi-AZ resilience and a tested regional failover. ₹1.6 cr over 9 months (engineering, infra, testing).
• DPO + DORA-readiness programme, DPO appointment (a fractional DPO via a Bengaluru firm), DORA-aligned DPIA, TLPT preparation. ₹45 lakh over 6 months.
• CERT-In 6-hour IR capability, PoC appointment, SOC partnership (a managed SOC in Bengaluru with a 24×7 SLA), IR runbook, tabletop exercises. ₹35 lakh over 4 months.
• Workforce resilience, Work-from-anywhere hardening (laptop refresh, secure SD-WAN, identity, MDM); Bengaluru-Chennai-Pune distributed-staffing programme for critical roles. ₹55 lakh over 7 months.
• Climate-adaptation for the DC footprint, Secondary DC moved out of a flood-prone corridor; quarterly flood-drill; battery + genset upgrade. ₹45 lakh over 5 months.

Total 4.1-driven investment: ₹2.8 crore (excluding ordinary BCM programme costs), spread over 9 months.

The ROI event

In the fourth quarter of 2024, an incident affecting a major hyperscaler region (the nature of which is publicly documented) took several SaaS platforms offline for hours, some for the better part of a business day. Sarayu's Tier-1 services failed over to the EU region within 11 minutes (RTO achieved: 11 minutes; target: 15 minutes). Customer-side impact: brief latency degradation, no transaction loss (RPO = 0). Two of the three EU/UK bank customers and the two PSPs sent public notes acknowledging Sarayu's resilience relative to other vendors in their stack.

The follow-on business

Within 6 months of the incident, Sarayu closed two new EU fintech customers at €1.4 million ARR each (€2.8 million ≈ ₹25 crore). Both customers cited Sarayu's DORA-aligned posture (the multi-region architecture, the tested exit strategy per Art 30, the TLPT readiness) as a primary reason for selection. One of the existing EU/UK bank customers expanded its contract by 60% (≈ ₹6.5 crore ARR uplift).

The numbers

• 4.1-driven investment: ₹2.8 cr.
• First-year ROI event benefit: ₹25 cr (new) + ₹6.5 cr (expansion) = ₹31.5 cr in new/expanded ARR.
• Avoided loss: estimated ₹4.5–7 cr in churn/SLA-penalty exposure had the platform gone down for hours with the same customer base (peer-firm benchmarks).
• Insurance: cyber-insurance premium reduced 18% on renewal (the multi-region + IR capability + DPO investment were credited by the insurer).
• Payback: approximately 3.5 months from the October 2024 incident to the close of the first follow-on EU contract.
• 14-month ROI: ~10× on the 4.1-driven investment, with the resilience benefit compounding in subsequent years.

The lessons (in 4.1 terms)

1. A serious 4.1 cycle produces a materiality filter that drives investment to the right places. Sarayu's investment in multi-region + DPO + IR was not generic "security spend", it traced to specific material issues.
2. The traceability matrix is the bridge from 4.1 to strategy. Without it, investment happens in silos; with it, every dollar traces to an issue.
3. DORA is a customer-facing opportunity, not just a compliance burden. The 4.1 analysis surfaced DORA as both a risk and an opportunity; the commercial team used it.
4. Climate was not a separate workstream. The flood-risk dimension shaped the secondary-DC relocation decision, which contributed to the regional-resilience posture that delivered the ROI.
5. Board engagement mattered. The independent-director-chaired Risk Committee approved the analysis and the investment; the post-incident conversation with the board was therefore about execution, not about why weren't we prepared.

Multi-Framework Mapping

The table below maps ISO 22301:2019 Clause 4.1 to the equivalent or strongly-related requirements in other major frameworks. The mappings are Singahi's practitioner mappings, not official equivalences, based on the cited clauses and articles of each instrument.

Practical implications of the mapping

For most growing companies in India, three mappings drive day-to-day work:

1. ISO 22301 ↔ ISO 27001: produce one context-analysis document that serves both management systems. The ISMS lens adds information-security issues; the BCMS lens adds continuity and climate issues. Combine.
2. ISO 22301 ↔ RBI / SEBI / IRDAI / CERT-In: each Indian regulator's framework requires the same underlying context understanding, expressed in its own vocabulary. A strong 4.1 artefact is the single source that feeds every regulatory return.
3. ISO 22301 ↔ DORA / APRA CPS 230: for Indian firms serving EU or Australian customers, the foreign regime is a material issue under 4.1; satisfying DORA Art 8 or CPS 230 §7–11 is essentially doing a parallel 4.1 analysis for that customer segment.

Implementation Roadmap

A phased 180-day roadmap for a growing company (50–2,000 staff) implementing Clause 4.1 from scratch. Larger mid-market (250–2,000) and enterprise scales add depth and parallelism but follow the same shape.

Days 0–30: Frame and assemble

• Day 0: Executive sponsor (COO / CRO / CIO) charters the 4.1 cycle.
• Day 3–5: Appoint the context-analysis lead (BCM Manager or equivalent).
• Day 7–10: Adopt the Context Analysis Policy (Toolkit Doc 01); tailor to the organisation.
• Day 10–14: Define in-scope organisation; agree method (PESTLE) and time-horizons.
• Day 14–21: Gather prior analyses: ERM risk register; ESG report; last BIA; last ISO 27001 SoA; SOC 2 report; board-risk-committee minutes; recent regulatory inspection reports; recent incident postmortems.
• Day 21–28: Build the context-analysis RACI (Toolkit Doc 13).
• Day 28–30: Issue workshop invitations; book CXO, cross-functional, and site/BU workshops.

Days 30–90: Gather, synthesise, trace

• Day 30–45: Run CXO workshop; cross-functional workshop; site/BU workshops. Capture verbatim.
• Day 45–60: Desk research: regulatory horizon scan; climate scan; threat landscape; supplier ecosystem.
• Day 60–75: Cluster issues into PESTLE + Internal; assign time-horizon, uncertainty, BCMS-impact; flag materiality.
• Day 75–85: Build the traceability matrix (each material issue → 4.2 / 4.3 / 6.1 / 6.2 / 8.3).
• Day 85–90: Draft the context analysis document (4–10 pages plus appendices).

Days 90–150: Approve, integrate, communicate

• Day 90–100: Executive-sponsor review; Risk Committee review; revisions.
• Day 100–110: Risk Committee approval; Board notation (where applicable).
• Day 110–130: Cascade outputs: refresh Clause 4.2 interested-parties register; review Clause 4.3 scope; refresh Clause 6.1 risk register; refresh Clause 6.2 objectives; re-scope Clause 8.1/8.2/8.3 plans; update Clause 8.5 exercise programme.
• Day 130–140: Communicate summary to the organisation (Clause 7.3 awareness input).
• Day 140–150: Internal audit (Clause 9.2) of the 4.1 cycle.

Days 150–180: Operationalise and schedule

• Day 150–165: Address internal-audit findings; update the analysis; re-approve where material.
• Day 165–175: Schedule the refresh calendar: annual full + quarterly regulatory/climate scan + event-triggered refresh.
• Day 175–180: Feed the next Clause 9.3 management review with the refreshed context; document continuous-improvement actions (Clause 10.2).

For mid-market (250–2,000) and enterprise, expand the workshops into per-BU cycles, parallelise desk research across the compliance team, and add a quarterly metric cadence (Section 12) reporting to the Risk Committee.

FAQ

Q1. We are a 60-person SaaS start-up. Does 4.1 apply to us? Yes, fully. The depth scales: you might run two workshops (CXO + cross-functional) instead of three, and your PESTLE might cover 8 issues instead of 40. But the discipline of identifying your operating context is independent of size, and the regulator (CERT-In, DPDP) does not exempt small firms.

Q2. We already have an ISO 27001 context-of-the-organisation document. Do we need a separate 4.1 analysis for ISO 22301? No, but you need to extend it. Produce one document with two lenses (ISMS + BCMS). The ISMS lens adds information-security issues; the BCMS lens adds continuity, climate and supplier-concentration issues.

Q3. The standard says "issues that affect the ability to deliver". Does that mean only negative issues? No. "Issues" includes opportunities. Climate change, AI adoption, DORA readiness, each is an issue with both risk and opportunity dimensions. Materiality is the filter, not negativity.

Q4. Do we have to use PESTLE? No. Any defensible structured method (STEEPLED, ISO 31000's "establishing the context", COSO ERM "external/internal environment") works. PESTLE is the most common because it surfaces climate and regulation naturally. SWOT is acceptable as a synthesis step but should not replace PESTLE because it loses time-horizon.

Q5. How often should we refresh? At least annually. Add a quarterly regulatory + climate horizon scan. Add event-triggered refresh: major change (M&A, new product, new geography, new core system, new outsourcing); post-incident (Clause 8.6 / 10.1); post-exercise drift (Clause 8.5); new material regulation; new climate scenario.

Q6. Is climate really mandatory under Amendment 1:2024? Yes. Amendment 1:2024 modifies Clauses 4.1 and 4.2 to require the organisation to consider climate change as an issue. Certifications conducted against the amended standard (most major certification bodies moved to the amended standard during 2024–2025) expect climate to appear in the 4.1 analysis.

Q7. We are an NBFC. What's the minimum regulatory list to identify? RBI Master Direction IT Governance (7 Nov 2023, eff. 1 Apr 2024); RBI Cyber Security Framework in Banks (2 Jun 2016, applied to NBFCs through later graded circulars); RBI Master Direction Outsourcing of IT Services (10 Apr 2023); RBI MD Outsourcing of Financial Services (NBFCs); CERT-In Directions (28 Apr 2022); DPDP Act 2023; Companies Act 2013 §134(3)(n)/§177; IT Act 2000. If you have EU/UK customers, add DORA (applies 17 Jan 2025). If you have Australian customers, add APRA CPS 230 (eff. 1 Jul 2025).

Q8. What does the auditor actually want to see for traceability? For each material issue: a documented link to (a) the interested parties it affects (4.2); (b) any scope decision it drove (4.3); (c) the risks and opportunities it generated (6.1); (d) the objectives it shaped (6.2); (e) the strategy selections it informed (8.3). The Toolkit Doc 02 traceability matrix is the format.

Q9. Our board has never discussed 4.1. Is that a finding? Almost certainly yes. Companies Act 2013 §134(3)(n) requires the Board's Report to include a statement on the development and implementation of a risk management policy, including the elements of risk that may threaten the existence of the company. A 4.1 analysis the Board has not seen does not satisfy that duty. For listed companies, SEBI LODR Regulation 21 makes this explicit through the Risk Management Committee.

Q10. We had a ransomware incident last year. Does that change our 4.1 analysis? Yes, that is the textbook event-triggered refresh. The post-incident review (Clause 8.6 / 10.1) should have surfaced new material issues (the specific threat actor, the specific failure path, the specific supplier involvement); those should appear in the refreshed 4.1 analysis.

Q11. Our last context analysis is two years old. Is that a non-conformity? Almost always yes. The cycle is "at least annually" plus event-triggered. Two years without refresh, particularly across the 2023–2025 sequence of major Indian regulatory changes (RBI MD, SEBI CSCRF, IRDAI 2023, CERT-In, DPDP), is a major finding.

Q12. Can we outsource 4.1 to a consultant? You can outsource the facilitation (workshop design, desk research, drafting, traceability matrix construction). You cannot outsource ownership, the BCM Lead and executive sponsor remain accountable; top management must approve; the Board (or Risk Committee) must engage. A consultant-produced 4.1 that the board has never discussed is decorative.

Q13. We have multiple BCMS scopes (one per client engagement). Do we need a 4.1 per scope? Usually one group-level 4.1 plus a per-scope addendum works. The addendum captures the scope-specific issues (the specific customer's regulatory regime, the specific dependencies, the specific site). Avoid running five parallel 4.1 cycles, they drift and produce inconsistent materiality.

Q14. What about contested attributions like the Mumbai 2020 blackout? Present both positions (Maharashtra state's "cyber sabotage" / Recorded Future's RedEcho attribution vs the Union Power Ministry's "human error, not cyber"). Do not assert a single cause. Note the disagreement in the 4.1 document. This is both an intellectual-honesty practice and a 4.1 best practice, contested issues are material issues regardless of attribution certainty.

Q15. Where does 4.1 stop and 6.1 begin? 4.1 frames the risk picture; 6.1 rates and treats specific risks. The bright line: 4.1 says "supplier concentration is a material issue for us"; 6.1 says "the risk that Vendor X's failure disrupts Activity Y has inherent likelihood = 4 and impact = 5; we will treat by adding Vendor Z as a warm standby by Q3."

Industry-Specific Requirements

The shape of a defensible Clause 4.1 analysis varies materially by sector. The five sectors below are the most common among Indian growing companies.

BFSI, Banks, NBFCs, Payment System Operators

Material 4.1 issues (in addition to the generic):

• RBI MD IT Governance (7 Nov 2023, eff. 1 Apr 2024), the consolidated instrument; identifies BCM/DR chapters as material to the regulated entity.
• RBI Cyber Security Framework in Banks (2 Jun 2016), board-approved cyber policy; SOC; CCMP; 2–6 hour RBI reporting.
• RBI MD Outsourcing of IT Services (10 Apr 2023), inherited continuity from outsourcers/cloud; concentration risk; right of RBI access.
• RBI Cyber Resilience and Digital Payment Security Controls for PSOs, for non-bank PSOs.
• UPI / NPCI dependency, for banks and PSPs, the UPI rail is a material infrastructure dependency (cf. 12 Apr 2025 ~5-hour UPI nationwide degradation).
• Card-network dependency, RuPay/Visa/MasterCard.
• Cross-border (DORA, APRA CPS 230, MAS TRM, HKMA), for banks/PSPs with EU/Australian/Singapore/Hong Kong exposure.

Sector-specific 4.1 emphasis: supplier-concentration analysis (core-banking, payment switch, card-network, TPAP); DC/DR site diversity; cyber-threat landscape (cf. HDFC RBI 2 Dec 2020 action; Yes Bank moratorium 5–18 Mar 2020); liquidity-continuity linkage; fraud-continuity interaction; regulator-as-interested-party.

Healthcare, Hospitals, Health-Tech, Pharma

Material 4.1 issues:

• Clinical Establishments (Registration and Regulation) Act 2010 + state rules.
• DPDP Act 2023, health data is sensitive; Section 8(5) availability is a clinical-safety duty, not just an IT metric.
• IRDAI (for insurer-paid services), claims-data continuity.
• NDMA Hospital Safety Guidelines + NDMA Chemical Disaster Guidelines 2007 (for pharma).
• CDSCO / State FDA (for pharma manufacturing), GMP continuity.
• Cyber threat, hospital ransomware (AIIMS Delhi 23 Nov 2022 is the canonical Indian case); pharma ransomware (Sun Pharmaceutical 2023; Tata Technologies 2023).
• Climate, heatwave hospital-surge; cold-chain for vaccines/pharma; flood exposure for hospitals and manufacturing.

Sector-specific 4.1 emphasis: clinical-safety framing of continuity; manual-mode fallback (paper medical records, manual billing) as a strategy option; cold-chain continuity for biologics/vaccines; OT/IT convergence for pharma manufacturing; AIIMS-style ransomware scenarios in the exercise programme.

IT/ITeS & SaaS

Material 4.1 issues:

• CERT-In Directions (28 Apr 2022), 6-hour clock; 180-day logs; NTP; VPN/DC/cloud KYC.
• DPDP Act 2023, for SaaS handling customer personal data; breach notification; Significant Data Fiduciary criteria.
• Customer-contract SLAs, typically stricter than the firm's own BCMS targets; specific named-customer scenarios.
• Cross-border regimes, DORA (for fintech customers), EU AI Act (for AI-enabled SaaS), GDPR, US SEC cyber disclosure (for US-listed customers), MAS TRM, HKMA, APRA CPS 230.
• Cloud concentration, single-hyperscaler risk; multi-region/multi-cloud architecture as strategy.
• Software-supply-chain risk, build-pipeline integrity (cf. SolarWinds SUNBURST, Dec 2020), dependency confusion, signed-update trust model.
• People concentration, engineer-bus-factor; talent concentration in metros (Bengaluru, Hyderabad, Pune, Gurugram).

Sector-specific 4.1 emphasis: customer-as-interested-party (with per-customer regulatory mapping); cloud-concentration analysis; build-pipeline integrity; workforce-resilience (WFH, distributed staffing); DORA/CSRD readiness for EU customers.

Manufacturing, Discrete, Process, Pharma Manufacturing

Material 4.1 issues:

• NDMA Chemical Disaster Guidelines 2007 + NDMA Industrial Disaster Guidelines (cf. LG Polymers 2020, environmental-clearance gap; NGT ₹50 cr).
• Factories Act 1948 + state Factories Rules; Manufacture, Storage and Import of Hazardous Chemicals Rules 1989 (MSIHC).
• CDSCO / GMP for pharma manufacturing.
• DPDP (for HR/customer data; lighter touch unless consumer-facing).
• Cyber, OT/IT convergence; ransomware halting production (Tata Technologies 2023; Bajaj Auto); sub-tier supplier opacity.
• Supplier concentration, single-source critical components (cf. Go First – Pratt & Whitney PW1100G; Maruti Suzuki Manesar 2012 violence as a workplace-continuity event).
• Climate, heatwave worker-safety; water stress (cf. Bengaluru, Chennai manufacturing corridors); flooding (cf. Chennai 2015).
• Industrial relations, workplace violence as a disruption scenario (Maruti Suzuki Manesar 18 Jul 2012, Awanish Kumar Dev (GM-HR) killed, 91 arrested, ~₹1,400 cr lockout loss).

Sector-specific 4.1 emphasis: OT/IT segmentation; MSIHC compliance; supply-chain tier-2/tier-3 visibility; workforce violence scenario; environmental-clearance status as a continuity prerequisite.

Government & Public Sector

Material 4.1 issues:

• CERT-In Directions (horizontal).
• MeitY, Cloud First / Government Cloud policy; MeitY Empanelment of Cloud; Digital India guidelines; Digital Data Protection Act 2023.
• NDMA, Disaster Management Act 2005; Section 35/37/40 duties; NDMA N3 DMP template (Prevention / Mitigation / Preparedness / Response / Relief / Recovery & Reconstruction / Capacity Building).
• CAG, performance-audit expectations on ICT/BCM.
• IT Act 2000 §70A, NCIIPC for Critical Information Infrastructure (CII); §70, protected systems.
• e-Governance standards (Ministry of Electronics and IT).

Sector-specific 4.1 emphasis: NCIIPC engagement for CII; interoperability with NDMA District DMPs; CAG audit trail; citizen-as-data-principal (DPDP); DPI dependence (UPI, DigiLocker, Account Aggregator, Aadhaar).

Maturity Model

A five-level maturity model for Clause 4.1, with indicative INR investment estimates. The estimates are Singahi's observed ranges for Indian growing companies (50–2,000 staff); enterprise investments scale up materially.

How to advance levels

• L1 → L2: Run a structured PESTLE workshop; appoint the BCM Lead as owner; take the document to the executive sponsor.
• L2 → L3: Add quarterly scans; complete the traceability matrix; build the KPI dashboard; take the analysis to the Risk Committee.
• L3 → L4: Integrate with ERM; enter an IRM/GRC platform; add cross-standard mapping; pilot scenario stress-testing.
• L4 → L5: Subscribe to regulatory/threat-intel feeds; commission independent assurance; integrate with ESG and DORA/CPS 230 programmes; move to monthly board KPI reporting.

Most growing companies in India can and should target L3 within 18 months of starting ISO 22301. L4–L5 is the realm of larger mid-market (250–2,000) and enterprise firms with complex regulatory exposure.

Emerging Trends

Several trends will reshape Clause 4.1 practice over the next 24–36 months:

Climate-resilience mainstreaming

Amendment 1:2024 is the standard's formal acknowledgement that climate is now core BCM, not adjacent. Indian firms should expect: (a) certification bodies to test climate-issues coverage actively from 2025 onwards; (b) regulators (RBI's climate-risk discussion paper line, SEBI BRSR) to elevate climate continuity as a supervisory topic; (c) customers (especially EU/UK under CSRD) to require climate-continuity disclosure in supply-chain due diligence; (d) investors and insurers to price climate-continuity posture into valuations and premiums.

Operational-resilience convergence (DORA / CPS 230 / UK FCA-PRA)

DORA (applies 17 Jan 2025), APRA CPS 230 (eff. 1 Jul 2025), and the UK operational-resilience regime (FCA PS21/3, PRA SS1/21) collectively define operational resilience as the new supervisory frame. Where ISO 22301 talks "business continuity," these regimes talk "operational resilience", but the underlying analytic is the same: identify important business services, set impact tolerances, test against severe-but-plausible scenarios, learn. The 4.1 analysis is the bridge: a strong 4.1 is a strong "identification of important business services and their dependencies" under all three regimes. Expect Indian regulators (RBI, SEBI) to move further in this direction through 2025–2027.

NIST CSF 2.0's Govern function

The addition of the Govern function (GV) to NIST CSF 2.0 (26 Feb 2024) makes context-setting a first-class cybersecurity outcome. GV.OC (Organizational Context) is essentially Clause 4.1 by another name. For Indian firms running both ISO 22301 and NIST CSF (common for US-market SaaS), the two analyses are converging.

DPI as a context dimension

India's Digital Public Infrastructure, UPI, Account Aggregator, DigiLocker, Aadhaar, ONDC, ABDM, is now a material context issue for most consumer-facing Indian businesses. The 12 April 2025 UPI nationwide degradation (~5 hours; NPCI blamed participating banks over-polling "check transaction status" APIs) was a sector-level continuity event. 4.1 analyses that do not name DPI dependencies are incomplete.

Software-supply-chain and AI supply-chain risk

SolarWinds SUNBURST (Dec 2020), Kaseya VSA (Jul 2021), and the emergence of LLM-supply-chain risk (foundation-model dependency, training-data poisoning, prompt-injection) are pushing supplier-concentration and software-supply-chain to the centre of 4.1 analyses. Firms using foundation models as core infrastructure should treat the model vendor as a Tier-1 continuity dependency.

Geopolitical fragmentation

US-China tech decoupling, export controls on advanced semiconductors, the EU's economic-security strategy, and India's own production-linked incentive schemes are reshaping the technology-supplier map. For Indian firms that sourced hardware or software from Chinese OEMs (telecom, IoT, cameras, industrial control) the 4.1 analysis should flag geopolitical supply-chain risk and pre-position alternatives.

Climate-attribution science and event-linked losses

As climate-event attribution science matures (the World Weather Attribution network publishes rapid-attribution studies within weeks of major events), expect disclosure regimes (BRSR, CSRD's ESRS E1, ISSB IFRS S2) to require firms to quantify event-linked losses attributable to climate change. The 4.1 analysis is where the firm first records its climate-event exposure, making it the foundation for downstream disclosure.

Board competencies on operational resilience

Boards and Risk Committees are slowly building operational-resilience competency, partly driven by SEBI LODR Reg. 21 (Risk Management Committee must include members with risk-management expertise), partly by regulator pressure (RBI's expectation that boards understand ICT risk), partly by incident experience. The 4.1 analysis is the document that lets a competent board engage; a board that cannot engage with 4.1 is the wrong board for an operational-resilience era.

References and Further Reading

The references below are the primary instruments, regulator publications, and standards cited in this guide. Always verify the current edition on the issuing body's official portal before relying on a specific clause or article number.

Standards and guidance

• ISO 22301:2019 / Amd 1:2024, Security and resilience, Business continuity management systems, Requirements (with Climate action changes amendment, Feb 2024). International Organization for Standardization, Geneva.
• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301.
• ISO 22300:2021, Security and resilience, Vocabulary (verify if a 2025 edition has published).
• ISO/TS 22317:2021, Security and resilience, Business continuity management systems, Guidelines for business impact analysis.
• ISO/TS 22318:2021, Security and resilience, Business continuity management systems, Guidelines for supply chain continuity.
• ISO/TS 22330, Guidelines for people aspects of business continuity.
• 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 regulators

• Reserve Bank of India, Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 Nov 2023, eff. 1 Apr 2024). rbi.org.in.
• Reserve Bank of India, Cyber Security Framework in Banks (2 Jun 2016). rbi.org.in.
• Reserve Bank of India, Master Direction on Outsourcing of Information Technology Services (10 Apr 2023). rbi.org.in.
• Securities and Exchange Board of India, Cybersecurity and Cyber Resilience Framework (CSCRF), SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 (20 Aug 2024). sebi.gov.in.
• Securities and Exchange Board of India, Guidelines for BCP/DR of Market Infrastructure Institutions, SEBI/HO/MRD1/DTCS/CIR/P/2021/33 (22 Mar 2021; modifications 12 Sep 2024). sebi.gov.in.
• Insurance Regulatory and Development Authority of India, Information and Cyber Security Guidelines, 2023 (24 Apr 2023). 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 Apr 2022). cert-in.org.in.
• Ministry of Electronics and Information Technology, Digital Personal Data Protection Act, 2023 (Act 22 of 2023, 11 Aug 2023) + Digital Personal Data Protection Rules, 2025. meity.gov.in.
• National Disaster Management Authority, Disaster Management Act, 2005; Chemical Disaster Guidelines 2007; Guidelines for Preparation of Disaster Management Plans (2014). ndma.gov.in.
• Ministry of Corporate Affairs, Companies Act, 2013 (Sections 134(3)(n), 177). mca.gov.in.
• Securities and Exchange Board of India, Listing Obligations and Disclosure Requirements (LODR) Regulations, 2015 (Regulation 21, Risk Management Committee).

Cross-border frameworks

• European Union, Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Applies 17 January 2025. eur-lex.europa.eu.
• Australian Prudential Regulation Authority, CPS 230 Operational Risk Management (eff. 1 July 2025). apra.gov.au.
• US National Institute of Standards and Technology, NIST Cybersecurity Framework 2.0 (NIST.CSWP.29, 26 Feb 2024); NIST SP 800-34 Rev 1 (May 2010); NIST SP 800-160 Vol 2 Rev 1 (Sep 2021). nist.gov.
• US Federal Financial Institutions Examination Council, IT Examination Handbook, Business Continuity Management Booklet (Nov 2019; OCC 2019-57, FRB SR 19-13, FDIC FIL-19071). ffiec.gov.
• US Federal Emergency Management Agency, Federal Continuity Directives FCD-1 and FCD-2 (2017) under PPD-40. fema.gov.

Practitioner bodies and datasets

• The Business Continuity Institute, BCI practitioner guidance (31 Oct 2023); Horizon Scan 2025 ("Complex and Interconnected Risk"); Horizon Scan 2024. thebci.org.
• Disaster Recovery Institute International, Professional Practices for Business Continuity Management (10 practices; living framework). drii.org.

Indian incident references (primary-sourced; cited as illustrative anchors)

• AIIMS Delhi ransomware (23 Nov 2022), peer-reviewed case in International Journal of Information Management; reporting in The Hindu.
• HDFC Bank repeated digital outages → RBI action (2018–2020), RBI order; Livemint, Finextra.
• Yes Bank moratorium (5–18 Mar 2020), illustrative scenario in Yale Journal of Financial Conduct.
• Cognizant, Maze ransomware (Apr 2020), SEC 10-Q/10-K (ctsh-20201231); disclosed Q2 2020 impact US$50–70 million.
• Cognizant, Chennai floods (Dec 2015), official Cognizant statement; reaffirmed FY2015 revenue guidance ≥ US$12.41 billion.
• Jio DC fire (17 Sep 2024), Reuters; Cloudflare Radar (AS55836 traffic down up to 53%).
• Go First insolvency (filed 2 May 2023), NCLT; refund liability ₹597 cr (airline disclosure, 31 Jul 2023).
• SpiceJet DGCA enhanced surveillance (27 Jul 2022), 50% of approved Summer Schedule for 8 weeks.
• Air India / SITA breach (Feb 2021, disclosed May 2021), Reuters; ~4.5 million customers.
• LG Polymers Vizag styrene gas leak (7 May 2020), NGT Joint Monitoring Committee report (OA 73/2020); NGT interim penalty ₹50 cr; 12–13 fatalities.
• Maruti Suzuki Manesar violence and fire (18 Jul 2012), production loss ~₹70–75 cr/day; ~₹1,400 cr lockout loss; Awanish Kumar Dev (GM-HR) killed; 91 arrested.
• Mumbai blackout (12 Oct 2020), Western Regional Power Committee report; Maharashtra State Cyber cell findings; Recorded Future attribution (Feb–Mar 2021). Attribution contested between Maharashtra ("cyber sabotage") and the Union Power Ministry ("human error, not cyber"); present both positions; do not assert.
• UPI nationwide degradation (12 Apr 2025), ~5 hours; NPCI blamed participating banks over-polling "check transaction status" APIs.
• Akasa Air pilot exodus (2023), Emerald EEMCS illustrative scenario; Livemint.

This guide was prepared by Singahi for the receiving organisation's implementation of ISO 22301:2019 Clause 4.1. The paraphrased requirement, the worked examples, the traceability matrix, and the illustrative scenarios are Singahi's own drafting. ISO 22301:2019's own clause text is copyrighted and is not reproduced. All regulatory and framework references are to public instruments named in Section 24; verify current versions on the issuing body's official portal before relying on them. Numerical estimates (impact figures, investment ranges, INR bands) are illustrative and based on Singahi's observed ranges for Indian growing companies, adapt to your organisation's reality.