ISO 22301 Clause 4.3: Determining the Scope of the BCMS

Quick Reference (60 Seconds)

If you only read one thing: Clause 4.3 is where the BCMS stops being an abstract ambition and becomes a bounded management system. A clean 4.3 Scope Statement is what makes your BIA cover the right activities, your strategy fund the right recovery solutions, your plans exercise the right procedures, and your certification audit sample the right evidence. Get 4.3 wrong, too narrow and you certify a fragment of the business that misleads customers and regulators; too broad and you commit the organisation to a BCMS it cannot resource, and the rest of the BCMS, however technically perfect, will be answering the wrong question.

What the Standard Actually Requires

Figure · Process

What Clause 4.3 asks you to do

The paraphrased requirement

ISO 22301 Clause 4.3 asks organizations to determine the boundaries of their business continuity management system, to decide which parts of the organization, which products and services, which locations and which activities the BCMS will cover, and to make that scope available as documented information. The scope must be determined in the light of the Clause 4.1 context (internal and external issues) and the Clause 4.2 analysis (interested parties, their needs and expectations, and the legal, regulatory and other requirements that flow from them). With Amendment 1:2024 in force (published February 2024; taken over as EN ISO 22301:2019/A1:2024 in September 2024), the organisation is expected to bring climate-change considerations explicitly into the context that scope reflects. The climate dimension is not a separate sub-clause; it is part of the 4.1 / 4.2 / 4.3 trilogy the organisation reasons through when drawing the boundary.

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

1. Coverage, Have we named every part of the organization we propose to bring inside the BCMS (legal entities, business units, functions, products, services, locations, activities, supplier interfaces), in language an auditor can sample against?
2. Boundary, Is the boundary of the BCMS unambiguous? Could two reasonable readers, six months apart, draw the same line from this document?
3. In/out decisions, For every candidate that was considered (entities, products, sites, activities, suppliers), have we recorded an explicit in/out decision with a documented rationale that traces back to 4.1 and 4.2?
4. Justification for exclusions, Have we justified what we have excluded? Scope exclusions in ISO 22301 are not forbidden, but unjustified or capability-affecting exclusions draw immediate auditor scrutiny.
5. Dependency mapping, Have we mapped the in-scope activities' dependencies on people, premises, technology, information, suppliers and third parties, including dependencies that cross the boundary (e.g., an in-scope core banking platform depending on an out-of-scope captive subsidiary for daily reconciliations)?
6. Interfaces, Have we documented the interfaces between in-scope and out-of-scope units, and the continuity obligations that flow across them (so an out-of-scope unit cannot quietly break the in-scope one)?
7. Multi-entity, multi-geography, For groups, have we named the legal entities, branches and international operations in or out of scope, and reflected any sectoral scope boundaries (e.g., RBI RE scope, SEBI MII scope, DORA scope, parent-company scope)?
8. Climate and physical-risk exposure, Under Amendment 1:2024, have we considered climate-driven scope inputs, flood-exposed locations, heat-stressed workforces, water-dependent manufacturing, supply-chain climate exposure, when drawing the boundary?
9. Living process, When and how will we re-do this? Annually; on event trigger (M&A, divestiture, new geography, new regulator, new climate scenario, post-incident, post-exercise); after every Clause 9.3 management review; and as part of Clause 6.3 planned changes.

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

Clause 4.3 is the most under-served clause in the public BCM literature because most commentators reduce it to "write a scope paragraph". It is helpful to be explicit about what is out of scope for 4.3, because auditors test the boundary:

• It does not require identifying internal/external issues. That is Clause 4.1. 4.1 names the issues; 4.3 draws the boundary that responds to them.
• It does not require identifying interested parties or obligations. That is Clause 4.2. 4.2 names the people and the requirements; 4.3 reflects them in the boundary (for example, the scope must include any part of the organisation that is subject to a captured regulatory obligation).
• It does not require running a BIA. That is Clause 8.2. 4.3 sets the population of activities that the BIA will then prioritise; the BIA does not decide what is in the BCMS, it ranks what is already in.
• It does not require selecting continuity strategies. That is Clause 8.3. 4.3 describes what must be recovered; 8.3 decides how.
• It does not require full organizational-structure documentation. That is the job of HR / corporate secretarial. 4.3 references enough of the org structure to bound the BCMS, it does not reproduce it.
• It does not require that the BCMS cover the entire organization. Partial scope is permissible, provided the exclusion is justified, the boundary is documented, and the out-of-scope units do not quietly carry in-scope dependencies that the BCMS ignores. Many growing companies certify an entity, a business unit or a service line first and widen scope over successive cycles.
• It does not require treating outsourced functions as automatically out of scope. On the contrary, where an outsourced function underpins an in-scope activity, 4.3 must capture the dependency and Clause 8.1 must extend continuity controls to it. Outsourcing moves the control boundary, not the accountability boundary.
• It does not require climate scenario modelling to TCFD/NGFS specifications. Amendment 1:2024 requires that climate-driven scope inputs 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. Five are most relevant for Clause 4.3:

• 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.3 it explains that scope is shaped by the organization's strategic objectives, its regulatory environment, its supply chain, its products and services, and the size and structure of the organization. It encourages the organisation to think in terms of what the BCMS needs to manage to deliver continuity outcomes, rather than in terms of corporate-legal boundaries alone.
• ISO/TS 22318:2021, Business continuity management systems, Guidelines for supply chain continuity. The most directly load-bearing companion for the supplier-interface dimension of scope. The 2015 edition is withdrawn; cite the 2021 edition. It makes explicit that a BCMS scope which ignores supply-chain dependencies is incomplete.
• ISO/TS 22331:2018, Guidelines for business continuity strategy. Shapes the recovery-shape inputs to scope: if the chosen strategy is multi-site recovery, scope must include the recovery site.
• ISO/IEC 27001:2022 Clause 4.3 covers the same concept for the ISMS; if your organisation runs an integrated ISMS+BCMS (common for Indian BFSI and SaaS), the two scopes should be reconciled, not duplicated.
• ISO 22300:2021, Vocabulary. Defines "scope", "boundary", "continuity", "prioritised activity" and related terms (a 2025 edition is under development (ISO/DIS 22300, 4th ed.) and not yet published, verify).

What auditors actually check

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

• The Scope Statement itself, is it specific, justified, and traceable to 4.1 and 4.2? Does it name the entities, products, services, locations, activities and supplier interfaces the BCMS will manage? Does it justify exclusions? Is it approved by top management? Is there a version history and a refresh date?
• The exclusion rationale, every exclusion is examined. "Out of scope because it is low-impact" without evidence is a finding. "Out of scope because it is managed by the parent's BCMS" requires that the parent's BCMS actually exist and actually cover it.
• Dependency and interface coverage, does the Scope Statement acknowledge what crosses the boundary? If the in-scope lending platform depends on an out-of-scope recovery vendor, is that captured? If the in-scope SaaS depends on an out-of-scope parental function, is that captured?
• Consistency with the rest of the BCMS, does the BIA cover every in-scope activity? Do the continuity plans cover every in-scope product and service? Does the exercise programme sample in-scope scenarios? Are incidents outside scope (and how is "outside scope" determined at incident time)? A Scope Statement that says "all products" but whose BIA covers only three of seven products is a major nonconformity waiting to happen.
• Climate considerations (Amendment 1:2024), for organisations with material climate exposure (flood-zone facilities, water-dependent manufacturing, heat-exposed field workforce, climate-vulnerable supply chains), the auditor will look for evidence that climate-driven scope inputs were considered. A blanket statement that "climate is not material to scope" without analysis is a finding.

Why This Control Matters

The business case

Clause 4.3 is the single decision that most decisively shapes the cost, the credibility and the operational usefulness of an ISO 22301 certification. Done well, scope concentrates BCMS effort on the parts of the business that actually need continuity management, produces a BIA that ranks the right activities, funds the right recovery solutions, and yields an exercisable plan set. Done badly, scope either over-promises (the BCMS claims to cover "the whole company" but the BIA covers three products) or under-delivers (the BCMS covers the parent company but silently excludes the captive subsidiary that holds the customer data), and the rest of the BCMS cannot recover the posture because it is built on a faulty foundation.

The financial logic of getting scope right is unusually clear. Continuity investment scales with the size and criticality of the in-scope footprint: every additional in-scope prioritised activity triggers BIA, strategy, plan, exercise, supplier-management and audit effort; every out-of-scope unit avoids those costs but exposes the organisation to the silent dependency risk where the in-scope part depends on the out-of-scope part. The scope decision is therefore a risk-cost optimisation: small enough to be affordable and credible; large enough to actually cover what matters. Indian growing companies routinely get this wrong on both sides, over-scoping because "the auditor wants the whole company" and under-scoping because "we'll add the subsidiary next year" (next year never comes).

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

Four features of the Indian business environment sharpen the consequences of a 4.3 failure:

• Group structures and captive subsidiaries. Indian growing companies are frequently structured as a parent (P) + one or more operating subsidiaries + a captive IT/BPO entity + an overseas holding company for cross-border customers. Each entity has its own PAN, GST registration and (often) its own regulator. A BCMS scope that names "the company" without naming the legal entity is dangerously ambiguous. The single most common 4.3 failure in Indian growing companies is a Scope Statement that covers the parent and silently excludes the captive subsidiary that processes customer personal data, the very entity whose failure would trigger a DPDP breach.

• Dense sectoral regulation with overlapping scopes. A mid-market financial-services group can simultaneously be a RBI RE (Master Direction IT Governance, 7 November 2023, effective 1 April 2024), a SEBI RE (CSCRF, 20 August 2024; BCP-DR for MIIs, 22 March 2021), an IRDAI-regulated insurance distributor, and a DPDP Significant Data Fiduciary, each with its own scope expectations. A 4.3 Scope Statement that maps to none of these regulators' definitions of "regulated entity" leaves scope gaps; one that is drawn solely from one regulator's lens may miss the others. CERT-In Directions (28 April 2022) apply horizontally to every Indian ICT operator, the Scope Statement must acknowledge that the BCMS, however tightly bounded, operates inside CERT-In's horizontal regime.

• Climate and natural-hazard exposure. India's geography, monsoon dependency and industrial concentration make climate disruption a first-order scope input, far more than in most OECD markets. The December 2015 Chennai floods submerged a major IT/BFSI delivery hub (Cognizant disclosed 11 delivery/operations centres affected); August 2018 Kerala floods hit Cochin and the wider Malabar coast (CIAL airport shut ~2 weeks with ~₹250 crore income loss); the 12 October 2020 Mumbai blackout affected hospitals, BSE and bank branches (cyber link contested between Maharashtra State Cyber Cell and the Union Power Ministry, present both positions); and heat-wave conditions across the Indo-Gangetic plain now routinely exceed wet-bulb survivability for outdoor workers. Amendment 1:2024 makes explicit what the geographic exposure already implied: climate is a scope input.

• Supplier concentration. Indian SaaS and IT-services firms often depend on a small number of cloud providers, payment switches, identity providers, telecom carriers and SMS gateways. The 17 September 2024 Jio DC fire (Cloudflare Radar measured AS55836 traffic down up to 53 per cent) and the 12 April 2025 NPCI/UPI ~5-hour nationwide degradation both showed the blast radius of single-vendor concentration. A 4.3 Scope Statement that treats these dependencies as out-of-scope "vendors" rather than as in-scope continuity dependencies misses the most likely disruption scenarios.

The cost of getting it wrong

A defective 4.3 scope generates three categories of cost:

• Certification and audit cost. Stage 1 audit is essentially a scope-examination exercise. A vague, unjustified, or internally inconsistent scope generates Stage 1 findings that delay Stage 2 by 2 to 6 months; re-audit fees of 8 to 25 lakh rupees for a growing firm; and, in the worst case, withdrawal of certification post-issuance when the inconsistency surfaces. Indian certification bodies operating under NABCB accreditation and IAF MD rules are increasingly strict on 4.3, the "scope shopping" of a decade ago is no longer tolerated.

• Operational disruption cost. A scope that silently excludes a real dependency produces a BCMS that cannot recover the business. The illustrative TantraSoft SaaS scenario in Section 14 traces how a parent-company scope that excluded a newly-acquired analytics subsidiary produced ₹4.2 crore in service-credit and remediation costs when the subsidiary's flood-induced outage cascaded into the parent's customer dashboards.

• Regulatory cost. Where the BCMS is required by an Indian regulator (RBI MD IT Governance for banks/NBFCs, SEBI CSCRF for SEBI REs, IRDAI 2023 for insurers, CERT-In horizontally), an inadequate scope is a regulatory breach. The Reserve Bank's 2 December 2020 action against HDFC Bank (restriction on new digital products and fresh credit cards, partially lifted 17 August 2021, fully lifted March 2022) illustrates how repeated digital outages get escalated to a board-level governance failure, and a scope that excluded the failing platform from BCMS coverage would have made that escalation faster, not slower. DPDP penalties up to ₹250 crore for failure to take adequate security safeguards (Section 8(5) availability duty) make a personal-data processing entity excluded from BCMS scope a material balance-sheet risk.

The counter-case is equally clear. A clean 4.3 scope concentrates spend on the right activities and visibly widens the organisation's resilience posture without inflating the BCMS cost. The illustrative Aravali Payments scenario in Section 15 traces how a payment aggregator that deliberately scoped in its critical payment-switch and SMS-gateway dependencies, and contracted a secondary for each, survived an 11-day SMS-gateway outage at a cost of ₹35 lakh of scope analysis plus ₹80 lakh of secondary contracts, against ₹7+ crore of avoided service credits and the avoided RBI penal action.

Scope and Applicability

Who 4.3 applies to

Clause 4.3 applies to every organisation seeking ISO 22301:2019 certification, regardless of size, sector or geographic footprint. It is a universal requirement, not a sector-conditional one. A 30-person SaaS startup, a 1,200-person NBFC, a 6,000-staff hospital chain and a 50,000-employee manufacturing group all draw a 4.3 scope, the complexity of the scope scales, but the obligation does not.

4.3 also applies to organisations pursuing internal alignment with ISO 22301 (without seeking certification). The discipline of drawing the boundary is the same; only the audit pressure differs. Many growing companies in India run a "shadow" 4.3 cycle 12 to 18 months before pursuing certification, to identify scope ambiguities before the certification body does.

What "the organization" means for 4.3

ISO management-system standards use "the organization" to mean the entity to which the standard is being applied. For 4.3, this is the legal entity (or defined group of entities) that the BCMS will cover. In India, this question is non-trivial because of common group structures:

• Single-company scope, the BCMS covers one legal entity (e.g., "Aravali Payments Private Limited"). Most common for independent growing companies.
• Multi-entity group scope, the BCMS covers several related legal entities (e.g., a parent + its operating subsidiaries). Requires naming each entity in scope and the entity-boundary interfaces.
• Partial-entity scope, the BCMS covers one or more business units, products or services within a larger legal entity (e.g., "the B2B SaaS subscription business unit of TantraSoft Private Limited"). Permissible where the rest of the entity is materially different in continuity risk profile, but requires rigorous justification.
• Cross-border scope, the BCMS covers the Indian operations of a foreign-headquartered group, or vice versa. Requires explicit treatment of the parent's BCM regime, data-localisation boundaries, and any cross-border regulatory regimes (DORA for EU financial-sector customers, APRA CPS 230 for Australian captives, MAS TRM for Singapore subsidiaries, HKMA OR-2/TM-G-2 for Hong Kong).

What 4.3 does NOT scope

4.3 scopes the BCMS, not the organisation's entire operations, not its full product portfolio, not its complete corporate footprint. The following are commonly confused with BCMS scope but are different things:

• Quality management scope (ISO 9001), different management system, different boundary.
• Information security management scope (ISO/IEC 27001), overlaps but is not identical (the ISMS may cover a wider or narrower footprint than the BCMS; the two should be reconciled).
• Regulatory perimeter, the RBI RE perimeter, the SEBI RE perimeter, the IRDAI insurer perimeter are regulatory definitions; the BCMS scope operates within these but is not bounded by them.
• Corporate boundary, a corporate group's full legal-entity tree is a corporate-finance artefact; the BCMS scope covers the subset of those entities that the BCMS will manage continuity for.
• Contract perimeter, customer contracts may reach outside the BCMS scope (e.g., DORA flow-down from an EU bank customer reaches into the SaaS firm's sub-processors); the BCMS scope must acknowledge and manage these even when the activity is delivered from outside the BCMS boundary.

By organisation size

The mechanics of 4.3 scale with organisation size:

• Small (10 to 50 staff), a single Scope Statement (2 to 4 pages), a single scope diagram, a short inclusion/exclusion table. The whole 4.3 cycle is achievable in 3 to 5 weeks of part-time effort.
• Growing companies (50 to 250 staff), a 4- to 8-page Scope Statement, an inclusion table covering all products/services/sites, an exclusion table with rationale, a dependency map and a scope diagram. 4 to 8 weeks of cross-functional effort; usually owned by the BCM Lead with executive sponsorship.
• Mid-market (250 to 2,000 staff), a 10- to 20-page Scope Statement, regulator-by-regulator scope annexures (RBI/SEBI/IRDAI/DORA), entity-level scope matrix for groups, a live dependency map maintained in the CMDB or GRC platform. 8 to 14 weeks; usually a BCM Lead with a 4 to 6 person scope working group.
• Enterprise (2,000+ staff), a Scope Statement set (master + per-business-unit annexures + per-geography annexures + per-regulator annexures), an integrated dependency map covering legal-entity, infrastructure, IT, supplier and people dependencies, scope-change governance through a Clause 6.3 change-management process, and a scope-attestation cycle for each business unit head. 3 to 6 months for first cycle; a permanent scope-governance function thereafter.

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

The scope signature varies sharply by industry:

• BFSI, regulator-driven scope boundaries (RBI RE, SEBI MII, IRDAI insurer), dense customer-contract perimeter, critical third-party dependencies (NPCI, payment switches, credit bureaus).
• Healthcare, patient-safety scope dimension, clinician-privilege scope, hospital-data scope (DPDP SDF for hospitals handling large patient datasets).
• IT/ITeS and SaaS, enterprise-customer contractual perimeter, cross-border regimes (DORA/CPS 230/MAS TRM/HKMA OR-2), SaaS-on-SaaS dependencies.
• Manufacturing (especially chemical), physical-site scope (NDMA Chemical Disaster Guidelines, State PCB), multi-plant scope, OT/IT scope boundary.
• Government/PSU, departmental scope, RTI transparency, multi-departmental dependencies.

Key Definitions and Terminology

Clause 4.3 turns on a small set of terms whose precise meaning an auditor will test. Definitions below reconcile ISO 22300:2021 vocabulary with Indian regulatory usage.

• Scope, the boundary of the BCMS: what the management system covers (entities, products, services, locations, activities, supplier interfaces) and what it does not. The scope is the answer to the question "what is the BCMS managing the continuity of?".
• Boundary, the line that separates in-scope from out-of-scope. A boundary is well-drawn if a reasonable third party (an auditor, a customer, a regulator) can determine unambiguously, for any given activity, whether it is inside or outside.
• Inclusion, an explicit decision to bring a candidate (entity, product, service, location, activity, supplier) inside the BCMS boundary.
• Exclusion, an explicit decision to leave a candidate outside the BCMS boundary, with a documented rationale. In ISO 22301 (unlike ISO 27001 Annex A), exclusions are not forbidden; they must, however, be justified and must not undermine the organisation's ability to deliver continuity outcomes for in-scope activities.
• Dependency, a relationship in which an in-scope activity relies on a person, premises, technology, information, supplier or third party (which may itself be in or out of scope) to deliver its continuity outcome. Dependencies that cross the boundary are particularly important, the BCMS must manage these even though it does not manage the out-of-scope unit.
• Interface, the point at which an in-scope activity exchanges information, materials or control with an out-of-scope unit. Interfaces are where continuity obligations flow across the boundary.
• Prioritised activity, an activity, inside the BCMS scope, that the BIA (Clause 8.2) has ranked as critical to delivery. 4.3 sets the population from which 8.2 prioritises; it does not itself prioritise.
• MBCO (Minimum Business Continuity Objective), the minimum level of delivery of an in-scope activity that the organisation commits to maintain during a disruption. 4.3 sets the population; 8.2/8.3 set MBCO per activity.
• Organizational unit, a defined part of the organisation (function, business unit, department, team) that has a distinct scope identity.
• Outsourced process / activity, an activity delivered by an external party on behalf of the organisation. Outsourcing moves the control boundary (the external party controls the day-to-day) but not the accountability boundary (the organisation remains accountable to its customer/regulator for the outcome).
• Scope drift, the gradual, undocumented expansion (or contraction) of scope between formal reviews. A common finding in growing companies that have acquired or divested entities without updating the Scope Statement.
• Scope annexure, a subsidiary scope document for a particular business unit, geography, or regulator. Common in mid-market and enterprise implementations.
• Climate-driven scope input (per Amendment 1:2024), a scope consideration arising from climate change, such as flood exposure of a site, heat exposure of a workforce, water dependence of a process, or climate vulnerability of a supply chain. Not a separate sub-clause; woven into 4.1/4.2/4.3.
• RTO (Recovery Time Objective) and RPO (Recovery Point Objective), defined per in-scope prioritised activity in Clause 8.2; not by 4.3 itself, but 4.3 determines the population over which they are defined.
• MTPD (Maximum Tolerable Period of Disruption), same concept as the legacy MAO label; ISO 22301:2019 prefers MTPD. APRA CPS 230 paragraph 38 codifies the regulatory equivalent ("tolerance for the maximum period of disruption"). MTPD is set in 8.2 for each in-scope activity.

Relationship to Other Clauses and Frameworks

Inside ISO 22301:2019

4.3 is the keystone of the Clause 4 trilogy (4.1 → 4.2 → 4.3) and the foundation for the entire PDCA loop that follows:

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

Clause 4.3 has direct equivalents in every major BCM and operational-resilience framework:

• ISO/IEC 27001:2022 Clause 4.3, same concept for the ISMS. Integrated ISMS+BCMS organisations reconcile the two scopes into one Statement of Applicability + Scope Statement.
• NIST SP 800-34 Rev 1 (May 2010), the seven-step contingency planning process begins with a system-boundary scoping decision for each Information System Contingency Plan. ISO 22301's 4.3 is the organisation-wide equivalent; NIST is system-centric, ISO is organisation-centric, bridge both when mapping.
• FFIEC BCM Booklet (November 2019), the BCM Booklet's "governance and accountability" principle requires a clear statement of what the BCM programme covers; functionally equivalent to ISO 4.3.
• DORA (Reg EU 2022/2554, applies 17 January 2025), Article 4 (scope) plus Article 6 (ICT risk-management framework) and Article 11(5) (BIA) together impose a scope-like discipline on in-scope financial entities and their ICT third-party providers. Note: there is no "June 2025 DORA date"; the mid-2025 prudential date is APRA CPS 230 (1 July 2025).
• APRA CPS 230 (effective 1 July 2025), paragraph 8 requires an operational-risk-management framework whose scope covers all the activities of the regulated entity; paragraphs 47 to 60 extend scope-related obligations to service-provider arrangements.
• MAS TRM Guidelines (18 January 2021), board-approved TRM framework with explicit scope.
• HKMA OR-2 / TM-G-2 (31 May 2022), OR-2 introduces an operational resilience scope that explicitly includes important business services, going beyond traditional BCP scope.
• NIST CSF 2.0 (26 February 2024) Govern function, GV.OC organisational context and GV.SC supply chain scope considerations overlap ISO 4.3.

The full bidirectional crosswalk with clause/article/paragraph numbers is in Section 16.

Detailed Implementation Guidance, The Worked Scope Determination

This section is the practitioner core of the guide. It describes a ten-step method that takes a growing company from "the BCMS covers the company" to a defensible, audit-ready, scope-governed Statement. The method is the same one Singahi uses in its 4.3 implementation sprints; the artefacts produced at each step map to the toolkit documents in Section 19.

Step 1, Inputs and pre-work (the 4.1 + 4.2 inputs)

Before drawing the boundary, gather the upstream artefacts that 4.3 must respond to. Without these, scope is opinion, not analysis.

• 4.1 Context analysis, the internal and external issues that affect the organisation's ability to deliver. Each material issue is a candidate scope input. For example, "Chennai delivery-centre concentration" (internal location issue) suggests that the Chennai site is a scope candidate that needs explicit in/out treatment; "monsoon flood exposure" (external climate issue) makes the same site a climate-driven scope input under Amendment 1:2024.
• 4.2 Interested-party register and obligations tracker, the legal, regulatory, contractual and other requirements captured in 4.2. Every obligation is a scope driver: the BCMS must cover the activity that the obligation applies to. A RBI RE has to scope its IT Service Continuity programme under the Master Direction IT Governance; a SEBI MII has to scope its Near Site + DRS architecture under SEBI BCP-DR for MIIs; an insurer has to scope its board-approved BCP/DR under IRDAI 2023; every Indian entity with ICT operations has to scope its CERT-In compliance horizontally.
• Org chart and legal-entity register, from the Company Secretary. The complete list of legal entities, branches, JV partners and captive subsidiaries, with PAN/GST/CIN/sectoral-licence identifiers.
• Product and service catalogue, from Strategy/Product/Ops. The complete list of products and services the organisation offers, with revenue, customer count and criticality where known.
• Location register, from Facilities. Every physical and virtual location (offices, data centres, co-location, cloud regions, recovery sites), with hazard exposure (flood zone, seismic zone, chemical-MAH proximity, single-source power).
• Procurement / supplier register, from Procurement. Every supplier with annual spend, criticality, concentration and contract-renewal date.
• Customer register, from Customer Success/Sales. Every enterprise customer with contractual BCM clauses, sector (BFSI/healthcare/government customers impose their own scope), and cross-border reach (DORA flow-down, APRA CPS 230 flow-down).
• Regulatory register, from Legal/Compliance. Every applicable Indian instrument and any cross-border regime.

The pre-work produces a scoping pack, a single briefing document the scope workshop uses. Allow one to two weeks for a growing company; three to four weeks for mid-market; eight to twelve weeks for a multi-entity enterprise.

Step 2, The scope workshop (in/out decisions)

Convene a half-day to two-day workshop (depending on organisation size) with cross-functional representation: BCM Lead (facilitator), executive sponsor, Strategy, Legal, Compliance, Risk, IT, CISO, Operations, HR, Procurement, Facilities, Customer Success, and (for groups) Company Secretary. Use the scoping pack to walk through every candidate (entity, product, service, location, activity, supplier, customer) and record an explicit in/out decision with rationale.

The workshop's discipline is naming the candidates before deciding them. Two anti-patterns to avoid:

• The "whole company" shortcut, "the BCMS covers the whole company" is not a scope, it is an aspiration. It avoids the in/out discipline and reliably produces a Stage 1 finding. Even if the eventual answer is "the whole company", the workshop must walk every candidate to confirm no silent exclusions.
• The "the auditor will tell us" deferral, deferring scope decisions to the Stage 1 auditor surrenders control of the certification outcome. The auditor's job is to test the scope, not to draft it.

The workshop output is a candidate register, a single spreadsheet with one row per candidate, columns for: candidate name, type (entity/product/service/location/activity/supplier/customer), in/out decision, rationale, owner, dependencies (named), interfaces (named), and the 4.1/4.2 inputs that drove the decision. A growing company typically produces 60 to 150 candidates; a growing firm 200 to 500; an enterprise 1,000+.

Step 3, The inclusion logic

For each "in" candidate, document why it is in scope. Five in-justifications cover the vast majority of cases:

1. Regulatory inclusion, the candidate is subject to a captured obligation (4.2). Example: the core banking platform is in scope because the RBI MD IT Governance requires IT Service Continuity over critical systems.
2. Customer-contract inclusion, the candidate underpins a contractual SLA. Example: the payment-switch integration is in scope because enterprise-customer contracts require payment availability.
3. Criticality inclusion, the candidate is one of the organisation's prioritised activities (a candidate, formally prioritised in 8.2). Example: the SaaS subscription platform is in scope because it is the primary revenue-generating activity.
4. Dependency inclusion, the candidate is a critical dependency of an in-scope activity. Example: the SMS gateway is in scope (as a managed dependency) because multi-factor authentication depends on it.
5. Lifecycle inclusion, the candidate crosses the boundary of the management system (e.g., an outsourced activity) and must be managed under Clause 8.1.

Step 4, The exclusion logic (and its red lines)

For each "out" candidate, document why it is out of scope. Five out-justifications cover most cases:

1. Low-impact exclusion, the candidate's disruption would not cause unacceptable impact. Must be supported by BIA-grade evidence, not assertion. "Low impact" without numbers is a finding.
2. Parent-company coverage, the candidate is covered by another management system (the parent's BCMS, an ISO 9001 QMS, a separate ISMS). Must name the covering system and evidence its existence.
3. Distinct risk profile, the candidate has a materially different risk profile from the rest of the in-scope business (e.g., a small experimental product line with no critical customers).
4. Newly-acquired but not yet integrated, a recently acquired entity whose integration is in progress and whose scope-inclusion will be done at a defined future milestone. Must be time-bound and re-confirmed at each cycle.
5. Outsourced but contractually bounded, the candidate is delivered by an external party under a contract that places continuity responsibility on the external party. The out-of-scope decision here does not remove the dependency-management obligation under Clause 8.1, it just clarifies who runs the day-to-day.

Three red lines, exclusions that almost always generate Stage 1 findings and should be avoided:

• Excluding a personal-data processing activity. DPDP Act 2023 Section 8(5) makes availability of personal data a statutory duty; an out-of-scope personal-data processor that fails creates a Section 8(6) breach notification duty. The BCMS scope must include (or formally manage via 8.1) every material personal-data processing activity.
• Excluding a revenue-critical product because "it never goes down". "It never goes down" is a BIA assertion, not a scope decision; the absence of past failure is not evidence of future resilience. The candidate belongs in scope and in the BIA.
• Excluding a regulator-defined critical function. For RBI REs, the Master Direction's critical-systems classification is scope-binding. For SEBI MIIs, the MII BCP-DR critical systems are scope-binding. For IRDAI insurers, the board-approved BCP/DR scope is binding. The BCMS cannot exclude what the regulator has scoped in.

Step 5, The dependency map

For every in-scope activity, map its dependencies across six dimensions (the BCM "PESTIS" framing, People, Premises, Technology, Information, Suppliers, stakeholders):

The dependency map is what surfaces the silent dependencies, the out-of-scope units on which in-scope activities depend. These silent dependencies are the single most common cause of BCMS failure on the day; they are also the single most common Stage 1 finding. The TantraSoft SaaS illustrative scenario in Section 14 traces exactly this failure mode.

Step 6, The scope diagram

Draw the BCMS boundary. A scope diagram is not optional flourish; it is the visual artefact that forces precision in the boundary. A clean scope diagram contains:

• The boundary itself, a clear line (or shape) enclosing what is in scope.
• The in-scope units inside the boundary, labelled (entities, products, services, locations, prioritised activities).
• The out-of-scope units outside the boundary, labelled, with a short justification tag.
• The cross-boundary dependencies as arrows crossing the boundary, each arrow labelled with the dependency (e.g., "customer authentication flow → out-of-scope captive IDP").
• The regulatory overlays as a parallel layer (the RBI RE boundary, the SEBI MII boundary, the DPDP SDF boundary) showing how regulatory scope interacts with BCMS scope.
• The climate overlay under Amendment 1:2024, hazard exposure of in-scope locations (flood zone, heat zone, single-source power).

Tools for the diagram range from PowerPoint/Draw.io for small firms through Visio/Lucidchart for mid-market to GRC-platform-hosted scope diagrams for enterprise. The diagram does not have to be a work of art; it has to be unambiguous.

Step 7, The Scope Statement (the documented artefact)

The Scope Statement is the canonical 4.3 document. It is the artefact the auditor reads first; it is the artefact referenced by the BCM Policy, the BIA, the strategies, the plans, the exercises and the audit/review cycles. A defensible Scope Statement contains eight sections:

1. Identification, issuing organisation, document owner, approval date, version, classification, refresh date.
2. Purpose, one paragraph: "This Statement defines the scope of [Organisation]'s BCMS as required by ISO 22301:2019 Clause 4.3."
3. Scope determination inputs, explicit citations to the 4.1 context analysis and 4.2 interested-party/obligations analysis that drove the boundary. The Statement traces its own provenance.
4. In-scope, a structured enumeration: legal entities, business units, products and services, locations (physical and virtual), prioritised activities (named or referenced), supplier interfaces (named or referenced). Tables, not prose.
5. Out-of-scope, a structured enumeration with rationale for each exclusion. Tables, not prose.
6. Dependencies and interfaces, the cross-boundary dependencies, the interfaces, and the continuity obligations that flow across them.
7. Climate considerations (Amendment 1:2024), a short subsection documenting the climate-driven scope inputs considered and the resulting scope decisions.
8. Governance, approval authority (top management), review cadence (annual + event-triggered), change-control process (linkage to Clause 6.3), and reference to subsidiary scope annexures (where applicable).

A growing company Scope Statement is typically 4 to 8 pages; a mid-market one 10 to 20; an enterprise master Scope Statement 15 to 30 with annexures running to hundreds of pages.

Step 8, Wiring scope into the downstream BCMS

The Scope Statement is not a deliverable to be filed; it is the operating envelope for the rest of the BCMS. After top-management approval, explicitly wire the scope into:

• The BCM Policy (Clause 5.2), references the Scope Statement.
• The risk register (Clause 6.1), every BCMS risk must be associated with an in-scope activity.
• The objectives (Clause 6.2), every BCMS objective is scoped.
• The resources plan (Clause 7.1), resourced within scope.
• The BIA (Clause 8.2), covers every in-scope prioritised activity; the BIA scope equals the BCMS scope (no BIA "orphans").
• The strategies (Clause 8.3), selected for in-scope activities.
• The plans (Clause 8.4), cover in-scope activities and cross-boundary interfaces.
• The exercise programme (Clause 8.5), samples in-scope scenarios.
• The audit and review cycles (Clauses 9.2 and 9.3), test scope continuing suitability.

A clean test of wiring: ask "for each in-scope activity, is there a BIA row, a strategy, a plan, an exercise, and an audit trail?". Any in-scope activity without this chain has a wiring gap.

Step 9, Top-management approval and communication

The Scope Statement is approved by top management, for a growing company, typically the CEO/COO/CRO; for a growing firm, the executive committee with board endorsement; for an enterprise, the board or board risk committee. The approval is not a formality: it is the act by which the organisation commits the BCMS resource envelope.

After approval, communicate the scope:

• Internally, to every function in scope (so they know they are in), to every out-of-scope unit (so they know they are out, and what their interface obligations are), to the BCM team, and to internal audit.
• Externally, to the certification body (as part of the certification application), to enterprise customers with BCM clauses, to material suppliers, and (where relevant) to regulators via existing compliance returns. The Statement is not automatically public, it is shared on a need-to-know basis under appropriate confidentiality.

Step 10, The scope-governance cycle (refresh)

Scope is not a one-shot decision; it is a managed object. The refresh cadence combines:

• Annual full review, every cycle, re-walk the candidate register, re-validate in/out decisions, update the dependency map, re-issue the Scope Statement.
• Quarterly scope-change scan, check for events that would resize scope (new product, sunset product, new customer with BCM clauses, new supplier, new geography, new regulation).
• Event-triggered scope review, fire immediately on:
  • M&A (acquisition brings a new entity into the corporate boundary; divestiture takes one out).
  • New or amended regulation (DPDP Rules amendment, RBI circular, SEBI circular, IRDAI circular, cross-border regime change).
  • New geography (entry into a new state, country, or regulator's perimeter).
  • Material incident or exercise finding (the post-incident review identifies a silent dependency that must be brought into scope).
  • Climate event or new climate scenario (Amendment 1:2024, a flood, heatwave, or new climate-impact assessment that changes the location's exposure profile).
  • Strategic pivot (a new product line, a sunset of a legacy business, a business-model change).

Each scope change is logged, justified, approved by top management (per the change-control process defined in the Statement's governance section), and reflected in the downstream BCMS artefacts.

Pitfalls inside the worked method

The most common pitfalls, named so they are avoidable:

• The "scope = corporate" conflation. Drawing the BCMS boundary at the corporate-legal boundary rather than at the activity boundary. Continuity is an activity property, not a legal-entity property.
• The silent exclusion of the captive. A captive IT/BPO subsidiary excluded from scope without analysis. Almost always wrong; the captive is usually a critical dependency.
• The "outsource and forget" error. Treating outsourced activities as automatically out-of-scope. Outsourcing moves the control boundary, not the accountability boundary, Clause 8.1 still applies.
• The unfounded "low impact". Excluding activities as low-impact without BIA evidence. The exclusion must be supported by the BIA, not the other way round.
• The scope drift over years. An organisation that has acquired three companies since its last scope review but still operates on the original Scope Statement. Scope drift is the most common enterprise finding.
• The unstated climate exposure. A blanket "climate is not material" without analysis, post-Amendment 1:2024. Not defensible; the analysis must be shown even where the conclusion is no-change.
• The regulatory-perimeter confusion. Assuming the BCMS scope equals the RBI RE or SEBI MII perimeter. The two are related but distinct; a multi-regulator group has to reconcile them.
• The diagram-less Statement. A Scope Statement without a scope diagram. Prose-only scopes are routinely misread by both internal stakeholders and auditors.

Tools, Technologies, and Solutions

The tooling stack for 4.3

4.3 tooling falls into four categories:

• GRC / BCM platforms, host the Scope Statement, the inclusion/exclusion log, the dependency map and the scope-governance workflow. Several global GRC platforms have Indian sales, support, and implementation-partner presence in Bengaluru, Mumbai, Pune, and Hyderabad (and one in Mangalore). Indicative licensing: ₹4,000 to ₹12,000 per user per month for mid-market tiers; enterprise pricing is custom. Your procurement team should run a category-level RFP; vendor selection is beyond this guide.
• CMDB / asset-management systems, feed the dependency map (every configuration item, application, server, cloud resource is a node; relationships are dependencies). ITSM-platform CMDB, discovery and asset tool, network-mapping tool, IT-service-intelligence tool, native AWS/Azure/GCP config graphs.
• Diagramming tools, for the scope diagram and dependency map. Draw.io (free), Lucidchart (~₹800 to ₹2,500 per user per month), Microsoft Visio (one-time per user), Miro (collaborative).
• Regulatory-content feeds, for the scope-change scan. Indian regulatory-content services (Legal-era-style aggregators), sector-specific (RBI/SEBI/IRDAI notification feeds), DORA/CPS 230/MAS TRM/HKMA monitoring for cross-border. Indicative ₹1.5 to ₹6 lakh per year for a mid-market subscription.

The "buy vs build" question for growing companies

A growing company does not need a GRC platform to do 4.3 competently. The minimal viable stack is:

• The Scope Statement, a Markdown/Word document with version control (Git or a SharePoint/Drive folder with a clear naming convention).
• The inclusion/exclusion log, a spreadsheet.
• The dependency map, a spreadsheet for the data, plus a one-page diagram in Draw.io or PowerPoint.
• The scope-change workflow, a ticketing system (issue-tracking tool/project-tracking tool/project-management tool/issue tracker) with a "scope change" ticket type.

This stack carries most growing companies to maturity Level 3 (Section 22). GRC platform investment becomes worthwhile when the organisation hits Level 4, when the dependency map needs to be live-fed from CMDB and procurement data, when scope-change governance needs auditable workflows, when multiple scope annexures need to be maintained across business units, or when the certification body is asking for evidence-grade traceability.

What tooling cannot do

Tooling automates the bookkeeping; it does not make the scope decisions. The most common tooling-driven failure is a GRC platform populated with a Scope Statement that no one has pressure-tested in a workshop. The platform produces a beautifully formatted, internally inconsistent, silently over-scoped Statement. The scope workshop (Step 2 of the method) is not a tooling step, it is a judgement step and must be done by people.

Policy and Procedure Templates

This section previews the templates in the toolkit (Section 19 lists them; the toolkit itself contains the full documents). Each template is Singahi's own drafting, ready to customise; sample "shall" language is illustrative, not a copy of any standard's text.

The BCMS Scope Policy

A short top-management-issued policy that:

• States the organisation's commitment to maintaining a documented, justified, and continually reviewed BCMS scope per ISO 22301:2019 Clause 4.3.
• Names the BCM Lead as the scope owner, accountable to the executive sponsor.
• Requires the scope to be determined on the basis of the Clause 4.1 context and the Clause 4.2 interested-party/obligations analyses.
• Requires explicit in/out decisions for every candidate with documented rationale.
• Requires cross-boundary dependencies to be mapped and managed under Clause 8.1.
• Requires the scope to be reviewed annually and on event-trigger (M&A, new regulation, new geography, material incident, climate event per Amendment 1:2024).
• Includes sample "shall" drafting: "The BCM Lead shall maintain the BCMS Scope Statement as documented information. The executive sponsor shall approve the Scope Statement and any subsequent material change. Functions responsible for in-scope activities shall cooperate with the scope-governance cycle."

The Scope Determination Procedure

The operating procedure that operationalises the ten-step method of Section 7. It defines:

• Inputs (the 4.1 and 4.2 artefacts, the registers from Step 1).
• The scope workshop composition and quorum.
• The candidate register structure.
• The in/out decision criteria.
• The dependency-map structure and update cadence.
• The scope-diagram standard.
• The Scope Statement structure.
• The top-management approval workflow.
• The scope-change governance workflow (scheduled and event-triggered).
• The communication plan (internal and external).

The BCMS Scope Statement

The canonical 4.3 artefact (Section 7.7 lists its eight sections). The toolkit's template includes placeholder text and worked examples for a representative Indian SaaS company, ready to customise.

The Inclusion/Exclusion Log

A structured register (one row per candidate) with: candidate name, type, in/out, rationale, supporting evidence reference (BIA row, contract clause, regulation citation), owner, last-reviewed date, next-review date.

The Dependency Map

The PESTIS-structured dependency register (Section 7.5) plus the one-page visualisation.

The Scope Diagram

A template (Draw.io and PowerPoint formats) with the in-scope/out-of-scope/cross-boundary structure pre-drawn; the organisation fills in its own units.

The Scope Change Log

A change-by-change record (one row per change) with: change ID, trigger, date raised, requested by, impact summary, decision (approved/deferred/rejected), decision rationale, approver, decision date, implementation actions, downstream-artefact updates, implementation verification date.

Integration with the BCM Policy, BIA, Strategy, and Plans

The Scope Statement is referenced from the BCM Policy (5.2); it sets the population for the BIA (8.2), the strategies (8.3), and the plans (8.4). The templates in the toolkit are designed to be cross-referenced so a change in scope propagates cleanly to the downstream artefacts.

Risk Assessment and Treatment

The 4.3-to-6.1 bridge

Clause 4.3 does not assess risks (that is Clause 6.1), but it generates them. Every scope decision is a risk decision:

• An in-scope inclusion generates the obligation to manage continuity for that activity (which consumes resources; the residual risk is under-resourcing).
• An exclusion generates the risk that the excluded activity will fail and affect in-scope activities (silent-dependency risk).
• An outsourced activity's out-of-scope decision generates concentration risk and supplier-continuity risk.

The 4.3 cycle feeds these as risk seeds into the Clause 6.1 risk register. The BCM Lead is responsible for raising these risk seeds; the Risk function is responsible for rating and treating them.

Treatment patterns

Five treatment patterns cover most scope-sourced risks:

1. Bring into scope, if the excluded activity is genuinely material, the right treatment is to widen scope. Common improvement action in maturing organisations.
2. Manage as a dependency under Clause 8.1, for outsourced activities that cannot practicably be brought in scope, manage them as dependencies (supplier-BCP clauses, exit plans, right of audit, secondary supplier).
3. Reduce dependency, if a single supplier is the silent dependency, diversify (secondary contract, in-sourcing of a small fallback capability).
4. Transfer, insure against the residual impact (cyber-insurance, business-interruption cover). Insurance does not remove the BCMS obligation; it cushions the financial impact.
5. Accept with documented justification, for low-impact candidates, document the acceptance with BIA evidence and re-test at the next review.

Risk-assessment cadence

Scope-sourced risks are re-assessed:

• Annually, with the full scope review.
• Quarterly, with the scope-change scan.
• Event-triggered, on M&A, new regulation, new geography, material incident, climate event.

Audit and Compliance Checklist

Below are 27 questions the certification auditor is likely to ask during the Stage 1 and Stage 2 audit of Clause 4.3. Use them as a self-assessment before the audit. For each question, the expected evidence and a red-flag indicator are noted.

1. Is the BCMS Scope Statement available as documented information? Expected: a controlled document with version history, approval, classification. Red flag: only a paragraph inside the BCM Policy.
2. Does the Statement name the legal entity (or entities) covered? Expected: explicit entity names with CIN/PAN/GST. Red flag: "the company" without naming.
3. Does the Statement name every in-scope product and service? Expected: a structured catalogue with criticality. Red flag: "all products".
4. Does the Statement name every in-scope location (physical and virtual)? Expected: office, DC, DRS, cloud regions. Red flag: no DC or cloud regions named.
5. Does the Statement name every in-scope prioritised activity (or reference the BIA)? Expected: cross-reference to the BIA scope.
6. Does the Statement name every material supplier interface? Expected: a supplier-interface sub-section. Red flag: no supplier interface.
7. Does the Statement justify every exclusion? Expected: an exclusion table with rationale column. Red flag: no exclusions, or exclusions without rationale.
8. Are excluded activities supported by BIA-grade evidence? Expected: a BIA row for each excluded activity that demonstrates low impact. Red flag: assertion only.
9. Does the Statement map cross-boundary dependencies? Expected: a dependency map (PESTIS-structured). Red flag: no dependency map.
10. Are outsourced activities managed under Clause 8.1 even where out of scope? Expected: supplier-BCP clauses, exit plans, right-of-audit clauses in supplier contracts. Red flag: out-of-scope = out-of-mind.
11. Does the Statement cite the 4.1 context analysis as an input? Expected: explicit citation in the inputs section.
12. Does the Statement cite the 4.2 interested-party/obligations analysis as an input? Expected: explicit citation, plus the regulatory obligations named.
13. For regulated entities, does the Statement reconcile BCMS scope with the regulator's perimeter? Expected: RBI RE / SEBI MII / IRDAI scope annexure. Red flag: silence on regulatory scope.
14. For groups, are the entity boundaries explicit? Expected: entity-by-entity in/out. Red flag: "group-wide" without entity enumeration.
15. For cross-border operations, are the cross-border regimes captured? Expected: DORA, APRA CPS 230, MAS TRM, HKMA OR-2 as applicable. Red flag: silence on cross-border.
16. Is there a scope diagram? Expected: a visual, in the Statement or as an annexure. Red flag: no diagram.
17. Does the diagram show cross-boundary dependencies as labelled arrows? Expected: arrows with named dependencies.
18. Does the diagram show regulatory overlays? Expected: RBI/SEBI/IRDAI perimeters as parallel layers.
19. Under Amendment 1:2024, are climate-driven scope inputs documented? Expected: a climate-considerations subsection. Red flag: silence on climate post-Feb-2024.
20. Are climate-exposed in-scope locations identified? Expected: flood zone, heat zone, single-source power, chemical-MAH proximity.
21. Was the Statement approved by top management? Expected: a signed approval page, or board/exec-committee minute reference.
22. Is there a defined scope-change governance workflow? Expected: a documented workflow tied to Clause 6.3.
23. Is the scope-change log current? Expected: a log with every change since the last Statement version. Red flag: no log, or stale log.
24. Are scope changes propagated to the downstream artefacts (BCM Policy, BIA, strategies, plans)? Expected: traceable updates. Red flag: scope changed but BIA unchanged.
25. Are in-scope units aware they are in scope? Expected: awareness training records, communication evidence. Red flag: business-unit heads surprised to be in scope.
26. Are out-of-scope units aware of their interface obligations? Expected: communication evidence. Red flag: out-of-scope units doing whatever they want.
27. Has the Statement been reviewed in the last 12 months? Expected: a current version date. Red flag: a Statement older than 12 months regardless of changes.

A scoring rubric for self-assessment: 24 to 27 satisfied = audit-ready (L4 maturity); 18 to 23 = minor findings likely (L3); 12 to 17 = major findings likely (L2); below 12 = Stage 1 delay probable (L1).

Metrics and KPIs

Clause 4.3 generates measurable process and outcome indicators. The 14 KPIs below are the working set for a defensible 4.3 programme.

Process KPIs

1. Scope Statement currency, months since last formal review. Target: ≤ 12.
2. In-scope coverage traceability, per cent of in-scope activities with a complete BIA + strategy + plan + exercise chain. Target: 100%.
3. Exclusion evidence coverage, per cent of exclusions with BIA-grade evidence. Target: 100%.
4. Dependency-map completeness, per cent of in-scope activities with all six PESTIS dimensions mapped. Target: 100% for critical activities; ≥ 80% overall.
5. Scope-change cycle time, median days from event trigger to scope-decision. Target: ≤ 30 days.
6. Scope-change propagation, per cent of scope changes propagated to all downstream artefacts within 60 days. Target: 100%.
7. Top-management approval latency, median days from Statement draft to top-management sign-off. Target: ≤ 21 days.
8. Out-of-scope interface-control coverage, per cent of cross-boundary interfaces with documented continuity obligations and a named owner on each side. Target: 100%.

Outcome KPIs

9. Silent-dependency findings per audit, count of in-scope activities discovered to depend on undocumented out-of-scope units. Target: 0.
10. Scope-related nonconformities, count of NCs (major + minor) raised by internal or external audit against Clause 4.3. Target: 0 major; ≤ 1 minor.
11. Scope-gap incident count, count of business disruptions where the root cause traced to an out-of-scope unit silently affecting in-scope delivery. Target: 0.
12. Regulator-perimeter reconciliation status, count of regulators whose perimeter is unreconciled with the BCMS scope. Target: 0.
13. Climate-scope review completion (Amendment 1:2024), binary: completed / not completed in the current cycle. Target: completed.
14. Scope-explanation accuracy, per cent of internal stakeholders who, when asked "what is in scope for the BCMS?", can describe it accurately. Target: ≥ 90% for executives; ≥ 75% across all in-scope staff.

Dashboard sample

A monthly 4.3 dashboard for the BCM Steering Committee includes: KPIs 1, 2, 4, 9, 10, 11 with trend lines; scope-change events in the period; the next scheduled review date; and any open findings. A quarterly board pack adds KPIs 6, 8, 12, 14 and a one-page narrative on scope evolution.

Common Pitfalls and Audit Failures

The 12 anti-patterns below are the most common reasons Clause 4.3 generates findings. They are named (with a short memorable label) so the BCM team can scan for them.

1. The "Whole Company" Shortcut. "The BCMS covers the whole company" with no candidate register, no inclusion/exclusion, no dependency map. Generates an immediate Stage 1 finding.
2. The Silent Subsidiary. A captive subsidiary excluded from scope without analysis, usually because "it's small" or "the parent covers it". Almost always wrong; the captive is usually a critical dependency.
3. The Outsource-and-Forget. Outsourced activities treated as out-of-scope without Clause 8.1 dependency management. Generates a finding even where the scope decision itself is defensible.
4. The Unfounded Low-Impact. Activities excluded as low-impact without BIA evidence. The exclusion must be supported by the BIA, not asserted.
5. The Stale Statement. A Scope Statement more than 12 months old, with multiple M&A events or regulatory changes unreflected. Generates both a Clause 4.3 finding and a Clause 6.3 finding.
6. The Diagram-less Statement. A Statement with no scope diagram. Auditors ask for the visual; its absence suggests the boundary has not been thought through.
7. The Climate-Blind Statement. A Statement with no climate-considerations subsection post-Amendment 1:2024. Generates a finding even where climate is genuinely immaterial, the analysis must be shown.
8. The Regulatory-Perimeter Conflation. The Statement assumes BCMS scope equals the regulator's perimeter. For a multi-regulator group, the perimeters differ.
9. The BIA Orphan. A BIA that covers activities not in the Scope Statement. The BIA scope must equal the BCMS scope.
10. The Plan-Plan Mismatch. Plans covering activities that are out of scope, or missing activities that are in scope.
11. The Wiring Gap. A Statement that exists in isolation, not referenced from the BCM Policy, not reflected in the BIA, not driving the exercise programme.
12. The Out-of-Scope Black Hole. Out-of-scope units with no interface owners, no continuity obligations, and no awareness they are out of scope. The boundary exists on paper only; on the day, no one knows what to do.

Illustrative Scenario 1: Failure, TantraSoft SaaS (Illustrative)

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

The following is an illustrative scenario based on patterns observed in multiple Indian SaaS firms. TantraSoft is a composite; any resemblance to a specific firm is coincidental.

The organisation

TantraSoft Private Limited is a B2B SaaS company headquartered in Bengaluru, with development centres in Hyderabad and Pune, an overseas subsidiary in Singapore (for APAC customer contracting), and a captive analytics subsidiary (TantraSoft Analytics Private Limited) in Chennai. Headcount 600; FY24 revenue ₹185 crore; 84 enterprise customers across India, the Middle East and South-East Asia.

The 4.3 posture at T-9 months

TantraSoft decided to pursue ISO 22301 certification in FY24. The BCM Lead drafted a Scope Statement (4 pages) that read, in essence: "The BCMS covers TantraSoft Private Limited and its enterprise SaaS subscription platform, including the Bengaluru HQ, Hyderabad and Pune development centres, and the AWS Mumbai region production environment." Key features of the original Statement:

• The Singapore subsidiary was excluded as "out of scope, customer-contracting vehicle only".
• The Chennai analytics subsidiary was excluded as "out of scope, recently acquired, separate management system".
• AWS Mumbai was named; the secondary AWS Hyderabad region used for some workloads was not.
• The customer-facing analytics dashboard (a feature of the SaaS subscription platform, but data-served from the Chennai subsidiary) was implicitly in scope as part of "the SaaS subscription platform", but its dependency on the Chennai subsidiary was not mapped.
• Climate considerations were absent.
• The scope diagram was a single box labelled "TantraSoft BCMS" with no cross-boundary arrows.

The Stage 1 auditor flagged several issues but TantraSoft's executive sponsor, under pressure to deliver certification on schedule, declined to widen scope before Stage 2.

The incident (T = 0)

In early December (T = 0, the week of 4 December), record monsoon flooding hit Chennai. The TantraSoft Analytics subsidiary's primary DC (a co-location in a Chennai IT park) lost power for 31 hours; the subsidiary's on-premise analytics cluster, which served customer-facing dashboards via a nightly batch feed into the parent's SaaS subscription platform, went down. The subsidiary's own (modest) BCM plan was designed around an 8-hour outage assumption; at 31 hours, it had exhausted its UPS and its small genset was unable to refuel due to flood-affected access roads.

The parent's SaaS subscription platform stayed up (it was in AWS Mumbai), but the customer-facing analytics dashboards across 18 enterprise customers, including 4 customers in the Middle East with strict uptime SLAs, went dark. SLA breaches began to accrue at hour 4.

What went wrong, the 4.3 failures

The post-incident review (using a Clause 10.1 corrective-action framework) identified five 4.3 failures:

1. Silent dependency unmapped. The Chennai subsidiary was a critical dependency of an in-scope feature (the analytics dashboard), but the dependency was not mapped in the Scope Statement's dependency map. The parent's BCM team had no idea the dashboard would fail when the subsidiary failed.
2. Unjustified exclusion. The Chennai subsidiary was excluded as "recently acquired, separate management system" without analysis. The subsidiary had no ISO 22301 certification, no formal BCM programme, and no tested recovery beyond an 8-hour UPS. The exclusion was unsupported.
3. Outsource-and-forget variant. Even where the subsidiary was treated as a separate unit, the parent's Clause 8.1 obligation to manage the outsourced critical dependency was not met, no supplier-BCP clauses, no exit plan, no right of audit, no secondary.
4. Climate-blind scope. The Chennai location is in a known flood zone (the 2015 floods are part of the city's recent memory); the Scope Statement's silence on climate under Amendment 1:2024 was not just a documentation gap, it was a scope-input omission. A climate-aware scope would have flagged the Chennai DC as a high-exposure location requiring either (a) in-scope treatment with a tested DRS, or (b) an explicit decision to relocate the workload.
5. BIA-Plan-Exercise orphans. The parent's BIA covered the analytics dashboard as part of the SaaS subscription platform with an RTO of 4 hours, but no plan existed to recover the dashboard from a Chennai subsidiary outage, and no exercise had ever tested the cross-entity dependency.

The financial impact

• Service credits to 18 enterprise customers: ₹2.6 crore (the Middle East SLAs were particularly punitive).
• Customer churn: 3 enterprise customers did not renew (annualised revenue ₹1.1 crore).
• Remediation cost: emergency DRS for the Chennai subsidiary (₹45 lakh), consultancy to redo the 4.3 cycle properly (₹28 lakh), legal review of customer contracts (₹12 lakh).
• Certification delay: Stage 2 was deferred by 6 months pending scope remediation; re-audit fees and consultancy ₹35 lakh.
• Total direct cost: ~₹4.2 crore (excluding the cost of executive time and the reputational impact on the brand).

The post-incident 4.3 overhaul

The corrective-action plan (Clause 10.1) re-ran the full 4.3 cycle:

• The Chennai subsidiary was brought into scope as an in-scope legal entity; TantraSoft Analytics Private Limited was named in the revised Statement.
• A dependency map was built showing 47 cross-boundary dependencies, of which 11 were material (including the analytics dashboard feed).
• A climate-considerations subsection was added, identifying Chennai (flood), Hyderabad (heat), and the AWS Mumbai region (single-region concentration) as climate-exposed in-scope locations.
• The Singapore subsidiary was brought into scope as a customer-contracting vehicle with cross-border reach (APRA CPS 230 flow-down from Australian customers; MAS TRM reach).
• Supplier-BCP clauses and exit plans were put in place with the Chennai co-location provider, the cloud providers, and the analytics tooling vendors.
• The exercise programme added a cross-entity failover test (the Chennai subsidiary failing over to a Hyderabad recovery site).

Lessons (in ISO 22301 clause language)

• Clause 4.3 silent-dependency risk is the most expensive 4.3 failure mode. The Chennai subsidiary's outage cost ₹4.2 crore because the parent did not know it depended on it.
• The "recently acquired" exclusion is rarely defensible. New captives need accelerated scope integration, not deferred scope analysis.
• Climate-driven scope inputs are not a documentation formality under Amendment 1:2024; Chennai's flood exposure was a known fact that a competent scope analysis would have surfaced.
• Scope is not a Stage 1 deliverable; it is an operating envelope. The 4.3 cycle must be done properly the first time.

Illustrative Scenario 2: Success, Aravali Payments (Illustrative, with ROI)

The following is an illustrative scenario based on patterns observed in multiple Indian payment-aggregator firms. Aravali is a composite; any resemblance to a specific firm is coincidental.

The organisation

Aravali Payments Private Limited is a RBI-authorised payment aggregator headquartered in Jaipur, with a technology office in Bengaluru, a DRS in Mumbai, and a customer-support centre in Pune. Headcount 320; FY24 revenue ₹78 crore; ~12,000 merchant customers across India; ~4.3 million transactions per day at peak.

The 4.3 investment

When Aravali decided to pursue ISO 22301 certification, the BCM Lead (Priya Sharma) proposed a 4.3 cycle that was deliberately wider than the RBI MD IT Governance minimum. The argument: Aravali's real continuity risk was not in its own technology stack (which was modern and well-run) but in its dependency chain, payment switch, SMS gateway, NPCI connectivity, identity provider, cloud. Priya secured executive sponsorship for an extended scope that brought these dependencies into managed scope (not necessarily in-scope as legal entities, but in-scope as managed dependencies under Clause 8.1 with explicit inclusion in the Scope Statement's dependency map).

The 4.3 investment:

• 4.3 cycle execution (workshop, candidate register, dependency map, scope diagram, Statement drafting, top-management approval): ₹35 lakh of internal effort plus consultancy.
• Secondary SMS gateway contract (with a different vendor, in a different region, with tested failover): ₹80 lakh over 3 years.
• Secondary payment-switch integration capability (a smaller secondary switch under contract for failover): ₹1.4 crore over 3 years (annual maintenance only, the integration was a one-time capital cost in the prior year).
• DRS upgrade and live-failover exercise programme: ₹1.1 crore.

Total 4.3 + dependency investment: ₹3.65 crore over 3 years (₹1.2 crore per year).

The 4.3 implementation

The Aravali Scope Statement, after the cycle, contained:

• In-scope: the payment-aggregator platform (the core transaction processing); the merchant-onboarding workflow; the customer-support function; the in-house fraud-monitoring service.
• Out-of-scope (with rationale): the Jaipur HQ as a workplace (work-area recovery, not platform; covered by a separate workplace recovery plan), the Pune customer-support centre's HR operations (handled by the parent HR function).
• Managed dependencies (under Clause 8.1): the primary payment switch (a regulated PSP, not a TantraSoft-style captive but a separate RBI-regulated entity), the primary SMS gateway, NPCI for UPI connectivity, the cloud provider, the identity provider, the card-network connections.
• Climate-considerations subsection: Jaipur (heat-stress summer operations), Bengaluru (flood exposure of certain low-lying areas), Mumbai DRS (flood exposure but redundant to Bengaluru), cloud-region concentration.

The scope diagram was a single page with the in-scope box in the centre, six labelled arrows out to managed dependencies, and a regulatory overlay showing the RBI RE perimeter.

The operational test, a real incident

Eighteen months after the Scope Statement was approved, the primary SMS-gateway vendor suffered a multi-day outage (the vendor had a DC fire that took both its primary and its secondary offline for ~11 days, because the secondary was in the same building, a textbook concentration failure on the vendor's side).

For Aravali, the SMS gateway is the path for OTP delivery for two-factor authentication on card and net-banking transactions. Without SMS OTP, transaction-success rates collapse.

The 4.3-cycle prepared Aravali for exactly this scenario. Within 47 minutes of detecting the gateway degradation, Aravali's BCM Lead invoked the failover playbook; traffic was routed to the secondary SMS gateway (the ₹80 lakh contract) via the pre-tested integration. Merchant-side OTP delivery recovered to ~95% within 90 minutes. Aravali's transaction-success rate, which would otherwise have collapsed to ~30% (industry data on OTP-less card flow), stayed at ~91% for the duration of the outage.

The ROI

• Avoided service credits to merchant customers: based on the success-rate delta, Aravali estimated ₹6.4 crore of avoided SLA-breach credits over the 11-day outage.
• Avoided transaction-revenue loss: ~₹2.1 crore in fees that would have been lost to failed transactions.
• Avoided RBI penal action: a payment aggregator losing OTP delivery for 11 days would have attracted RBI supervisory attention under the RBI MD IT Governance (IT Service Continuity) and the Cyber Security Framework; the avoided enforcement risk is conservatively valued at ₹1 to ₹3 crore of direct penalty plus reputational cost.
• Avoided customer churn: zero merchant churn during the outage; the prompt failover was visibly communicated to the top 200 merchants.

Total avoided cost: ₹7 to ₹11 crore against a 4.3 + dependency investment of ~₹3.65 crore over 3 years. Payback period for the 4.3 + secondary SMS contract alone (₹1.15 crore): less than one incident.

The intangible ROI

• Certification outcome: Stage 1 passed with zero major findings; Stage 2 cleared with one minor observation on exercise documentation (later closed).
• Customer-facing differentiation: the scope discipline became a sales asset, Aravali's enterprise-merchant RFP responses could credibly demonstrate continuity posture that competitors without ISO 22301 could not.
• Regulator posture: at the next RBI supervisory cycle, Aravali's BCM documentation, Scope Statement, dependency map, exercise records, was a positive supervisory signal.
• Internal culture: the 4.3 cycle, run with cross-functional rigour, established BCM as a real discipline rather than a documentation exercise; subsequent Clause 8 work (BIA, strategy, plans) was faster and better because the scope was clear.

Lessons

• Scope is a risk-cost optimisation. Aravali's wider scope (with managed dependencies) cost ~₹1 crore more than the minimum the RBI MD required, and saved ₹7 to ₹11 crore in a single incident.
• Managed dependencies under Clause 8.1 are the highest-use 4.3 decision for a payment aggregator. The SMS gateway was a small line item in the procurement budget but a single point of failure in transaction success.
• Climate + concentration analysis (the secondary in a different region) is what made the secondary SMS gateway actually useful, a secondary in the same building as the primary (which is what failed for the vendor) is theatre, not resilience.
• The Scope Statement is a sales asset, not just an audit artefact. Aravali's RFP team quoted from it directly.

Multi-Framework Mapping

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

The full crosswalk

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

How to use the crosswalk

• Build the Scope Statement from the Indian-instrument column. Start with the regulator's perimeter that binds you; widen to include all material activities and dependencies.
• Map each row to the BCMS clauses in the middle column. This is the traceability the certification auditor will check.
• Cross-check coverage against the framework rows. When an enterprise customer's audit team asks "do you map to DORA Art 4 scope?", you have the answer ready.

Implementation Roadmap

A phased 30/90/180-day roadmap to take a growing company from "scope paragraph" to a defensible, audit-ready, scope-governed BCMS.

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

• Executive sponsor identified. Usually COO/CRO/CIO. Names the BCM Lead.
• Scope of the 4.3 cycle confirmed. The whole entity, or a defined sub-scope.
• Cross-functional team identified. Strategy, Legal, Compliance, Risk, CISO, IT, Operations, HR, Procurement, Facilities, Customer Success, Company Secretary.
• Initial maturity self-assessment using the L1 to L5 rubric (Section 22).
• Scoping pack assembled (Step 1 inputs).

Phase 1, Days 1 to 30 (Foundation)

• Week 1: Step 2 scope workshop (half-day to two-day, depending on size). Output: candidate register with in/out decisions for top candidates.
• Week 2: Step 3 in-justifications and Step 4 out-justifications completed for all candidates.
• Week 3: Step 5 dependency map drafted (PESTIS-structured). Step 6 scope diagram drafted.
• Week 4: Step 7 Scope Statement drafted (sections 1 to 8).
• Day 30 milestone (M30): Candidate register, in/out decisions, dependency map, scope diagram, and draft Scope Statement ready for review.

Phase 2, Days 31 to 90 (Build)

• Month 2: Cross-functional review of the draft Statement; gaps with Clause 4.1 (context) and 4.2 (obligations) closed; climate-considerations subsection drafted; regulator-by-regulator scope annexures (where applicable) drafted.
• Month 3: Step 9 top-management approval secured. Statement communicated internally and externally (certification body, key customers, material suppliers).
• Day 90 milestone (M90): Top-management-approved Scope Statement; dependency map; scope diagram; inclusion/exclusion log; regulator annexures; communication evidence.

Phase 3, Days 91 to 180 (Operationalise)

• Month 4: Step 8 wiring, Statement referenced from the BCM Policy (5.2); risk register (6.1) updated; objectives (6.2) scoped; resources (7.1) plan updated; BIA (8.2) coverage aligned; strategy (8.3) and plan (8.4) scope confirmed; exercise programme (8.5) scope confirmed.
• Month 5: First BIA cycle under the new scope; first cross-entity exercise for material cross-boundary dependencies; scope-change log opened.
• Month 6: Internal audit (Clause 9.2) of the 4.3 cycle; management review (Clause 9.3) re-validates scope; KPI dashboard live.
• Day 180 milestone (M180): Statement wired through the BCMS; BIA coverage aligned; first cross-entity exercise completed; internal audit closed; management review completed; KPI dashboard live; first quarterly scope-change scan scheduled.

Phase 4, Days 181+ (Sustain and Improve)

• Quarterly: Scope-change scan; dependency-map refresh; out-of-scope interface owner re-confirmation.
• Semi-annually: BIA spot-check (sample in-scope activities to confirm continuing priority).
• Annually: Full 4.3 cycle; climate-considerations review (Amendment 1:2024); top-management re-approval; integration with Clause 9.3 management review.
• Event-triggered: New regulation, new customer with BCM clauses, new supplier, new geography, M&A, material incident, post-exercise finding, climate event.

Industry-specific timing notes

• BFSI: Compress Phase 1 to 3 weeks (regulator expectations already established). Align M180 with the next RBI/SEBI/IRDAI inspection cycle.
• Healthcare: Extend Phase 1 to 6 weeks (clinical-stakeholder engagement takes longer; patient-safety scope analysis is sensitive).
• Manufacturing (chemical): Compress Phase 1 to 3 weeks (NDMA / SPCB engagement is statutory, not optional). Phase 2 must include the on-site and off-site emergency plan scoping.
• Government/PSU: Extend Phase 1 to 8 weeks (multi-departmental stakeholder engagement; RTI transparency expectations).

FAQ

Q1. Does the BCMS have to cover the whole organisation? No. ISO 22301:2019 Clause 4.3 asks organizations to determine the scope of the BCMS based on 4.1 and 4.2. Partial scope is permissible where justified. The test is whether the boundary is documented, defensible, and consistent with the rest of the BCMS.

Q2. We have an ISO/IEC 27001:2022 ISMS with a defined scope. Can we reuse it for the BCMS? The two scopes overlap but are not identical. The ISMS scope is driven by information assets; the BCMS scope is driven by activities that must be recovered. For an integrated ISMS+BCMS, reconcile the two into one Statement of Applicability + Scope Statement; the BCMS scope is typically wider where it includes activities whose information assets are unremarkable but whose continuity is critical (e.g., a manual reconciliation process).

Q3. We have an acquired subsidiary. When must we bring it into BCMS scope? Immediately on acquisition, you should treat it as a candidate (Step 2 of the method) and make an explicit in/out decision with rationale. The most defensible answer is usually to bring it into managed-dependency scope (Clause 8.1) immediately, and into full in-scope within 6 to 12 months. The TantraSoft illustrative scenario in Section 14 traces what happens when this is deferred.

Q4. Can we exclude an activity as "low impact" without a BIA? No. The exclusion must be supported by BIA-grade evidence, not asserted. The BIA does not have to cover the activity in full (after all, you are excluding it), but you must have a documented basis for the low-impact determination.

Q5. We outsource our payment switch / SMS gateway / cloud. Are these in or out of scope? Out as legal entities (you do not BCM-manage another company), but in as managed dependencies under Clause 8.1. Your Scope Statement must name them in the dependency map; your supplier contracts must include BCP clauses; you must have an exit plan for each.

Q6. Under Amendment 1:2024, do we have to do TCFD-aligned climate scenario analysis for 4.3? No. Amendment 1:2024 requires that climate-driven scope inputs be considered; the depth scales with exposure. A SaaS firm with one Bengaluru office and AWS deployment needs a short climate-considerations subsection. A chemical manufacturing firm with flood-exposed sites needs a deeper analysis. The "consideration" is mandatory; the depth is risk-proportionate.

Q7. What is the difference between ISO 22301 Clause 4.3 and ISO 27001 Clause 4.3? The same concept (define the management-system scope) applied to two different management systems. 22301 scope is continuity-activity-driven; 27001 scope is information-asset-driven. Reconcile the two where you run both.

Q8. Our Stage 1 auditor said our Scope Statement was too narrow. Do we widen scope or fight the finding? Usually widen. A Stage 1 scope finding is almost always a sign that the boundary is too tight or unjustified. The cost of widening (more BIA, more strategy, more plans) is usually less than the cost of fighting the finding and re-auditing. The Aravali illustrative scenario in Section 15 shows the ROI of the wider scope.

Q9. How often should we refresh the Scope Statement? Annually (full cycle); quarterly (scope-change scan); event-triggered (M&A, new regulation, new geography, material incident, climate event per Amendment 1:2024).

Q10. Do we need a scope diagram if our scope is simple? Yes. Even a single-box diagram with no cross-boundary arrows is useful, it confirms the boundary has been thought through. A diagram-less Statement suggests the boundary has not.

Q11. Our BCM team is small. Can a single person own 4.3? For small firms (10 to 50 staff), yes, usually the BCM Lead wearing multiple hats. For growing companies (50 to 250) and above, no, the candidate register, the dependency map and the inclusion/exclusion log require cross-functional input. A single person can facilitate, but cannot substitute for, the scope workshop.

Q12. We have a captive IT subsidiary that handles our customer data. It is "small", can we exclude it? Almost certainly not. Personal-data processing is a red-line exclusion under DPDP Act 2023 Section 8(5) (availability duty). If the subsidiary's failure would breach DPDP, it must be in managed scope at minimum, and almost always in full in-scope.

Q13. Our board does not seem engaged in scope. What do we do? Anchor 4.3 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.3 as the artefact that satisfies board-level risk-oversight duties.

Q14. We are a payment aggregator. Is NPCI in our BCMS scope? NPCI is not a legal-entity scope inclusion (you do not BCM-manage NPCI). It is a critical managed dependency under Clause 8.1, your payment flow depends on NPCI's UPI rail, and the 12 April 2025 NPCI/UPI ~5-hour nationwide degradation showed the blast radius. Your Scope Statement must name NPCI as a managed dependency.

Q15. We have a DORA-in-scope EU customer. Does that change our 4.3 scope? Yes, indirectly. DORA's third-party regime (Arts 28 to 30 + Arts 31 to 44) reaches into your SaaS firm via the customer contract. Your Scope Statement should acknowledge DORA flow-down as a managed-dependency dimension; your BIA should include DORA-relevant scenarios; your IR plan should include the customer's DORA incident-reporting clock.

Industry-Specific Requirements

BFSI, banks, NBFCs, payment system operators, insurers

BFSI has the densest regulator-driven scope environment in India. A mid-market NBFC's 4.3 scope must reconcile: the RBI MD IT Governance RE perimeter; the RBI MD Outsourcing of IT Services perimeter; the Cyber Security Framework perimeter; for an insurance-broking subsidiary, the IRDAI 2023 perimeter; for an NCD programme, the SEBI perimeter; horizontally, the CERT-In perimeter; and (for serving EU customers) the DORA scope via flow-down. Each regulator's perimeter is a scope input; the Scope Statement must reconcile them.

Specific 4.3 emphasis: RBI MD IT Governance critical-systems scope; SEBI BCP-DR for MIIs scope (RTO ≤ 2 hours for critical MII systems); NPCI/UPI/RuPay as managed dependencies; DICGC continuity expectations; rating-agency and RBI Ombudsman as interested parties (Clause 4.2 input to 4.3). The HDFC Bank RBI action (2 December 2020; partial lift 17 August 2021; full lift March 2022) is the cautionary anchor, a scope that excludes the failing digital platform is a scope the regulator will not respect.

Healthcare, hospitals, pharma, medtech

Healthcare's 4.3 signature is the patient-safety dimension of scope. Scope includes clinical activities (surgery, diagnostics, medication administration) whose continuity is a life-safety property, not just a service-availability property. Hospitals' Scope Statements typically include clinical units, the e-Hospital / EHR system, the pharmacy, the lab, and the diagnostic imaging function; they exclude (with care) the research arm, the educational arm, and the non-clinical facilities. Pharma manufacturing's scope includes production lines, the quality lab, the cold chain, and the regulatory-affairs function.

Specific 4.3 emphasis: AIIMS Delhi ransomware (23 November 2022; e-Hospital down ~6 to 15 days; primary and backup servers encrypted; OPD/admissions/billing/labs reverted to paper; NIA cyberterrorism probe) is the cautionary anchor, a Scope Statement that excludes the EHR "because it is run by NIC" misses the point; the EHR is the activity whose continuity matters, regardless of who runs the infrastructure.

IT/ITeS and SaaS

IT-services and SaaS firms have the most complex 4.3 signatures because of (a) enterprise-customer BCM-clause perimeter, (b) cross-border regimes flowing through customer contracts, (c) dense SaaS-on-SaaS dependencies, and (d) multi-city delivery footprint. The Scope Statement must enumerate: in-scope services (by product line); in-scope delivery centres (by city); in-scope customers (or "all enterprise customers with BCM clauses" plus a list of named contracts); managed dependencies (cloud, identity, observability, payments, SMS, key SaaS dependencies); cross-border regimes (DORA, APRA CPS 230, MAS TRM, HKMA OR-2 as applicable).

Specific 4.3 emphasis: Chennai 2015 (Cognizant disclosed 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.3 posture enables, geo-diverse scope with cross-city failover. The Cognizant Maze ransomware (18 to 20 April 2020; SEC-filed 10-Q/10-K disclosed Q2 2020 impact of US$50 to 70 million) showed what scope gaps cost, insufficient segmentation across the federated network meant a single ransomware incident cascaded across customer systems.

Manufacturing, chemicals, automotive, electronics, pharma manufacturing

Manufacturing's 4.3 scope signature includes physical-site scope (each plant is a scope candidate), OT/IT scope boundary (the SCADA/PLC/DCS environment is scope-distinct from the ERP), and chemical-safety scope (NDMA Chemical Disaster Guidelines 2007; State PCB). For a multi-plant group, the Scope Statement typically lists each plant with its hazard exposure and a per-plant scope annexure. Chemical-industry scope must include on-site and off-site emergency plans and integrate with the District Disaster Management Plan.

Specific 4.3 emphasis: LG Polymers Visakhapatnam styrene gas leak (7 May 2020; 12 to 13 fatalities; ~2,500 to 3,000 evacuated 3 km radius; NGT interim penalty ₹50 crore under OA 73/2020; LG Chem ₹730 crore relief package; plant permanently closed) is the cautionary anchor, a Scope Statement that excluded the M6 tank's runaway-polymerisation scenario "because it was an ops issue, not a BCM issue" would not be defensible. Maruti Suzuki Manesar violence and fire (18 July 2012; Awanish Kumar Dev GM-HR killed; 91 arrested; ~₹1,400 crore lockout loss) is the workplace-violence scope dimension, BCM scope includes industrial-relations scenarios, not just fire/flood/cyber.

Government and PSU

Government departments and PSUs have a distinctive 4.3 signature: departmental scope (the department's mandate), multi-departmental dependencies (e-services depend on multiple departments' systems), RTI transparency (Scope Statements may be requestable), and integration with the National Disaster Management Plan. NDMA's 2014 DMP template for Ministries/Departments of GoI provides the canonical structure that PSU and departmental BCPs mirror.

Specific 4.3 emphasis: Mumbai 12 October 2020 blackout (cyber attribution contested between Maharashtra State Cyber Cell and the Union Power Ministry, present both positions; ~6.5 million consumers affected; restoration ~15 to 18 hours) showed the infrastructure-dependency scope dimension, for infrastructure-dependent government services, the grid's continuity is upstream of every other BC plan.

Maturity Model

The L1 to L5 maturity model for Clause 4.3 helps a growing company locate its current posture and plan the next maturity step.

Level 1, Initial / ad hoc

• Posture: Scope exists as a paragraph in the BCM Policy ("the BCMS covers the whole company"); no candidate register; no inclusion/exclusion; no dependency map; no scope diagram; no top-management approval cycle.
• Typical artefact count: 1 paragraph.
• Investment to reach L1: ₹0 to 2 lakh baseline (one BCM Lead draft).
• Likely audit outcome: Major nonconformity on Clause 4.3.

Level 2, Defined

• Posture: A 2- to 4-page Scope Statement naming in-scope entities, products, services and locations; some exclusions listed (rationale thin); a basic dependency map (one or two PESTIS dimensions); a simple scope diagram; top-management approval on file.
• Typical artefact count: 1 Statement + 1 dependency spreadsheet + 1 diagram.
• Investment to reach L2 (from L1): ₹3 to 8 lakh of internal effort plus light consultancy.
• Likely audit outcome: Minor nonconformities on exclusion rationale and dependency-map completeness; climate-considerations missing.

Level 3, Managed

• Posture: A 6- to 12-page Statement with inclusion table, exclusion table (with rationale and evidence references), full PESTIS dependency map, scope diagram with cross-boundary arrows, regulatory overlay, climate-considerations subsection (Amendment 1:2024); top-management approval; scope-change governance workflow defined; KPI dashboard live; integration with BIA, strategy, plans and exercise programme confirmed.
• Typical artefact count: 5 to 10 controlled documents.
• Investment to reach L3 (from L2): ₹15 to 30 lakh of internal effort plus consultancy.
• Likely audit outcome: Clean certification; minor findings on tooling and refresh cadence.

Level 4, Quantitatively managed

• Posture: Scope Statement hosted in a GRC platform; live-fed dependency map (CMDB integration, procurement-data integration); regulator-by-regulator scope annexures; quarterly horizon-scan of regulatory and climate-change inputs; scope-change governance with auditable workflows; KPI-driven reporting to a BCM Steering Committee; cross-entity scope annexures for group structures; cross-border scope annexures for international operations.
• Typical artefact count: 15 to 30 controlled documents + a GRC-platform-hosted scope module.
• Investment to reach L4 (from L3): ₹30 to 70 lakh per year (people + platform + content feeds).
• Likely audit outcome: Clean certification; supervisor-grade artefacts; positive regulatory feedback.

Level 5, Optimising

• Posture: Predictive scope analytics (scope drift detected before audit); continuous dependency discovery (new dependencies surfaced automatically); benchmark scope posture against peers; integrated with ERM, GRC platform, and board reporting; scope as a sales asset in enterprise-customer RFP responses; climate-driven scope scenarios refreshed continuously.
• Typical artefact count: N/A (live, continuously-updated scope environment).
• Investment to reach L5 (from L4): ₹60 lakh to ₹3 crore per year (platform + analytics + content + people).
• Likely audit outcome: Clean certification; benchmark posture; sectoral leadership.

Maturity summary table

Emerging Trends

Several trends are reshaping what a mature 4.3 Scope Statement 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). 4.3 maturity requires explicit DPDP-driven scope coverage of every material personal-data processing activity, exclusions here are a red-line.
• Climate-scope expectations hardening (Amendment 1:2024). What was soft expectation is becoming hard requirement: SEBI BRSR for listed entities; TCFD/ISSB-aligned disclosure norms; insurer and reinsurer climate-risk underwriting; NGT and MoEFCC enforcement. The 4.3 climate-considerations subsection is no longer a formality. For flood-exposed (Chennai, Mumbai, coastal Bengaluru), heat-exposed (Indo-Gangetic plain), and water-dependent (pharma, chemicals, beverages) operations, climate is a material scope input.
• Operational resilience overtaking BCP. The shift, most visible in HKMA OR-2, UK FCA/PRA/CB operational resilience policy, and APRA CPS 230 (effective 1 July 2025), is from "do you have a plan?" to "can you maintain critical operations within tolerance through severe disruption?". 4.3 is where the important business services dimension of operational resilience gets surfaced (which services, what tolerance, what scope).
• DORA's third-party regime. DORA's ICT-third-party regime (Arts 28 to 30 + Arts 31 to 44 CTPP oversight, applies from 17 January 2025) is creating a new class of managed dependency for Indian SaaS/IT-services firms serving EU financial-services customers. The 4.3 cross-border scope annexure 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.3 scope must explicitly include CERT-In horizontally-applicable obligations.
• 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 scope constraint that the Statement must reflect.
• Concentration-risk scrutiny. The 17 September 2024 Jio DC fire (Cloudflare Radar measured AS55836 traffic down up to 53 per cent) and the 12 April 2025 NPCI/UPI ~5-hour nationwide degradation showed the blast radius of single-vendor concentration. Regulators are increasingly asking about concentration in scope, secondary suppliers and geo-diversity as managed-dependency requirements.
• AI-related scope expansion. As AI/ML systems become part of critical operations, new activities enter scope: model-inference serving, training-data pipelines, model-validation evidence chains. The 4.3 scope for AI-driven critical services must capture these explicitly.
• Board-level resilience dashboards. Boards are increasingly asking for resilience dashboards (not just compliance reports). The 4.3 Scope Statement, dependency map and KPI set feed directly into such dashboards.

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 8 scope; paragraph 38 BIA triple; paras 47 to 60 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.
• Infosys McCamish Systems, LockBit, ~29 October 2023; ~6 million individuals affected; Infosys McCamish agreed US$17.5 million class-action settlement.
• Air India / SITA, data breach disclosed May 2021, ~4.5 million Air India customers. Source: reuters.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.
• Kerala floods, June to August 2018; CIAL (Cochin airport) shut ~2 weeks with ~₹250 crore income loss. Source: sdma.kerala.gov.in; nidm.gov.in.
• CrowdStrike / Microsoft global outage, 19 July 2024; IndiGo cancelled 283 flights (thehindu.com); Akasa Air reported zero cancellations via manual check-in (contrast pair on procedures, not scope).

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).
• 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 70 million), LG Polymers NGT penalty (₹50 crore), Go First refund liability (₹597 crore), AIIMS ransomware reported figure (~₹200 crore, unconfirmed), Yes Bank moratorium (Yale JFC case), Infosys McCamish settlement (US$17.5 million), these are the strongest primary-sourced anchors; treat other figures as "reported" or "[UNVERIFIED]" unless traced to a primary disclosure.
• The official ISO 22301:2019 PDF's text layer does not extract via pypdf in our environment; the paraphrase in this guide (sourced from the manifest's own-words paraphrase) has therefore not been programmatically validated against the official text. Validate against the published standard before relying on it for certification.

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.3 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.