ISO 22301 Clause 7.1: Resources

Quick Reference (60 Seconds)

If you only read one thing: Clause 7.1 is where the BCMS is treated as a funded, capable system rather than a documentation set. A 7.1-conformant BCMS is one in which the organisation has identified the resources required to establish, run and improve the BCMS, has committed them through a budgetary decision, has inventoried them, has tested that they are sufficient to meet the BIA-derived RTO/RPO/MBCO commitments, and feeds the resource portfolio into the management review every cycle. The certification auditor will examine this discipline ruthlessly, and so will a regulator after a disruption, when a BCMS fails, the second question after "what happened?" is always "was this BCMS actually resourced to meet its commitments?". Get 7.1 wrong and however strong the policy, the BIA and the plans, the BCMS will fail on the day it is activated because the resources to execute the plans simply do not exist. Get it right and the BCMS becomes a system whose commitments are matched by its means.

What the Standard Actually Requires

The paraphrased requirement

ISO 22301 Clause 7.1 asks organizations to provide the resources the BCMS needs to be established, run, and improved. The paraphrase compresses a substantial management discipline into one sentence, and unpacking each phrase is the most useful way to understand what an auditor will look for.

Provide means the organisation commits the resources deliberately through a budgetary and allocation decision. The resources must be identifiable in the enterprise budget, in a procurement record, in a HR establishment list, in a contract, or in an equivalent artefact of organisational commitment. Resources that exist only in the BCM Manager's good offices, in informal departmental goodwill, in spare capacity that has never been committed, or in vendor marketing slides are not "provided" in the sense the standard requires. The provision test is: can the organisation produce, for any BCMS resource commitment, the budget line, the contract, the HR record, the purchase order or the equivalent artefact that evidences the commitment? If yes, the resource is provided; if no, the resource is aspirational and the BCMS is nonconformant at that point.

Resources spans five classes, and a complete 7.1 evidence set addresses each:

• People. The FTE, contractors, consultants, secondees and crisis-response rosters who design, build, operate, maintain, exercise, audit and improve the BCMS. People resources include the BCM Manager and team, the CISO and information-security staff who deliver the cyber-resilience controls that underpin continuity, the IT infrastructure team who run the recovery capability, the operations team who run the work-area recovery and manual fallbacks, the crisis-management team and alternate, the crisis-communications team, the internal audit team that tests the BCMS, the legal and compliance team that handles regulatory reporting, and the external consultants and advisers who supplement internal capacity. People resourcing is measured in FTE-equivalents, in named individuals (not role-only labels), in succession depth (single-point-of-failure roles identified and remediated), and in competence (Clause 7.2 evidence).
• Technology. The hardware, software, cloud services, backup systems, DRS, network, endpoint fleet, communication tools, crisis-notification platforms, GRC/BCM software, monitoring tooling and analytics that the BCMS relies on. Technology resourcing includes the production infrastructure whose availability the BCMS is designed to protect, the recovery infrastructure (DRS, backup, immutable storage, failover tooling) that the BCMS activates on disruption, and the management tooling (BCM software, dashboard, alerting) that runs the BCMS itself. Technology resourcing is measured in capacity (CPU, storage, bandwidth, licences), in tier-of-service (HA architecture, RTO/RPO-bearing SLAs), in geographic diversity (primary, DRS, alternate), and in contractual commitment (SLA, penalty, exit).
• Infrastructure. The physical and environmental facilities that house the people, technology and operations, the data centres (primary, secondary, edge), the alternate site, the work-area recovery location, the office premises, the power infrastructure (grid, UPS, genset, fuel), the telecom infrastructure (diverse last-mile, mobile, satellite), and the transport infrastructure that enables workforce mobility in a disruption. Infrastructure resourcing is measured in capacity (rack, square-foot, seat, kVA), in geographic separation (typically ≥30 km for seismically stable regions; more for flood- or seismic-prone), in contractual commitment (work-area-recovery contract, colocation SLA), and in resilience tier (TIA-942 or Uptime Institute tier).
• Financial. The OpEx run cost (people salaries, DRS subscription, drill cost, maintenance, software licences, retained consultants) and CapEx programme cost (alternate-site build, DRS build, tooling procurement, consulting engagement) that fund the BCMS across the budget cycle. Financial resourcing is measured in annual budget (the OpEx line), in programme budget (the CapEx envelope over the build horizon), in contingency reserve (the surge fund for disruption-driven spend), and in insurance (BI cover, cyber cover, crime cover, D&O cover). The financial dimension is the most-cited 7.1 evidence and the most frequently failed, many Indian growing companies cannot produce a defensible BCMS budget line because the spend is dispersed across IT, Operations, HR and Finance with no consolidated view.
• Information and external services. The documented information (BIA, strategy, plans, contact trees, exercise reports, audit reports, management-review minutes) that constitutes the BCMS system of record; the data (asset inventory, configuration management database, supplier register, customer data, regulator correspondence) that drives BCMS decisions; the supplier services (cloud HA, managed DR, SaaS availability, mutual-aid, work-area-recovery, crisis-communications agency, technical forensics, legal counsel) that extend the organisation's own capacity; the regulator access (PoC relationships with RBI, SEBI, IRDAI, CERT-In, NDMA); and the expert advice (legal, insurance, technical, medical, psychological-first-aid) that the BCMS can draw on. This class captures the BCMS's "soft" infrastructure and is the one most often omitted from 7.1 evidence sets.

The BCMS means the system itself, every clause from 4 to 10, not just the BCM team's desktop. The standard's choice of "the BCMS" (the management system) rather than "business continuity" (the operational outcome) is deliberate: the resourcing duty covers the design, build, operation, maintenance, evaluation and improvement of the management system, in addition to the response capability that the system produces. A common 7.1 misconception is that the clause only requires resources for the response (DR site, backup, crisis team). It also requires resources for the management-system work, the BIA refresh cycle, the strategy review, the exercise programme, the internal audit, the management review, the corrective-action pipeline, the continual-improvement initiatives. These are BCMS-running costs that must be funded.

Needs means the resources the BIA, the strategy and the plans demonstrate are required to meet the organisation's RTO/RPO/MBCO/MTPD commitments. Needs are not whatever the organisation finds convenient to provide; they are what the analytical artefacts of the BCMS (Clause 8.2 BIA, Clause 8.3 strategy, Clause 8.4 plans) prove are required. The most consequential 7.1 question an auditor asks is: how do you know these resources are sufficient? The only defensible answer is: because the BIA-derived demand was compared against the committed supply in a capability gap assessment, and the gap was closed or accepted as a documented risk. Needs are therefore a derived quantity, not a starting assumption.

Established, run, and improved means the three temporal phases of the BCMS lifecycle, each with a distinct resource profile:

• Established (design and build), the upfront investment to design the BCMS, run the first BIA, select the strategy, build the plans, procure the DRS, stand up the BCM team, train the workforce and run the first exercise. This phase is CapEx-heavy and typically runs 6 to 18 months in an Indian growing company.
• Run (operate and maintain), the recurring spend to keep the BCMS in operation: BCM team salaries, DRS subscription, drill cost, software licences, plan-refresh cycles, audit cost, awareness training, supplier management. This phase is OpEx-dominant and recurs annually for the life of the BCMS.
• Improved (continually improve), the investment to advance BCMS maturity: tightening RTO/RPO, automating manual activities, expanding scope, integrating with adjacent disciplines (ISM, ERM, OT security), responding to incidents and audit findings. This phase is a mix of CapEx (programme spend) and OpEx (incremental run cost).

A 7.1 evidence set that addresses only one of these phases, typically "run", because the OpEx budget line is the easiest to produce, is incomplete. The standard requires all three.

What "adequate" resources means, the demand-vs-supply test

The standard does not use the word "adequate", but the practitioner consensus, drawn from ISO 22313:2020 guidance on Clause 7.1, the Harmonized Structure's treatment of "resources" across ISO management-system standards, and the bodies of BCM practice, is that resources are 7.1-conformant when committed supply meets derived demand, with any gap either closed or accepted as a documented risk. The demand-vs-supply test is the operational form of the requirement.

Demand is derived from the analytical artefacts of the BCMS:

• The BIA (Clause 8.2) produces, for each prioritised activity, an RTO (time), an RPO (data), an MBCO (quality floor) and a list of dependencies (people, technology, information, suppliers, facilities). Each dependency is a resource demand.
• The strategy (Clause 8.3) translates those demands into recovery solutions, DRS architecture, backup design, work-area recovery, manual fallbacks, supplier failover, each of which has a resource cost.
• The plans (Clause 8.4) translate the strategy into activation procedures, contact trees, runbooks and crisis-management structures, each of which implies people, technology and information resources.
• The objectives (Clause 6.2) and the policy (Clause 5.2) carry top-management commitments that imply resource levels.
• The risk register (Clause 6.1) carries risk treatments, each of which has a resource claim.
• The regulatory landscape (RBI, SEBI, IRDAI, CERT-In, DPDP) imposes resourcing expectations that are external demands.

Supply is what the organisation has committed in the resource inventory: the FTE, the contracts, the budget lines, the facilities, the licences, the supplier agreements. Supply is a snapshot of what exists today, with a forward view of renewals and expiries.

The gap assessment compares demand and supply by class and by activity, and produces one of three findings per item: sufficient (supply meets demand, conformant), gap (supply falls short, close it or document the risk), or surplus (supply exceeds demand, opportunity to reallocate or to retire legacy spend). The gap assessment is the single most important 7.1 evidence because it is the only way the organisation can defensibly answer the auditor's question: how do you know these resources are sufficient?

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

Clause 7.1 is widely misread as "have a BCM budget" or "have a DR site", both are partial and both miss the BCMS-specific obligation. Being explicit about what 7.1 does not require protects against two failure modes: under-investing (treating the budget line as a documentation artefact) and over-reaching (treating 7.1 as the enterprise resource-management system).

• 7.1 does not require unlimited resources. The standard does not expect the organisation to fund every conceivable continuity capability. It expects the organisation to identify the resources its BCMS needs (driven by its BIA, strategy and objectives), commit them through a budgetary decision, and address any gap explicitly. A small organisation that legitimately needs a 24-hour RTO is conformant with a much lighter resourcing footprint than a bank that needs a 30-minute RTO. The standard is silent on absolute spend; it is vocal on the demand-vs-supply discipline.
• 7.1 does not require the BCM team to own every resource. Most BCMS resources are owned by other functions, IT owns the DRS, Operations owns the work-area recovery, HR owns the people establishment, Procurement owns the supplier contracts, Finance owns the budget. The BCM team's job is to identify the demand, document the supply, run the gap assessment and report the result. Ownership is a Clause 5.3 question; 7.1 is about identification, commitment, inventory and review.
• 7.1 does not require a specific BCM FTE count. The standard does not mandate a minimum or maximum BCM headcount. An Indian growing company may legitimately run a 0.5 FTE BCM Manager with a deputy and a contracted consultant; a bank may have a 20-person BCM team. The right headcount is whatever the BIA-derived demand demonstrates is required. A BCM team that is one part-time manager for a bank with 30-minute RTO commitments is almost certainly nonconformant; the same team for a 250-person BPO with 7-day RTO commitments may be conformant.
• 7.1 does not require every resource to be owned (not rented). Cloud DRS, managed DR services, work-area-recovery subscriptions, mutual-aid arrangements, retained consultants and SaaS availability are all legitimate forms of resourcing. The standard is silent on own-vs-rent; the decision is a strategy (Clause 8.3) and procurement question. What matters is that the rented resource is contractually committed, SLA-bearing, and tested through exercises.
• 7.1 does not require a specific DRS tier or geography. The standard does not mandate active-active, active-passive, hot-warm, warm-cold or any specific DRS architecture. The BIA and strategy drive the tier decision; 7.1 requires that whatever tier is chosen is actually resourced, the contract, the capacity, the network, the failover tooling, the test evidence.
• 7.1 does not require zero resource gaps. A gap that is identified, risk-assessed, documented on the risk register, and either accepted by top management or scheduled for remediation is conformant, provided the gap is visible and the risk is owned. A gap that is invisible (the BCM Manager knows the DRS SLA exceeds the BIA RTO but never tells anyone) is nonconformant regardless of the gap's size.
• 7.1 does not require top-management approval for every resource transaction. Authority is delegated in the Resource Management Procedure. The budget envelope is approved by top management; routine resource transactions within the envelope are delegated to the BCM Manager, IT, Operations, Procurement or HR as appropriate. What is non-delegable is the budget-level commitment, the visible proof that top management has funded the BCMS.
• 7.1 does not require a software-hosted inventory. A spreadsheet is conformant. A GRC-platform BCM module is leading practice in larger organisations but is not mandated. The standard requires the inventory to be controlled, versioned and accessible, properties a well-managed spreadsheet has.
• 7.1 does not require all resources to be in-house. Outsourced, cloud-delivered, mutual-aid and supplier-funded resources are conformant, provided they are contractually committed and evidenced. The standard explicitly recognises (Clause 8.1) that organisations outsource; 7.1 ensures that outsourced BCMS dependencies are themselves resourced (by the supplier) and that the resourcing is evidenced.
• 7.1 does not require resources to be perfect or unused. A BCMS with surplus capacity (more DRS than the BIA strictly requires, more BCM team FTE than the day-to-day work demands) is conformant. The standard does not penalise over-resourcing, provided the surplus is intentional (documented as a strategic choice) rather than accidental (drift through unmanaged procurement).

What the standard does NOT say about resourcing (and what to do about it)

The standard's text on 7.1 is short and high-level; the substantive architecture, the five resource classes, the seven-stage resource-management workflow, the demand-vs-supply gap assessment, the DRS costing model, the feasibility test, the escalation provision, is practitioner elaboration drawn from ISO 22313:2020 (companion guidance on Clause 7.1), ISO/TS 22331:2018 (strategy resourcing), the Harmonized Structure's treatment of "resources" across ISO management-system standards, and the bodies of BCM practice. This guide makes those elaborations explicit so that the BCMS you build is not just minimally conformant but operationally effective. Where the standard is silent on a detail (e.g., what counts as "the resources are sufficient"), this guide states the practitioner convention and explains the rationale; you may adopt the convention or document an alternative as long as the standard's intent is met.

Why This Control Matters

The business risk

When a disruption strikes, the difference between an organisation that recovers in hours and one that collapses in days is rarely the technical architecture, it is whether the resources to execute the recovery actually exist. A BCMS whose plans describe a recovery capability that the organisation has never resourced is worse than no BCMS, because the organisation's leaders are making recovery decisions based on assumptions that are financially and operationally false. Clause 7.1 is the clause that keeps the BCMS matched to its resourced reality across every budget cycle, every supplier renewal, every leadership transition and every regulatory shift.

Every major Indian incident of the last decade that turned from a contained event into a public crisis shares a 7.1 failure mode. The November 2022 AIIMS Delhi ransomware that took e-Hospital down for days, the post-incident review surfaced that the BCMS documentation described a recovery capability that the actual infrastructure did not match: primary and backup servers were both encrypted because immutable offsite backups had never been funded, the IT team was below the establishment strength the BCMS assumed, and the crisis-communications function had no retained agency or surge capacity. The November 2020 HDFC digital outage that drew the RBI's ban on new digital products, the public record shows that the active-active DC architecture that the BCMS strategy required had been approved in principle but never resourced: the secondary DC was a cold site with a multi-day recovery profile, the BCM team was a single manager, and the recommended live-failover drill programme had never been budgeted. The Cognizant Maze ransomware (April 2020), the SEC-filed disclosure noted that the federated-network architecture that would have contained the blast radius had been identified as a strategic investment but deferred year after year as a cost-saving measure; the BCMS strategy described a segmentation capability that the resourced infrastructure did not deliver.

The business risk of weak 7.1 implementation is concentrated in four failure modes. The first is goodwill resourcing, the BCMS depends on informal commitments from department heads, on spare capacity that has never been formally allocated, on key individuals' goodwill, and on vendor marketing claims rather than contracts. When disruption strikes, the goodwill is already committed elsewhere, the spare capacity does not exist, the key individuals are unavailable, and the vendor's marketing proves aspirational. The second is under-budgeted BCMS, the budget line is too thin to fund the strategy, the BIA commitments are unachievable with the resourced capability, and the gap is invisible because no gap assessment was ever run. The third is un-tested resourcing, resources are committed on paper (DRS contract, BCM team establishment, work-area-recovery subscription) but never validated through an exercise, so the gap between paper and reality is discovered only when the BCMS is activated in a real disruption and fails. The fourth is stale resourcing, the inventory was accurate once but has drifted through leadership turnover, supplier changes, technology migrations and budget cuts; the BCMS documentation describes a resourced capability that no longer exists.

The Indian regulatory context

The Indian regulatory environment has, over the last decade, transformed 7.1 from an internal budgetary nicety into a regulator-supervised resourcing expectation with named provisions. The transformation has happened across every major sector regulator, and the cumulative effect is that an Indian organisation's BCMS resourcing is now expected to be audit-defensible and regulator-interaction-ready.

For banks, NBFCs and payment system operators, the RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024) requires the board and senior management to oversee the IT budget, to ensure adequate staffing of the IT and information-security functions, to resource the IT Service Continuity capability including DRS, and to maintain a qualified CISO and SOC staffing establishment. The Master Direction treats resourcing as a governance control, an under-resourced IT or BCM function is a board-level concern, not an IT-ops issue. The RBI's action against HDFC in December 2020 (restriction on new digital products and fresh credit cards, partially lifted August 2021, fully lifted March 2022) demonstrated that the RBI treats resourcing-driven availability failures as a board-level governance failure. The RBI Master Direction on Outsourcing of IT Services (10 April 2023) extends resourcing expectations to outsourced arrangements, the outsourcer's continuity resourcing must meet the RE's own standards, and the RE has right-of-access to verify the outsourcer's resourcing claims. The RBI Cyber Security Framework in Banks (2 June 2016) requires a board-approved cyber-security policy with allocated budget, 24x7 SOC resourcing, and a Cyber Crisis Management Plan (CCMP) that is itself a resourced programme.

For SEBI-regulated entities, the Cybersecurity and Cyber Resilience Framework (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024) grades REs into five categories with resourcing expectations scaling by category, a Category-1 MII is expected to resource a 24x7 SOC, dedicated BC/DR teams, and quarterly drill programmes; a Category-5 small broker has lighter expectations but still needs a defined BCM responsibility and an annual drill. The SEBI MII BCP-DR circular (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021) requires MIIs to resource Near Site and DRS architecture with RTO/RPO-derived capacity and geographic separation, the MII's resourcing footprint is in scope of the board's Risk/IT committee.

For insurers, the IRDAI Information and Cyber Security Guidelines (24 April 2023) require a board-approved budget for information and cyber security, CISO resourcing, DR drill resourcing, and ICT outsourcing oversight staffing. The board-approval requirement means that the insurer's BCMS resourcing is in scope of the board's Risk/IT committee, a structural 7.1 escalation.

CERT-In Directions (20(3)/2022-CERT-In, 28 April 2022) raise the resourcing stakes: the 6-hour incident-reporting clock presupposes a resourced point-of-contact (PoC) function, the 180-day log-retention requirement presupposes log-retention infrastructure, the NTP-sync requirement presupposes time-source infrastructure, and the customer-KYC requirement presupposes data-residency and storage infrastructure. An organisation that cannot resource these capabilities is non-compliant with CERT-In regardless of its ISO 22301 posture.

The DPDP Act 2023 (Act 22 of 2023) introduces two new 7.1 angles for every Data Fiduciary. Section 8(5) makes the availability of personal data a statutory duty, meaning the Data Fiduciary must resource the safeguards (technical, organisational, people) that protect availability. Section 8(6) imposes a breach-notification duty, an un-resourced incident-response capability that misses a breach is a reportable event under DPDP. For Significant Data Fiduciaries, the DPDP Rules 2025 add DPIA, periodic security audits and a DPO obligation, each of which is itself a resourcing demand. Penalties up to ₹250 crore for failure to take adequate security safeguards convert the 7.1 resourcing discipline from a quality control into a financial-risk-mitigation control.

The Companies Act 2013 Section 134(3)(n) requires the board's report to include a statement on the development and implementation of a risk management policy for the company, including the elements of risk that may threaten the existence of the company itself. A 7.1-conformant resourcing evidence set is the strongest evidence a board can produce that the risk-management policy is funded. Section 177 and SEBI LODR Regulation 21 give the Audit Committee and the Risk Management Committee explicit oversight of risk-management systems, for listed entities, the BCMS resourcing is in scope of those committees.

The NDMA Disaster Management Act 2005 and the National Disaster Management Guidelines (Chemical Disasters 2007; Disaster Management Plans 2014) require industrial operators to resource on-site and off-site emergency plans, mutual-aid arrangements, and the integration of industrial plans with District DMPs. The LG Polymers Vizag styrene gas leak (7 May 2020, NGT interim penalty ₹50 crore) is the starkest Indian example of what a 7.1 failure looks like at the industrial-hazard end of the spectrum: the operator had not resourced the monitoring, training and response capability that the changed process conditions (longer M6 tank storage during COVID lockdown) required.

The cost of non-compliance

The financial exposure of weak 7.1 implementation is concrete and quantifiable. Sector-specific penalties include RBI monetary penalties under the Banking Regulation Act (typically ₹1 crore to ₹10 crore per failure for SCBs; the HDFC case demonstrated the structural penalty of a business restriction, which dwarfed the direct monetary penalty); SEBI penalties under the SEBI Act (up to ₹25 crore per contravention); IRDAI penalties (monetary penalties for ongoing non-compliance for insurers (verify the current daily limit)); DPDP penalties (up to ₹250 crore for security-safeguard failures, up to ₹200 crore for breach-notification failures); CERT-In enforcement (escalation to MeitY, with downstream consequences for the entity's ability to operate ICT in India).

Beyond direct penalties, the indirect costs typically dwarf the direct ones. The Cognizant Maze ransomware (April 2020) cost the company $50–70 million in a single quarter per its SEC 10-Q filing, a substantial portion of which traced to the under-resourced network segmentation and backup capability that the BCMS strategy had required but the budget had deferred. The Change Healthcare ransomware (February 2024) cost UnitedHealth over $3 billion full-year, the under-resourced segmentation and the missing MFA on the Citrix portal were both resourcing failures first, security failures second. Share-price drops after a resourcing-induced public disruption; customer churn after a continuity failure the organisation was not resourced to absorb; board and executive reputational damage; and the cost of remediation programmes mandated by regulators (HDFC's external IT audit was a precondition for lifting the digital-products ban, and the audit explicitly examined the resourcing discipline). Each of these costs is amplified when the organisation cannot demonstrate that the BCMS was funded to meet its commitments, the regulator and the court treat the absence of resourcing evidence as evidence of governance failure.

The corollary is positive: a well-built 7.1 evidence set is also the strongest defence when a regulator or a court asks whether the organisation took continuity seriously. A documented BCMS budget line, a capability gap assessment, a feasibility test and a management-review trail are the artefacts that distinguish a organisation that "tried and failed" from one that "never really tried". The former is treated proportionately; the latter punitively.

A well-built 7.1 evidence set does not eliminate these risks but it does three things. First, it makes the BCMS's resourcing visible, and visible resources get funded, renewed and tested. Second, it makes the resourcing defensible, when a regulator asks "was this BCMS actually funded?", the answer is documented. Third, it converts the BCMS from a documentation artefact into a funded system, every budget cycle is a chance to align resourcing with the BCMS's evolving commitments.

Scope and Applicability

Who must implement 7.1

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

For Indian growing companies (50 to 250 staff), 7.1 typically produces a 30-to-80-line resource inventory, a single-tier resource-management workflow, a BCM Steering Committee that doubles as the resourcing forum, and an annual capability gap assessment. The inventory is a spreadsheet; the budget is a single line in the enterprise OpEx; the feasibility test is the annual exercise. The DRS decision is usually buy-not-build (cloud DRS, managed DR service, or work-area-recovery subscription) because the CapEx for own-build is rarely justifiable at this scale.

For growing Indian organisations (250 to 2,000 staff), the inventory typically grows to 80 to 250 lines across the five resource classes, a dedicated BCM budget line exists separately from the IT budget, the DRS decision is typically a contracted colocation with managed services or a cloud HA architecture, and the feasibility test is a quarterly drill programme plus an annual full-failover exercise. The Resource Management Procedure is integrated with the enterprise budget cycle, the ITSM/ITIL change process (for technology resource changes) and the HR org-change process (for people resourcing).

For multi-entity enterprises (2,000+ staff), the resourcing system is integrated across entities, with group BCM resourcing cascaded to subsidiary BCMSs, with multi-jurisdiction regulatory-resourcing expectations (DORA Article 6 for EU-financial entities, APRA CPS 230 paragraphs 16 and 41 for Australian-prudential entities, MAS TRM for Singapore-financial entities, RBI MD for Indian banks and large NBFCs) feeding the resourcing demand, and with the BCM Steering Committee functioning as a forum for cross-entity resourcing coordination. The resourcing KPIs are benchmarked across entities and reported to the group risk committee.

What "resources" means in 7.1 scope

The 7.1 scope is "resources the BCMS needs", meaning resources that are required to establish, run and improve the management system, in addition to resources required to execute the response capability. The demarcation is critical because it determines which resources go into the BCMS inventory and which stay in enterprise operational budgets.

In scope (BCMS resources, Clause 7.1 applies):

• The BCM team establishment (BCM Manager, deputies, analysts, coordinators), Clause 5.3, 7.2.
• The crisis-management team and alternates, Clause 8.4.
• The crisis-communications team and any retained agency, Clause 7.4, 8.4.
• The DRS, secondary DC, cloud HA architecture, immutable backup, Clause 8.3.
• The work-area recovery and alternate-site arrangements, Clause 8.3.
• The BCM software / GRC platform / dashboard / exercise tooling, Clause 7.5, 8.5.
• The crisis-notification platform / mass-notification tool / emergency-comms system, Clause 7.4, 8.4.
• The BCP/DR drill programme budget (tabletop, simulation, full-failover), Clause 8.5.
• The internal-audit allocation for BCMS scope, Clause 9.2.
• The management-review time of top management, Clause 9.3.
• The BIA-refresh and strategy-review cycles, Clause 8.2, 8.3.
• The awareness-training programme, Clause 7.3.
• The supplier-continuity oversight resourcing, Clause 8.1.
• The CERT-In PoC function and 24x7 incident-response contactability, CERT-In C1.
• The log-retention infrastructure (180-day), CERT-In C1.
• The regulator-relationship capacity (RBI/SEBI/IRDAI/CERT-In/NDMA liaison).
• The retained legal, forensic, insurance, medical, psychological-first-aid advisers.
• The BCM-related insurance cover (BI, cyber, crime, D&O).
• The contingency / surge reserve for disruption-driven spend.
• The continual-improvement programme budget, Clause 10.2.

Out of scope (enterprise operational resources, not 7.1 unless they bear on the BCMS):

• General office infrastructure that is unrelated to BCMS response.
• General HR establishment unrelated to BCM roles.
• General IT operational staff unrelated to recovery capability.
• General procurement spend unrelated to BCMS supplier contracts.
• General finance budget lines unrelated to BCM.

The boundary is the BCMS dependency test: does this resource bear on the organisation's ability to establish, run or improve the BCMS, or to execute the response capability the BCMS produces? If yes, the resource is in scope and must be inventoried; if no, the resource is an enterprise operational matter outside 7.1.

Applicability by organisation type

Key Definitions and Terminology

The vocabulary of Clause 7.1 is shared with the rest of ISO 22301 and the broader BCM profession. The definitions below paraphrase the canonical sources (ISO 22300:2021 vocabulary, ISO 22301:2019 context, ISO 22313:2020 guidance) and add the practitioner conventions that operationalise them for resourcing decisions.

Resource (in the 7.1 sense). Any commitment of people, technology, infrastructure, financial capacity, or information/external services that the organisation has made available to the BCMS. A resource is "committed" when it is evidenced by a budget line, a contract, an HR establishment record, a purchase order, a license, or an equivalent artefact of organisational commitment. Resources that exist only in goodwill, spare capacity or vendor marketing are not committed.

Resource class. One of the five categories into which BCMS resources are organised for inventory, gap-assessment and reporting purposes: people, technology, infrastructure, financial, information/external. The five-class taxonomy is a practitioner convention (drawn from ISO 22313:2020 and the bodies of BCM practice) that ensures the inventory covers the full resourcing footprint without double-counting.

BCMS Resource Inventory. The controlled, versioned list of every committed resource by class, owner, cost band, lifecycle stage, BCMS dependency and renewal date. The inventory is the master artefact of Clause 7.1 and the basis for the capability gap assessment, the budget plan, the supplier-resourcing map and the management-review input. The inventory must be controlled per Clause 7.5 (documented information).

Capability Gap Assessment. The structured comparison of BCMS resource demand (derived from the BIA, strategy, plans, objectives and risk register) against BCMS resource supply (the inventory), producing a finding per resource line: sufficient, gap, or surplus. The capability gap assessment is refreshed annually and after every BIA revision, strategy revision, regulatory shift, or major organisational change.

RTO (Recovery Time Objective). The target time set for the resumption of a prioritised activity after a disruptive incident. RTO is the time-driven demand on the BCMS's resourcing, a 4-hour RTO demands a different DRS, runbook and team than a 7-day RTO. (Definition paraphrased from ISO 22300:2021.)

RPO (Recovery Point Objective). The point in time to which information used by an activity must be restored. RPO is the data-driven demand on the BCMS's resourcing, a 15-minute RPO demands near-continuous replication, where a 24-hour RPO demands daily backup. (Definition paraphrased from ISO 22300:2021.)

MTPD (Maximum Tolerable Period of Disruption). The duration of time following a disruptive incident after which an activity's tolerable level of impact is exceeded. MTPD is the upper bound that RTO must satisfy (RTO ≤ MTPD, with safety margin). MTPD is the ceiling against which resourcing feasibility is judged, if the resourced RTO exceeds MTPD, the BCMS is nonconformant by construction. Also called MAO (Maximum Acceptable Outage) in older BCI / ISO 22301:2012 usage. (Definition paraphrased from ISO 22300:2021.)

MBCO (Minimum Business Continuity Objective). The minimum level of activity or service that must be maintained or restored during a disruption. MBCO is the quality-driven demand on the BCMS's resourcing, an MBCO of "50% of normal throughput during the disrupted period" demands different capacity than "best-efforts resumption". (Definition paraphrased from ISO 22300:2021.)

Feasibility Test. The operational demonstration, typically through an exercise (Clause 8.5) or a parallel run, that the committed resources can actually meet the BIA-derived RTO/RPO/MBCO. The feasibility test is the operational form of the demand-vs-supply assessment and is the single most consequential 7.1 evidence.

DRS (Disaster Recovery Site). The secondary site, own-build, colocation, or cloud, to which the BCMS fails over when the primary site is unavailable. The DRS is classified by tier of service (hot, warm, cold; or TIA-942 / Uptime Institute rated) and by architecture (active-active, active-passive). DRS resourcing is typically the single largest 7.1 spend line after people.

Near Site (NS). A low-latency secondary site used by MIIs (per SEBI BCP-DR S2) to achieve near-zero data loss on transaction-processing systems. Near Site resourcing is a specific MII requirement and is distinct from DRS in latency, geographic separation and cost profile.

Work-Area Recovery (WAR). The contracted alternate facility, typically a dedicated seat-capacity at a third-party recovery provider, to which the workforce relocates when the primary office is unavailable. WAR is the people-and-premises counterpart of DRS.

Alternate Site. Any pre-arranged secondary location (own, leased, contracted, or reciprocal) to which the organisation can relocate operations during a primary-site disruption. Alternate-site resourcing includes the facility, the seats, the IT, the telecom and the access logistics.

Mutual-Aid Agreement (MAA). A pre-arranged, typically reciprocal arrangement between organisations (often in the same industrial cluster or sector association) to share response resources during a disruption, foam and medical for chemical clusters, spare capacity for utilities, recovery specialists for sector groups. MAAs are a recognised supplier-resourcing pattern under NDMA guidelines.

Crisis-Management Team (CMT). The named, trained, alternated group that commands the BCMS response during a disruption. CMT resourcing includes the named members, the alternates, the training, the tools (war-room, conferencing, decision-log), and the time-of-top-management commitment.

Crisis-Notification Platform. The tool or service used to alert, mobilise and coordinate the response workforce and to communicate with stakeholders during a disruption. Crisis-notification platform resourcing includes the licence, the contact database, the multi-channel capability (SMS, voice, email, app push), and the test programme.

BCM Steering Committee. The cross-functional governance body, typically chaired by the CEO/COO and including the CIO, CISO, CFO, Head of Operations, Head of HR and Head of Legal, that oversees the BCMS on behalf of top management. The BCM Steering Committee is the principal forum for 7.1 resource decisions, and its minutes are a key 7.1 evidence.

OpEx (Operating Expenditure). The recurring annual spend on BCMS run cost, salaries, subscriptions, drill cost, maintenance, licences, retained advisers. OpEx is the "run" phase of the resourcing lifecycle and is the dominant phase in a steady-state BCMS.

CapEx (Capital Expenditure). The programme spend on BCMS build or improvement, alternate-site build, DRS build, tooling procurement, consulting engagement, training programme. CapEx is the "established" and "improved" phases of the resourcing lifecycle.

Contingency Reserve. The pre-approved budget envelope for disruption-driven spend, emergency contracting, surge staffing, expedited procurement, customer-compensation, regulator-mandated remediation. The contingency reserve is the financial dimension of the escalation provision.

Business Interruption (BI) Insurance. The insurance cover that indemnifies the organisation for lost revenue and extra expense during a disruption. BI cover is a financial resource that funds the BCMS's post-disruption recovery, and the policy terms (sub-limits, waiting periods, exclusions) are themselves a resourcing consideration.

Relationship to Other Clauses and Frameworks

Relationship to other ISO 22301:2019 clauses

Clause 7.1 is the resourcing valve that every other ISO 22301 clause draws on. The relationships are bidirectional: every other clause generates resource demand (claims on 7.1), and 7.1 generates the supply that every other clause depends on (means for the BCMS).

• Clause 4 (Context): The organisation's context (4.1), interested-party expectations (4.2), and scope (4.3) shape the resource demand. A bank in scope of RBI MD IT Governance has a different resource demand than a 200-person SaaS startup; the context shapes the demand and 7.1 must respond.
• Clause 5 (Leadership): Top management's commitment (5.1) is the budgetary decision that funds the BCMS; the policy (5.2) carries commitments that imply resourcing; the roles (5.3) name the owners of each resource. The 5.1-to-7.1 link is the most important inter-clause relationship, an under-funded BCMS is a Clause 5.1 failure first, a Clause 7.1 failure second.
• Clause 6 (Planning): Risks and opportunities (6.1) carry resource claims for treatment; objectives (6.2) must be resourced; changes to the BCMS (6.3) have resource implications. An objective without a budget is a wish; the 6.2-to-7.1 link closes the loop.
• Clause 7 (Support): 7.1 is the head of the support cluster. Competence (7.2) demands qualified people resources; awareness (7.3) is itself a resourced programme; communication (7.4) demands channels, tools and contracted services; documented information (7.5) demands the system of record. Each subsequent support clause is a resource claim on 7.1.
• Clause 8 (Operation): Operational planning (8.1) drives day-to-day resourcing; the BIA (8.2) is the principal demand-side artefact, producing RTO/RPO/MBCO/MTPD and dependencies that drive resource demand; strategy (8.3) translates BIA demand into resourced solutions; plans (8.4) describe how the resources are activated; exercises (8.5) are the feasibility tests; post-disruption evaluation (8.6) reviews resourcing effectiveness.
• Clause 9 (Performance Evaluation): Monitoring (9.1) tracks resourcing KPIs; internal audit (9.2) tests the resourcing discipline; management review (9.3) receives the resource portfolio and the gap assessment.
• Clause 10 (Improvement): Corrective action (10.1) is itself a resourced activity; continual improvement (10.2) advances the resourcing maturity.

Relationship to other ISO management-system standards

The Harmonized Structure means Clause 7.1 in ISO 22301:2019 is structurally identical to Clause 7.1 in ISO/IEC 27001:2022 (Information Security Management Systems), ISO 9001:2015 (Quality), ISO 14001:2015 (Environmental), and ISO 45001:2018 (Occupational Health and Safety). An organisation running an integrated management system (IMS) treats resourcing once and produces a single evidence set that satisfies all the standards simultaneously, the resource inventory, the budget, the gap assessment and the management-review trail are common; only the BCMS-specific, ISMS-specific, QMS-specific, EMS-specific and OHSMS-specific resource lines differ. The integration is a major efficiency for Indian growing companies, who often run IMS combinations of ISO 27001 + ISO 22301 + ISO 9001.

Relationship to other frameworks

The frameworks most commonly mapped to ISO 22301 Clause 7.1 are: NIST SP 800-34 Rev 1 (step 4, identify preventive controls and recovery strategies, which is the demand-side resourcing); NIST CSF 2.0 (the Govern function, GV.PO, particularly GV.PO-02 which addresses funding); FFIEC BCM Booklet (governance and accountability, board and senior management responsibility for resourcing); DORA Article 6 (digital operational resilience framework, resourcing the framework) and Article 11 (response and recovery resources); APRA CPS 230 paragraphs 16 (BCPs as part of the framework), 41 (maintain BCP-execution capabilities) and 47 (service-provider management resourcing); MAS TRM (system availability and DR resourcing, para 8/9 area); HKMA TM-G-2 and OR-2. These mappings are detailed in Section 16.

Detailed Implementation Guidance, The Seven-Stage Resource Management Workflow

Figure · Process

What Clause 7.1 asks you to do

The practitioner form of Clause 7.1 is a seven-stage workflow that takes a BCMS resource from identification through to continual improvement of its allocation. The workflow is the operational structure of the Resource Management Procedure and is the framework around which the resource inventory, the capability gap assessment and the management-review input are organised.

Stage 1, Identify resource demand

The first stage is to identify what the BCMS actually needs. Demand is derived from the analytical artefacts of the BCMS, not invented:

• From the BIA (Clause 8.2): For each prioritised activity, extract the RTO, RPO, MBCO, MTPD, and the dependency list (people, technology, information, suppliers, facilities). Each dependency is a resource demand line. Example: a prioritised activity "wholesale payment processing" with RTO 2 hours, RPO 0 (zero data loss), MBCO 100%, depends on the core banking system, the payment-switch, the NPCI rail, a 6-person operations team, a 2-person IT-infrastructure on-call, and a contracted DRS, that is six resource demand lines from one activity.
• From the strategy (Clause 8.3): Translate the chosen recovery solutions into their resource cost. Active-active DC has one cost profile; active-passive DRS has another; manual workaround has another. The strategy document is the bridge from BIA demand to resource spend.
• From the plans (Clause 8.4): Identify the people, technology, information and external services that the activation procedures, contact trees, runbooks and crisis-management structures require. The plans are the operational form of the demand.
• From the objectives (Clause 6.2) and policy (Clause 5.2): Extract top-management commitments that imply resourcing, e.g., a policy commitment to "annual full-failover exercise" implies a drill budget, an exercise coordinator, a test-environment, and post-exercise reporting.
• From the risk register (Clause 6.1): Extract risk treatments, each of which has a resource claim, e.g., a risk treatment "implement immutable backups" implies a backup-platform licence, storage capacity, and an operational team.
• From the regulatory landscape: Extract resourcing expectations from RBI, SEBI, IRDAI, CERT-In, DPDP, NDMA, e.g., RBI MD IT Governance's CISO and SOC staffing expectations, CERT-In's PoC function, IRDAI's board-approved cyber budget.
• From the operational footprint: Extract the IT, OT, facilities, people and supplier base whose continuity the BCMS protects, each is a resource line.

The output of Stage 1 is a demand register, a structured list of every BCMS resource need, by class, by activity, by criticality, with a rationale and a source-artefact reference (which BIA line, which strategy decision, which regulatory clause). The demand register is the input to Stage 2.

Stage 2, Source resource supply

The second stage is to identify what the organisation has actually committed. Supply is a snapshot of the present state:

• People: Pull the HR establishment for BCM-named roles, IT infrastructure, operations, crisis-management team, internal audit, legal and compliance. Identify named individuals (not role-only labels), FTE-equivalents, succession depth, and any contractors or consultants on retainer.
• Technology: Pull the asset inventory, the software register, the cloud-service inventory, the DRS contract, the backup-platform licence, the BCM/GRC software licence, the crisis-notification platform. Identify capacity (CPU, storage, bandwidth, licences), tier-of-service, geographic diversity, and contractual SLAs.
• Infrastructure: Pull the DC contract, the colocation contract, the work-area-recovery contract, the office lease, the UPS/genset records, the telecom contracts (primary, secondary, mobile, satellite), the transport arrangements. Identify capacity (rack, square-foot, seat, kVA), geographic separation, and contractual commitments.
• Financial: Pull the enterprise budget for the BCM programme line, the IT line that funds the DRS, the Operations line that funds the work-area recovery, the HR line that funds the BCM team, the Legal line that funds retained counsel, the Insurance line for BI/cyber cover. Identify OpEx run cost vs CapEx programme cost, multi-year horizon, contingency reserve, and insurance cover.
• Information/external: Pull the documented information set (BIA, strategy, plans, contact trees, exercise reports, audit reports), the supplier-continuity contracts, the mutual-aid agreements, the regulator-PoC relationships, the retained adviser list.

The output of Stage 2 is a supply inventory, the master BCMS Resource Inventory, with each line tagged by class, owner, cost band, lifecycle stage, renewal date and BCMS dependency. The inventory is the central 7.1 artefact and is the basis for all subsequent stages.

Stage 3, Allocate (run the capability gap assessment)

The third stage is the demand-vs-supply comparison, the Capability Gap Assessment. This is the most analytically demanding stage and the one most often skipped or done superficially. The assessment is structured as follows:

• Compare line by line. For each demand line in the demand register, identify the corresponding supply in the inventory. A demand for "DRS with 4-hour RTO" maps to a supply line "DRS contract with vendor X, 24-hour SLA". A demand for "named BCM Manager with 5 years' experience" maps to a supply line "BCM Manager, named individual, 4 years' experience".
• Classify the finding. Three findings per line: sufficient (supply meets demand), gap (supply falls short), or surplus (supply exceeds demand). For each gap, quantify the gap in operational terms (FTE shortfall, INR shortfall, capability shortfall, SLA shortfall).
• Identify the root cause of the gap. Gaps arise from four sources: budget (the resource was never funded), market (the resource is not available in the market at any price the organisation can pay), capability (the resource exists but is not competent or not trained), or currency (the resource was funded historically but has lapsed through turnover, contract expiry, or technology drift).
• Prioritise the gaps. A gap on a 30-minute-RTO critical activity is more urgent than a gap on a 7-day-RTO back-office activity. A gap with regulatory exposure (e.g., RBI MD non-compliance) is more urgent than a gap with only internal consequence.
• Decide the treatment. For each gap, one of four treatments: close (commit the resource, typically a budget or procurement action), accept (accept the gap as a documented risk on the risk register, with top-management acknowledgement), transfer (transfer the gap to a supplier, insurer, or partner), or mitigate (reduce the demand, e.g., extend the RTO, narrow the MBCO).
• Document and report. The capability gap assessment is a controlled document per Clause 7.5. It is reported to the BCM Steering Committee, included in the management-review pack (Clause 9.3), and is the principal input to the next budget cycle.

Stage 4, Sustain (operation and renewal)

The fourth stage is to keep the resources in operation across the budget cycle. Sustaining is the "run" phase of the resourcing lifecycle and is the dominant workload in a steady-state BCMS:

• Operate the resources. Pay the salaries, pay the subscriptions, run the drills, maintain the DRS, test the backup, refresh the contact tree, run the awareness programme. Operating evidence (invoices, contracts, drill reports, test logs) is the artefact that proves the resource is in use, not just on paper.
• Track lifecycles. Every resource has a lifecycle: people join and leave, contracts start and expire, technology is procured and retired, facilities are leased and vacated. The inventory's renewal-date field is the trigger for renewal decisions, typically 90 to 180 days before expiry.
• Manage renewals. For each renewal, a decision: renew as-is, renew with changes (renegotiate SLA, capacity, price), or replace (switch supplier, switch technology, switch approach). Renewals are an opportunity to align supply with evolving demand and to close gaps identified in the capability assessment.
• Manage changes. Changes to BCMS resources (a new DRS vendor, a BCM team restructure, a tooling migration, a scope expansion) are Clause 6.3 events, they go through the BCMS change-management process and trigger a re-run of the capability assessment for the affected resource lines.
• Maintain the inventory. The inventory is a living artefact, updated as resources are committed, renewed, changed or retired. A monthly inventory review by the BCM Manager, a quarterly review by the BCM Steering Committee and an annual review at the management review are the typical cadence.

Stage 5, Measure (KPIs and monitoring)

The fifth stage is to measure how well the resourcing system is working. The KPI set (detailed in Section 12) covers four dimensions: volume (how many resources, how much spend), quality (gap-closure rate, SLA achievement, feasibility-test pass rate), outcome (BCMS activations met RTO/RPO; resourcing-driven incident rate; audit findings on 7.1), and integration (budget-vs-actual; objective-achievement-vs-resourcing; exercise-failure-vs-resourcing-gap correlation). The KPI dashboard is the operational form of Clause 9.1 monitoring applied to 7.1.

Stage 6, Review (management review input)

The sixth stage is the management-review input. Per Clause 9.3, the BCMS resource portfolio is a standing input to the management review. The 7.1 input typically includes:

• The current resource inventory summary (count by class, total spend, OpEx vs CapEx split).
• The current capability gap assessment (count of sufficient / gap / surplus lines, top-5 gaps, treatments).
• The KPI dashboard with trends.
• The feasibility-test results from the most recent exercise.
• The renewal calendar for the next 12 months.
• The budget ask for the next budget cycle, with justification.
• The regulatory-resourcing compliance posture (RBI, SEBI, IRDAI, CERT-In, DPDP).
• The status of any open 7.1 corrective actions.

The management review is the forum where top management renews or revises the BCMS funding commitment, the visible Clause 5.1 act that 7.1 depends on.

Stage 7, Improve (continual improvement of resourcing)

The seventh stage is continual improvement. Per Clause 10.2, the resourcing system itself evolves: maturity advances, automation replaces manual effort, integration with adjacent disciplines (ISMS, ERM, OT security) deepens, the inventory moves from spreadsheet to GRC platform, the gap assessment moves from annual to continuous, the feasibility test moves from once-a-year to embedded-in-each-release. The improvement pipeline is fed by audit findings, exercise failures, incident lessons, regulatory changes and technology shifts.

The five resource classes, implementation depth

Each of the five resource classes deserves implementation depth in its own right.

People resourcing. The people dimension is the most consequential and the most under-managed. Implementation guidance:

• Establish a BCM role catalogue with named roles (BCM Manager, BCM Coordinator(s), CMT Chair, CMT members, Crisis Communications Lead, BCM Steering Committee Chair, Internal Audit Lead for BCMS), each with a job description, a competency profile (Clause 7.2), and a named incumbent.
• Identify single-point-of-failure (SPOF) roles, roles with no qualified alternate. Every SPOF role is a Clause 7.1 gap that must be either closed (cross-training, deputy appointment) or accepted as a documented risk.
• Build the crisis-response roster with named members and alternates for each CMT role, with 24x7 contactability, with delegation rules (who decides if the primary is unreachable).
• Provide the time-of-top-management commitment, the CEO, COO, CFO must have calendar-allocated time for the BCM Steering Committee, the management review, the annual exercise and the post-incident review. This is the most-often-missing people resource.
• Maintain succession depth for the BCM Manager and CMT Chair roles, at least one named successor for each, with a development plan.
• Provide competence development, BCM training (BCI CBCI, DRI, ISO 22301 Lead Implementer), exercise participation, conference attendance, peer-network membership. Clause 7.2 evidence doubles as 7.1 evidence.
• Engage retained consultants and advisers, for specialist expertise (BIA facilitation, DRS architecture, crisis communications, technical forensics, legal counsel) that does not justify a full-time FTE.

Technology resourcing. The technology dimension is the most-spend-heavy after people. Implementation guidance:

• Establish the recovery infrastructure, DRS, backup platform, immutable storage, failover tooling, network diversity, with documented capacity, tier-of-service, RTO/RPO-bearing SLAs, and geographic separation. For Indian banks and large NBFCs, the RBI MD IT Governance chapter on IT Service Continuity is the binding requirement.
• Establish the BCM management tooling, BCM/GRC software (for the inventory, the BIA, the plans, the exercises, the corrective actions), the dashboard (for KPI reporting), the crisis-notification platform (for workforce mobilisation), the decision-log tool (for incident-command recording).
• Establish the communication and collaboration tooling, voice conferencing, video conferencing, instant messaging, out-of-band email, satellite communication, with diversity (no single-vendor dependency for crisis comms).
• Maintain the asset and configuration inventory, the CMDB is the technology counterpart of the resource inventory and is the basis for technology resourcing decisions.
• Provide the test and exercise infrastructure, the test environment, the data-masking capability, the parallel-run infrastructure, that the feasibility test depends on.

Infrastructure resourcing. The infrastructure dimension covers facilities and environment. Implementation guidance:

• Establish the data centre and colocation footprint, primary DC, secondary DC, edge locations, cloud regions, with documented tier (TIA-942 / Uptime Institute), capacity (rack, square-foot, kVA), and contractual SLA.
• Establish the work-area recovery, contracted seats at a third-party recovery provider (the typical pattern for Indian growing companies), with documented seat count, activation SLA (typically 4 to 24 hours), and test evidence.
• Establish the alternate-site strategy, own-build, leased, contracted, or reciprocal, aligned with the BIA-derived RTO and the NDMA / sector-regulator expectations.
• Provide the power and telecom resilience, UPS, genset, fuel contracts, dual-grid supply where available, diverse last-mile telecom (two distinct providers, plus mobile and satellite for critical functions).
• Provide the workforce-access continuity, transport arrangements (for disruptions that close public transport), accommodation arrangements (for disruptions that displace staff), family-safety arrangements (for disruptions that distract staff), these are the people-side of infrastructure and are often the difference between a recovery that works and one that fails.

Financial resourcing. The financial dimension funds the other four. Implementation guidance:

• Build the multi-year BCMS Budget Plan with the OpEx/CapEx split, the multi-year horizon (typically 3 to 5 years), and the explicit linkage to BCMS objectives. The plan is the principal financial 7.1 artefact.
• Defend the BCM budget line in the enterprise budget cycle, the BCM Manager presents the budget to the CFO and top management, with the capability gap assessment as justification. A BCM budget that is "whatever was left over" is a Clause 5.1 failure.
• Establish the contingency reserve for disruption-driven spend, typically 1 to 5 times the annual OpEx, depending on the organisation's risk appetite and the regulator's expectations.
• Buy the BI / cyber / crime / D&O insurance, with documented cover, sub-limits, waiting periods, exclusions, and insurer-required risk treatments. Insurance is a financial resource that funds recovery, but it is also a Clause 6.1 risk treatment and a Clause 8.3 strategy option.
• Provide the corrective-action and improvement budget, the spend that 10.1 corrective actions and 10.2 improvement initiatives require. An organisation that has no budget for corrective action is nonconformant at the moment it needs to act on an audit finding or an incident lesson.

Information and external-services resourcing. The information dimension covers documented information, data, supplier services and external relationships. Implementation guidance:

• Maintain the documented information set (Clause 7.5), BIA, strategy, plans, contact trees, exercise reports, audit reports, management-review minutes, with version control, access control, and the off-site / off-platform copies that survive a primary-site failure.
• Maintain the supplier-continuity contracts, the cloud HA agreements, the managed DR contracts, the SaaS SLAs, the mutual-aid agreements, the work-area-recovery subscriptions, each with documented BCMS dependency, RTO/RPO alignment, right-of-audit, and exit provisions.
• Maintain the regulator PoC relationships, the named contacts at RBI (for banks), SEBI (for MIIs and other REs), IRDAI (for insurers), CERT-In (for all), NDMA (for industrial operators), and the DPDP Data Protection Board (for significant Data Fiduciaries). The PoC is a resource because the 6-hour CERT-In clock and the 24-hour CPS 230 clock are un-meetable without a pre-existing relationship.
• Engage retained external advisers, legal counsel, technical forensics, crisis communications agency, insurance broker, medical adviser, psychological-first-aid provider, each on retainer or pre-qualified for rapid engagement.
• Maintain the mutual-aid agreements, reciprocal arrangements with peer organisations (typically through sector associations or industrial clusters) for shared response resources. MAAs are particularly important for chemical, manufacturing and utilities sectors per NDMA guidelines.

Tools, Technologies, and Solutions

The 7.1 tooling landscape spans five categories. The categories are described at the category level (per the IP-and-sourcing rules that govern this series, no vendor names in output). Within each category, the practitioner should evaluate Indian + global options against documented criteria, not brand reputation.

BCM / GRC platforms (the system of record)

A BCM/GRC platform is the system of record for the resource inventory, the BIA, the strategy, the plans, the exercises, the corrective actions and the KPIs. The platform is the natural home for the BCMS Resource Inventory ( artefact c in Section 1), the Capability Gap Assessment (artefact d), and the KPI dashboard (artefact in Section 12). For Indian growing companies, a BCM/GRC platform is typically the right investment at the upper end of the 250-to-2,000-staff band; below that, a well-managed spreadsheet is conformant. Evaluation criteria: (a) BCM-specific depth (BIA, plans, exercises) vs generic GRC; (b) India-region availability and data-residency; (c) integration with the ITSM/ITIL platform, the HR system, and the IT asset inventory; (d) audit-trail and Clause 7.5 documented-information features; (e) reporting and dashboard flexibility; (f) total cost of ownership including implementation and ongoing administration.

Illustrative third-party cost ranges (category-level, not vendor-specific): BCM/GRC platforms for growing Indian organisations typically range from ₹15 lakh to ₹80 lakh per year subscription plus ₹20 lakh to ₹100 lakh one-time implementation. Enterprise-tier platforms for multi-entity financial-sector organisations can exceed ₹2 crore per year. The implement-or-not decision should be a function of BCMS scope, complexity and maturity, not of vendor marketing.

Crisis-notification and mass-communication platforms

A crisis-notification platform is the tool that alerts, mobilises and coordinates the response workforce during a disruption. For most Indian growing companies, this is a SaaS subscription with multi-channel capability (SMS, voice, email, app push, RSS), contact-database management, two-way acknowledgement, conference-bridge integration, and reporting. The crisis-notification platform is a 7.1 resource because it is the operational form of Clause 7.4 communication during a disruption.

Illustrative cost ranges: ₹3 lakh to ₹25 lakh per year subscription for a mid-market deployment, scaling with seat count, message volume and channel mix. Some Indian organisations use the mass-notification capability embedded in their BCM/GRC platform; others use a standalone best-of-breed service.

DRS, backup and recovery infrastructure

DRS and backup infrastructure is the technology class that delivers the recovery capability. The choice architecture spans:

• Own-build DRS, the organisation builds and operates a secondary DC. Highest control, highest cost (CapEx-heavy), longest time-to-establish, suitable for large enterprises with sovereign or sector-specific requirements (banks, MIIs, government).
• Colocation DRS, the organisation owns the technology but houses it in a third-party DC. Medium cost, medium control, suitable for growing organisations with a defined recovery architecture.
• Managed DR service, a managed-service provider operates the DRS on the organisation's behalf, typically with an RTO/RPO-bearing SLA. Lower cost (OpEx), lower control, suitable for growing companies without a deep 24x7 infrastructure team.
• Cloud DRS / DRaaS, the recovery runs in a public cloud (hyperscaler or India-region cloud). Lowest cost (pay-per-use), highest elasticity, suitable for cloud-native and hybrid organisations.
• Near Site (MII-specific), low-latency secondary site for transaction-processing systems, per SEBI MII BCP-DR. Specialised requirement, not applicable outside MIIs.

Illustrative cost ranges (India-region, category-level): Managed DR service for a mid-tier critical workload typically ranges from ₹15 lakh to ₹80 lakh per year; Cloud DRaaS for a cloud-native workload typically ranges from ₹8 lakh to ₹50 lakh per year depending on capacity and replication profile; own-build DRS for a 200-rack secondary DC typically involves ₹15 crore to ₹60 crore CapEx plus ₹3 crore to ₹10 crore annual OpEx. Backup platform licences (category-level) typically range from ₹15 lakh to ₹1.5 crore per year for mid-market, scaling with capacity and feature set.

Work-area recovery and alternate-site services

Work-area recovery is the contracted alternate-facility service for workforce relocation. For most Indian growing companies, the typical pattern is a contracted seat-capacity at a third-party recovery provider, with an activation SLA (typically 4 to 24 hours) and a contracted test programme (typically one or two live activations per year). The work-area recovery contract is a 7.1 resource because it is the operational form of Clause 8.3 strategy for the people-and-premises dimension.

Illustrative cost ranges: contracted work-area recovery for a 50-seat allocation typically ranges from ₹6 lakh to ₹25 lakh per year subscription; for 200 seats, from ₹20 lakh to ₹80 lakh per year. Costs vary by city (Mumbai and Delhi premium; Pune, Hyderabad, Chennai, Kolkata progressively lower), by activation SLA (4-hour premium vs 24-hour standard), and by included services (desktop, telephony, conferencing, catering, parking).

BCM consulting, audit and training services

Professional services are the people-class resource that supplements internal capacity. The services span:

• BCM programme consulting, for the design and build phase (establish the BCMS, run the first BIA, draft the strategy, write the plans, run the first exercise). Typical Indian engagement: ₹15 lakh to ₹80 lakh over 6 to 12 months for a growing organisation.
• Internal-audit-as-a-service, for organisations without an in-house BCMS-audit capability. Typical Indian engagement: ₹3 lakh to ₹15 lakh per audit cycle.
• Exercise facilitation, for the annual full-failover exercise or the threat-led penetration test (TLPT, per DORA Article 26 for in-scope entities). Typical Indian engagement: ₹5 lakh to ₹30 lakh per exercise.
• Training, ISO 22301 Lead Implementer, Lead Auditor, BCI certification courses (CBCI, MBCI), DRI certification (CBCP, MBCP). Typical Indian course fee: ₹40,000 to ₹1,20,000 per participant per course.
• Specialist retainers, legal counsel, technical forensics, crisis communications, insurance broking, medical adviser. Retainer patterns vary widely; budget ₹2 lakh to ₹15 lakh per year per specialist for a mid-market engagement.

The selection methodology, a category-level framework

For each tool category, the selection methodology should be documented and reproducible. A practitioner framework (used by Singahi in client engagements, adaptable to any organisation):

1. Define the requirements. What BCMS clauses does the tool support? What scale (FTE, transaction volume, data volume)? What India-specific requirements (data-residency, language, regulator-reporting)? What integration (ITSM, HR, IT asset inventory)?
2. Define the evaluation criteria. Typically weighted across: functional fit (40%), India presence and support (15%), total cost of ownership over 5 years (20%), implementation risk (10%), vendor viability (10%), customer-reference base (5%).
3. Build the long list. Category-level research (per Section 8 above) to identify 5 to 10 candidate vendors per category.
4. Issue an RFI/RFP. Standardised template across candidates.
5. Short-list to 3. Score against criteria; eliminate the rest.
6. Run proofs-of-concept. A 4 to 8 week PoC per short-listed vendor, on a representative slice of the BCMS workload.
7. Reference calls. At least two reference calls per short-listed vendor, ideally with Indian or regional customers.
8. Negotiate and contract. Pay attention to SLAs (with credits), exit clauses, data-portability, audit rights, India-jurisdiction provisions.
9. Implement with governance. A documented implementation project with milestones, change management, training, and a 30/60/90-day stabilisation period.

Policy and Procedure Templates

The 7.1 policy and procedure set is the apex evidence of the resourcing discipline. The set is reproduced (in ready-to-customise form) in the toolkit that accompanies this guide; the principal documents are summarised here.

BCMS Resource Management Policy (the apex policy)

The apex 7.1 policy is approved by top management, linked to the BCMS policy (Clause 5.2) and the enterprise budget cycle, and states the organisation's commitment to resourcing the BCMS. The policy includes (sample "shall" clauses of Singahi's drafting, these are not reproductions of any standard's text):

• Scope and purpose. "[Organisation Name] shall maintain a BCMS resourced to meet its business continuity policy commitments, its BCMS objectives, and its legal and regulatory obligations, including the RBI Master Direction on IT Governance, the SEBI CSCRF, the IRDAI Information and Cyber Security Guidelines, the CERT-In Directions, the DPDP Act 2023, and the NDMA Disaster Management Act 2005 as applicable to [Organisation Name]."
• Resource classes. "[Organisation Name] shall identify, commit and maintain BCMS resources across five classes: people, technology, infrastructure, financial, and information/external services."
• Demand-driven resourcing. "BCMS resources shall be sized to meet the demand derived from the BIA, the BC strategy, the BC plans, the BCMS objectives, the risk register, and the applicable regulatory landscape. Resourcing decisions shall be evidence-based and shall be reviewed against the Capability Gap Assessment at every management review."
• Top-management commitment. "Top management shall fund the BCMS through a defended budget line in the enterprise budget cycle. The CFO shall present the BCMS budget to the BCM Steering Committee and to top management for approval. The BCM Manager shall defend the budget with the Capability Gap Assessment and the feasibility-test results."
• Inventory and gap assessment. "The BCM Manager shall maintain the BCMS Resource Inventory as a controlled document per Clause 7.5. The BCM Manager shall run the Capability Gap Assessment at least annually and after every BIA revision, strategy revision, regulatory shift, or major organisational change."
• Feasibility test. "The BCMS resourcing shall be validated at least annually through an exercise that demonstrates the committed resources can meet the BIA-derived RTO/RPO/MBCO. The exercise results shall be reported to top management."
• Roles and authorities. "Top management retains accountability for funding the BCMS. The CFO owns the BCMS budget line. The CIO owns the technology resourcing. The Head of Operations owns the work-area recovery and operational-continuity resourcing. The Head of HR owns the people resourcing. The Head of Procurement owns the supplier-resourcing contracts. The BCM Manager owns the inventory and the gap assessment."
• Continual improvement. "The BCMS resourcing shall be continually improved per Clause 10.2, with maturity advancement targets reviewed annually."

BCMS Resource Management Procedure

The procedure operationalises the policy into the seven-stage workflow described in Section 7. Each stage has named owners, inputs, outputs, decision rights, evidence requirements, and timelines. The procedure is the operational hand-book for the BCM team and the cross-functional resourcing stakeholders.

Supporting artefacts

The supporting artefacts in the toolkit include: the BCMS Resource Inventory template (with the five-class structure, owner field, cost band, lifecycle stage, renewal date, BCMS dependency); the Capability Gap Assessment template (demand-vs-supply comparison with finding, root-cause, treatment, owner, deadline); the DRS and Alternate-Site Costing Model (BIA-derived RTO/RPO → tier-of-service → INR price tag → decision); the BCMS Budget Plan template (OpEx/CapEx, multi-year horizon, linked to objectives); the Feasibility Test template (exercise scenario, target RTO/RPO, achieved RTO/RPO, gap analysis, sign-off); the Escalation Provision template (surge triggers, named authorities, cash reserve, emergency-contracting procedure, mutual-aid invocation).

Risk Assessment and Treatment

Resource-related risks are a first-class category on the BCMS risk register per Clause 6.1. The 7.1 risk assessment identifies the resource-shortfall risks that could prevent the BCMS from meeting its commitments, assesses them, and treats them.

Resource-risk taxonomy

The resource-risk taxonomy spans five families, mirroring the five resource classes:

• People risks: SPOF roles (single BCM Manager with no deputy); key-person dependency (the only person who knows the DRS runbook leaves); competence shortfall (the BCM team lacks BIA facilitation skills); succession gap (the CMT Chair retires with no successor); surge capacity (the crisis-response roster is too thin for a multi-day disruption); workforce access (staff cannot reach the alternate site in a flood).
• Technology risks: DRS SLA exceeds BIA RTO (24-hour-SLA DRS for a 4-hour-RTO activity); backup immutability missing (backups can be encrypted by ransomware); capacity shortfall (the DRS cannot carry peak load); licensing shortfall (the BCM/GRC platform is licensed below the workforce size); single-vendor concentration (all continuity capability on one cloud); untested failover (the DRS has never been exercised).
• Infrastructure risks: Geographic concentration (primary and DRS in the same seismic zone); power resilience gap (no genset or expired fuel contract); telecom diversity gap (single last-mile provider); work-area-recovery shortfall (no WAR contract for a flood-prone primary office); access logistics (no transport plan for staff displacement).
• Financial risks: Budget line dispersed and un-defended (no identifiable BCM budget); contingency reserve absent (no surge fund for disruption-driven spend); insurance gap (no BI cover, or sub-limits below the BIA's worst-case); corrective-action budget absent (no reserve for audit-finding remediation); currency risk (DRS contract in USD with no hedge).
• Information/external risks: Documented information single-copy (only one copy of the plans, in the primary office); supplier-continuity contract gap (cloud provider has no BC/DR SLA); mutual-aid lapsed (the MAA expired and was not renewed); regulator-PoC relationship absent (no pre-existing contact at CERT-In for the 6-hour clock); retained-adviser gap (no pre-qualified crisis-comms agency for a public incident).

Risk treatment patterns

Each resource risk is treated with one of four patterns: avoid (eliminate the risk, e.g., appoint a deputy for the SPOF role), transfer (transfer the risk, e.g., buy BI insurance, contract a managed-DR service with SLA), mitigate (reduce the risk, e.g., add a second last-mile telecom provider), or accept (accept the risk, e.g., accept the cost of a single-vendor concentration as a documented top-management decision). Treatments are recorded on the risk register with owner, deadline, and treatment-effectiveness review.

The demand-side risk: under-resourcing

The most consequential 7.1 risk is systematic under-resourcing, the organisation has committed to BCMS objectives (RTO, RPO, MBCO, MTPD) that exceed its resourced capability, and the gap is invisible because no capability assessment has been run. The treatment is the demand-vs-supply assessment itself, plus a top-management acknowledgement of the gap and a funded remediation plan. An under-resourcing gap that is identified, risk-assessed and either remediated or accepted is conformant; an under-resourcing gap that is invisible is nonconformant regardless of size.

Audit and Compliance Checklist

The certification auditor (and the regulator after a disruption) will examine Clause 7.1 through a structured set of questions, each expecting specific evidence. The checklist below contains 28 questions, each with the expected evidence and the typical red flag.

1. Is there a BCMS Resource Management Policy approved by top management? Evidence: the policy document with signatures; the BCM Steering Committee minute approving it; the linkage to the BCMS policy and the enterprise budget. Red flag: no policy, or a policy unsigned.
2. Is there a BCMS Resource Management Procedure defining the seven-stage workflow? Evidence: the procedure document with named owners, inputs, outputs, decision rights, evidence requirements. Red flag: no procedure, or a procedure with no named owners.
3. Is there a BCMS Resource Inventory? Evidence: the inventory (spreadsheet or platform), controlled per Clause 7.5, with version control. Red flag: no inventory, or an inventory that is clearly out of date.
4. Does the inventory cover all five resource classes (people, technology, infrastructure, financial, information/external)? Evidence: inventory structure with the five classes represented. Red flag: a partial inventory that omits, e.g., financial or information/external.
5. Does each inventory line have a named owner? Evidence: inventory with the Owner field populated by a named individual (not a role label). Red flag: Owner field reading "IT" or "Management".
6. Does each inventory line have a cost band? Evidence: inventory with Cost band (typically INR ranges) populated. Red flag: missing cost data, suggests the inventory is not actually used for budget decisions.
7. Does each inventory line have a renewal date? Evidence: inventory with Renewal date populated. Red flag: missing renewal data, suggests lapsed contracts are a risk.
8. Does each inventory line have a documented BCMS dependency? Evidence: inventory with BCMS dependency field (which BIA activity, which strategy, which plan). Red flag: inventory with no dependency field, suggests the inventory is not actually tied to BCMS demand.
9. Is there a Capability Gap Assessment? Evidence: the assessment document, refreshed annually. Red flag: no assessment, or an assessment older than one year.
10. Does the gap assessment compare demand and supply line by line? Evidence: the assessment with the demand-vs-supply comparison. Red flag: a qualitative "we think we're OK" statement with no line-by-line analysis.
11. Are the gaps classified by treatment (close, accept, transfer, mitigate)? Evidence: the assessment with treatment column populated. Red flag: gaps listed but with no treatment.
12. Are the accepted gaps on the risk register with top-management acknowledgement? Evidence: the risk register entries with top-management sign-off (BCM Steering Committee minute). Red flag: gaps accepted by the BCM Manager alone with no top-management traceability.
13. Is there a multi-year BCMS Budget Plan? Evidence: the budget plan document with the OpEx/CapEx split and the multi-year horizon. Red flag: no budget plan, or a plan that is just the current-year OpEx line.
14. Is the BCMS budget line identifiable in the enterprise budget? Evidence: the enterprise budget with the BCM line(s) traceable. Red flag: BCM spend dispersed across IT, Operations, HR, Finance with no consolidated view.
15. Is the BCM budget defended annually with the capability gap assessment as justification? Evidence: the BCM Steering Committee minute where the BCM Manager presented the budget with the gap assessment. Red flag: a budget that is "whatever was last year plus inflation".
16. Is there a DRS or recovery-infrastructure contract with an RTO/RPO-bearing SLA? Evidence: the contract with the SLA clauses. Red flag: a DRS contract with no SLA, or an SLA that exceeds the BIA RTO.
17. Does the DRS SLA meet the BIA RTO? Evidence: the BIA RTO figure; the DRS SLA figure; a comparison statement. Red flag: DRS SLA exceeds BIA RTO.
18. Is there a work-area recovery or alternate-site arrangement? Evidence: the contract or the MAA. Red flag: no alternate-site arrangement for an organisation whose primary site is in a flood- or seismic-prone area.
19. Is there a BCM team with named individuals and qualified alternates? Evidence: the HR establishment for BCM roles; the alternates list. Red flag: a single BCM Manager with no deputy, or a BCM role unfilled for >6 months.
20. Are the SPOF BCM roles identified and either closed or accepted as risks? Evidence: the SPOF role analysis; the closures (deputy appointed, cross-training completed) or the risk-register entries. Red flag: no SPOF analysis.
21. Has a feasibility test (exercise) been run within the last 12 months demonstrating that the committed resources can meet the BIA RTO/RPO? Evidence: the exercise report with target vs achieved RTO/RPO. Red flag: no exercise in the last 12 months, or an exercise that did not measure RTO/RPO.
22. Were the gaps identified in the last feasibility test fed back into the capability assessment and the corrective-action pipeline? Evidence: the corrective-action log entries derived from the exercise. Red flag: an exercise report with findings but no corrective actions.
23. Is there a crisis-notification platform or equivalent, with the contact database tested within the last 6 months? Evidence: the contract or platform records; the test log. Red flag: a contact tree that has not been tested in the last 6 months.
24. Is there a contingency reserve or escalation provision for disruption-driven spend? Evidence: the finance record of the contingency reserve; the escalation procedure. Red flag: no contingency reserve, suggests the organisation cannot fund emergency response.
25. Is there BCM-relevant insurance (BI, cyber) with documented cover and exclusions? Evidence: the insurance policy schedule; the exclusions analysis. Red flag: no BI or cyber cover, or cover with broad exclusions that effectively nullify the indemnity.
26. Are the supplier-continuity arrangements (cloud SLA, managed-DR contract, WAR subscription) documented and tested? Evidence: the supplier contracts with BC clauses; the supplier-test evidence (right-of-audit exercised, or supplier-supplied test report). Red flag: supplier contracts with no BC clauses, or supplier-test evidence never sought.
27. Are the regulator-PoC relationships documented (named contacts at RBI/SEBI/IRDAI/CERT-In as applicable)? Evidence: the PoC register; the last interaction log. Red flag: no PoC register, or stale contacts (>12 months since last interaction).
28. Is the resource portfolio a standing input to the management review (Clause 9.3)? Evidence: the management-review pack with the 7.1 section; the minute capturing top-management discussion of resourcing. Red flag: a management review that does not include 7.1 input.

Metrics and KPIs

The 7.1 KPI set spans four dimensions (volume, quality, outcome, integration) and is reported on the BCM dashboard reviewed monthly by the BCM Manager, quarterly by the BCM Steering Committee and annually at the management review. The 15 KPIs below are the practitioner set; adapt the targets to the organisation's maturity and sector.

Volume KPIs (capacity and spend)

1. Total BCMS OpEx (₹). Annual OpEx run cost across the five resource classes. Target: trend against the budget plan; flag variance >10%.
2. Total BCMS CapEx (₹). Annual CapEx programme spend. Target: trend against the budget plan; flag variance >15%.
3. BCM-team FTE-equivalents. Total FTE-equivalent committed to the BCM team (including the BCM Manager, coordinators, and the BCM share of cross-functional roles). Target: meets the demand derived from the scope and objectives.
4. Inventory line count by class. Count of inventory lines in each of the five classes. Target: growth aligned with BCMS scope growth; flag any class shrinking without justification.

Quality KPIs (gap management and SLA achievement)

5. Gap-closure rate (%). Of the gaps identified in the last capability assessment, the percentage closed (resource committed) within the agreed deadline. Target: ≥80% within deadline.
6. Open-gap count by treatment. Number of open gaps, classified by treatment (close, accept, transfer, mitigate). Target: accepted gaps have top-management sign-off; closing gaps have a funded plan.
7. Supplier-SLA achievement (%). Of the BCMS-relevant supplier SLAs (DRS RTO/RPO, WAR activation, managed-DR response), the percentage achieved in the last test. Target: 100%.
8. Inventory freshness (months). Average age of inventory-line last-validation. Target: ≤6 months across the inventory.

Outcome KPIs (feasibility and incident performance)

9. Feasibility-test pass rate (%). Of the BIA RTO/RPO commitments tested in the last exercise, the percentage met with the committed resources. Target: 100%; any failure triggers a corrective action.
10. Resourcing-driven incident rate (%). Of the BCMS-relevant incidents in the period, the percentage where resourcing shortfall was a root cause. Target: trending down; zero over time.
11. Resourcing-driven audit-finding rate (%). Of the 7.1 audit findings, the percentage that are repeat findings from the prior cycle. Target: zero repeat findings.
12. Resource-availability-on-activation (%). Of the resources activated in the last real or exercised disruption, the percentage that were available and functional when invoked. Target: 100%.

Integration KPIs (cross-clause alignment)

13. Budget-vs-actual variance (%). Variance of actual BCM spend against the budget plan, reviewed quarterly. Target: within ±10%.
14. Objective-achievement-vs-resourcing correlation. Qualitative review of whether BCMS objectives (Clause 6.2) met in the period correlate with resourcing levels. Target: positive correlation, under-resourced objectives are flagged for either re-resourcing or re-targeting.
15. Exercise-failure-vs-resourcing-gap correlation. Qualitative review of whether exercise failures (Clause 8.5) correlate with known resourcing gaps. Target: positive correlation, exercise failures trace to known gaps and drive corrective actions.

The KPI dashboard is the operational form of Clause 9.1 monitoring applied to 7.1. Each KPI has a formula, a target, a frequency, an owner, and a reporting destination (BCM dashboard, BCM Steering Committee pack, management-review pack).

Common Pitfalls and Audit Failures

The 7.1 nonconformities most commonly seen in Indian growing-company audits are concentrated in ten patterns. Each is named (memorably), explained, and paired with the corrective pattern.

1. The Goodwill BCMS. The BCMS depends on informal commitments, "Operations will lend us five people", "IT has spare DRS capacity", "the BCM Manager will handle it personally". The goodwill is real on a normal day and evaporates on a disruption day when Operations and IT are dealing with their own continuity. Correction: convert every goodwill commitment into a contracted, named, evidenced resource line in the inventory.

2. The Part-Time BCM Manager. The BCM role is a part-time assignment for someone with a day job (often the CISO, the IT Manager, or the Compliance Head). The BCMS work is squeezed into the cracks of the day job and is the first thing dropped when the day job heats up. Correction: size the BCM role to the BCMS scope. A bank needs a full-time BCM Manager plus deputies; a 200-person SaaS firm may legitimately have a 0.5 FTE BCM Manager, but the time must be calendared, defended and reported.

3. The DRS SLA Mismatch. The BIA sets a 4-hour RTO; the DRS contract is on a 24-hour SLA; nobody has noticed. The mismatch is invisible until a disruption, when the BCMS fails on the day it is activated. Correction: compare the BIA RTO against the DRS SLA in the capability assessment; close or accept the gap explicitly.

4. The Paper Feasibility. The BCMS documentation claims the resources are sufficient, but no exercise has ever tested the claim. The "feasibility" is asserted, not demonstrated. Correction: run the annual feasibility test (the Clause 8.5 exercise) with explicit RTO/RPO measurement and feed the results into the capability assessment.

5. The Dispersed Budget. BCM spend is scattered across IT (DRS), Operations (WAR), HR (BCM team), Legal (retained counsel), Insurance (BI cover) and Finance (contingency reserve), with no consolidated view. Top management cannot answer "what do we spend on BCM?". Correction: build the consolidated BCMS Budget Plan and present it annually to top management.

6. The Stale Inventory. The inventory was accurate once but has drifted through turnover, contract changes, technology migrations and budget cuts. The BCMS documentation describes a resourced capability that no longer exists. Correction: institute the monthly inventory review by the BCM Manager, the quarterly review by the BCM Steering Committee, and the annual review at the management review.

7. The SPOF BCM Manager. The BCM Manager is the only person who knows the BCMS, the inventory, the contacts, the runbooks. When the BCM Manager leaves (and they do, BCM Managers are scarce in India and turnover is high), the BCMS goes with them. Correction: appoint a deputy; cross-train; document the BCMS in a way that survives the BCM Manager.

8. The Untested Supplier Continuity. The cloud provider, the managed-DR vendor, the WAR provider all have BC/DR clauses in their contracts. None has ever been tested. Correction: exercise the supplier-continuity clauses, invoke the WAR provider for a test activation, request the cloud provider's BC/DR test report, audit the managed-DR vendor.

9. The Missing Regulator PoC. The CERT-In 6-hour clock is un-meetable because no pre-existing PoC relationship exists. The first time the organisation speaks to CERT-In is the day it has to report an incident. Correction: establish the PoC relationships proactively; participate in CERT-In / sector-regulator / sector-CERT exercises and forums.

10. The Cosmetic Maturity. The organisation claims a high 7.1 maturity ("we have a BCM/GRC platform!") but the underlying discipline (the gap assessment, the feasibility test, the management-review trail) is absent. The maturity claim is decoration, not substance. Correction: maturity is what the evidence shows, not what the marketing claims. Benchmark the maturity against the L1–L5 model in Section 22 and address the gaps honestly.

Illustrative Scenario 1: Failure, Konkan Specialty Chemicals Limited (Illustrative)

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

Disclaimer: The following scenario is illustrative. It does not describe any specific real company or incident; it is a composite drawn from publicly-documented patterns in the Indian chemical-manufacturing sector (LG Polymers Vizag 2020; multiple ransomware-impacted manufacturers) and is constructed for teaching purposes. All names, figures and timelines are illustrative.

The organisation

Konkan Specialty Chemicals Limited (KSCL, illustrative) is a mid-sized (≈680 staff, ≈₹420 crore annual revenue) manufacturer of specialty resins and intermediates with a single integrated plant in a coastal Maharashtra industrial estate. KSCL is a Major Accident Hazard (MAH) unit under the NDMA Chemical Disasters Guidelines 2007 and is regulated by the State Pollution Control Board, the Factory Inspectorate, and (for the corporate entity) the Ministry of Corporate Affairs. The plant runs a 24x7 OT environment (DCS, SCADA, safety instrumented systems) integrated with an ERP and a quality-lab system on the IT side.

The BCMS as documented

KSCL's BCMS documentation is a 90-page binder produced two years earlier by a brief consultancy engagement (₹8 lakh, three-month duration). It includes a BCMS policy, a BIA identifying the production line and the order-to-cash cycle as the prioritised activities (RTO 7 days for production; RTO 48 hours for order-to-cash), a BC strategy document (warm-cold DRS at the corporate office in Mumbai ≈250 km away; manual workaround for order-to-cash), a set of BC plans, an on-site emergency plan (per NDMA Chemical Disasters Guidelines), and an exercise schedule (annual tabletop, biannual evacuation drill).

The resourcing reality

The BCMS documentation describes a recovery capability. The resourcing reality is sharply different:

• People. The BCM role is a part-time assignment for the IT Manager (who is also the CISO, the OT lead, and the procurement-system owner). There is no BCM Coordinator, no deputy, no crisis-communications lead. The on-site emergency control room staff is a paper roster; the last training was at BCMS go-live.
• Technology. The "DRS" is a single rack at the corporate office Mumbai that houses a year-old backup of the ERP. The OT environment has no DRS, the BIA's 7-day production RTO assumed a manual restart that has never been tested. Backups are daily, on a NAS in the plant server room, with a weekly tape copy stored in the IT Manager's Mumbai apartment.
• Infrastructure. The plant's UPS supports the server room for 30 minutes; the genset supports critical OT for 8 hours (fuel contract expired four months ago). The corporate office Mumbai is in a flood-prone low-rise; the single rack has no separate power or environmental protection.
• Financial. There is no identifiable BCM budget line in the enterprise budget. The ₹8 lakh consultancy was the last identifiable BCM spend. The annual tabletop has been cancelled twice in two years "for cost reasons". There is no BI insurance specific to cyber or ransomware (the property policy has a ₹5 crore BI sub-limit for physical events only). There is no contingency reserve for disruption-driven spend.
• Information/external. The mutual-aid agreement with the neighbouring chemical cluster (foam, medical, evacuation) was a one-page MoU signed at BCMS go-live and never refreshed. There is no retained crisis-communications agency; no retained technical-forensics firm; no pre-existing relationship with CERT-In (the IT Manager would not know whom to call).

The disruption

On a Saturday in late monsoon, two events coincide. A ransomware actor (suspected initial access via a phishing email to a finance user two weeks earlier, lateral movement to the ERP and the OT-IT bridge) encrypts the ERP, the quality-lab system, and the OT-IT bridge systems. Simultaneously, a heavy-monsoon downpour triggers a partial flooding of the plant's lower yard, restricting road access for the morning shift. The DCS and SIS are unaffected (segmentation held), but the integrated ERP-to-OT production-scheduling workflow is down.

The BCMS activation and the resourcing failure

The IT Manager (concurrently BCM Manager, CISO, OT lead) is at home in Mumbai, reachable but unable to travel for 36 hours due to flooding in his locality. The CEO activates the BCMS by phone. The next 11 days expose every resourcing shortfall:

• Day 0 (Saturday). The plant continues to run on existing work orders but cannot schedule new ones. The order-to-cash cycle is dark. The IT Manager, working remotely, discovers the backups on the plant NAS are also encrypted (the ransomware reached them through the same IT-OT bridge), and the corporate office Mumbai rack is a year-old backup that does not include the last 12 months of ERP schema changes, the restoration fails on schema mismatch. The IT Manager has no retained forensics firm to call; he triages alone.
• Day 1–2 (Sunday–Monday). The CEO tries to notify CERT-In within the 6-hour clock; the IT Manager does not have a PoC and spends the day navigating the CERT-In portal. The State Pollution Control Board and the Factory Inspectorate are notified on Day 2; the corporate-office Mumbai flood (the rack's room has taken water) is not yet known.
• Day 3–5 (Tuesday–Thursday). A forensics firm is finally engaged (a Mumbai firm with no prior relationship, premium rates, mobilisation in 48 hours). The corporate office rack is declared unusable (water damage). The decision is taken to rebuild the ERP from a year-old backup and re-key 12 months of transactions manually, a decision that will take 11 days of accounting-team overtime.
• Day 6–11 (Friday–Wednesday). Production continues on existing work orders but new orders cannot be accepted; the order book bleeds. Customer notifications are handled by the sales team ad-hoc; one Tier-1 automotive customer invokes a force-majeure clause and switches to an alternate supplier. The insurer declines the cyber claim (no cyber cover; property policy excludes cyber). The IT Manager works 18-hour days; on Day 8 he announces his resignation.

The impact

• Revenue: ≈₹38 crore in lost and deferred revenue over the 11-day ERP outage and the following 30-day recovery tail (≈9% of annual revenue).
• Customer churn: Two Tier-1 customers (≈₹45 crore annual combined) either switch suppliers or reduce KSCL's share-of-wallet.
• People: The IT Manager resigns; the IT team loses three of seven members in the following six months; the corporate-office Mumbai office is closed for two months for flood remediation.
• Regulator: The State Pollution Control Board issues a show-cause; the Factory Inspectorate requires an independent BCMS audit as a condition of continued operation; the corporate entity faces a CERT-In escalation for the late notification.
• Total financial impact: Estimated at ≈₹65–75 crore direct and indirect over 18 months, roughly 80 times the cumulative BCM budget of the prior two years.

The lessons (Clause 7.1 root causes)

Every Clause 7.1 failure mode is on display:

1. Goodwill resourcing, the BCMS depended on the IT Manager personally; there was no deputy.
2. Under-budgeted BCMS, there was no identifiable BCM budget line; the annual tabletop had been cancelled.
3. Untested resourcing, the "DRS" had never been exercised; the schema-mismatch gap was discovered on the day.
4. Stale resourcing, the MAA was a one-page MoU at go-live; the mutual-aid never refreshed.
5. Single-vendor concentration, backups in the plant server room, on the same IT-OT bridge, in the same corporate office building as the "DRS".
6. Missing regulator PoC, the 6-hour CERT-In clock was missed because no PoC existed.
7. Missing specialist retainers, the first call to a forensics firm happened during the incident; 48-hour mobilisation at premium rates.
8. Insurance gap, no cyber cover; property policy excluded cyber.

The 7.1 evidence that would have prevented the failure: a defended BCM budget line (≥₹50–80 lakh per year for an organisation of this size and risk profile); a deputy BCM Manager; a contracted DRS with an RTO/RPO-bearing SLA and immutable backups in a different geography; an annual feasibility test with RTO/RPO measurement; a retained forensics firm and crisis-communications agency on standby; a CERT-In PoC relationship; cyber insurance with documented cover. The cost of building this evidence is roughly 1% of the failure's financial impact.

Illustrative Scenario 2: Success, Sharda Payments Limited (Illustrative, with ROI)

Disclaimer: The following scenario is illustrative. It does not describe any specific real company or incident; it is a composite drawn from publicly-documented patterns in the Indian payments / fintech sector (the NPCI/UPI ecosystem resourcing expectations, SEBI CSCRF-adjacent expectations for non-bank PPIs, the general RBI Master Direction on Outsourcing of IT Services resourcing expectations) and is constructed for teaching purposes. All names, figures and timelines are illustrative.

The organisation

Sharda Payments Limited (Sharda, illustrative) is a mid-market (≈420 staff, ≈₹310 crore annual revenue) non-bank Prepaid Payment Instrument (PPI) issuer and B2B payments processor regulated by the Reserve Bank of India under the Payment and Settlement Systems Act 2007 and the RBI Master Direction on Outsourcing of IT Services (10 April 2023). Sharda's core platform processes wallet loads, merchant settlements, KYC, reconciliation, and customer service for ≈3.2 crore wallet holders and ≈18,000 merchants. The platform is cloud-native (a hyperscaler's Mumbai region) with a small colocated edge for low-latency routing.

The challenge

In 2024, three forces converge on Sharda:

• A Tier-1 bank customer (a large private bank whose name is illustrative) issues an RFP for a white-label PPI partner; the RFP includes BC/DR clauses requiring a 2-hour RTO, 15-minute RPO, quarterly drill participation, and right-of-audit on the partner's BCMS. Winning the contract is worth ≈₹28 crore per year.
• RBI (illustratively through supervisory dialogue) signals an upcoming enhancement of PPI operator BC/DR expectations aligned with the RBI MD IT Governance (7 November 2023, effective 1 April 2024 for banks and large NBFCs).
• An internal capability review finds that Sharda's current RTO is "approximately 18 to 24 hours, untested" and that the BCM team is one part-time manager in the CISO's organisation.

The 7.1 programme

The CEO commissions a 12-month BCMS resourcing programme (illustrative). The programme is structured around the seven-stage workflow described in Section 7 of this guide, and the resourcing commitments are:

• People (≈₹1.4 crore per year OpEx). A full-time BCM Manager (recruited externally, ISO 22301 Lead Implementer certified), two BCM Coordinators (one for technology continuity, one for business continuity), and 0.4 FTE of internal-audit allocation for BCMS scope. The CMT is reconstituted with named members and alternates; the CEO chairs; the COO is alternate. Cross-training is initiated for the BCM Manager SPOF (the CISO becomes qualified as deputy BCM Manager).
• Technology (≈₹1.1 crore per year OpEx). A contracted managed-DR service with an RTO/RPO-bearing SLA (2-hour RTO, 15-minute RPO, Mumbai + Hyderabad regions, failover tooling included). An immutable backup layer (separate credential, separate account, write-once-read-many). A BCM/GRC platform for the inventory, the BIA, the plans, the exercises. A standalone crisis-notification platform with two-way acknowledgement.
• Infrastructure (≈₹0.4 crore per year OpEx). A contracted work-area recovery subscription (100 seats in Pune, 4-hour activation SLA). Diverse last-mile telecom (two providers plus mobile failover). Power and environmental resilience audited at the colocated edge.
• Financial (≈₹0.5 crore per year OpEx, ≈₹0.6 crore one-time CapEx). A defended BCMS budget line in the enterprise budget. A contingency reserve of ₹3 crore (≈1 month of OpEx) for disruption-driven spend. Cyber insurance with ₹50 crore cover (no ransomware sub-limit; 12-hour waiting period; no war-exclusion ambiguity).
• Information/external (≈₹0.4 crore per year OpEx). Retained legal counsel (₹6 lakh per year retainer), retained crisis-communications agency (₹8 lakh per year retainer), retained technical-forensics firm (₹4 lakh per year retainer), insurance broker (contingency), medical and psychological-first-aid advisers (on call). CERT-In PoC established and tested through a sector-CERT exercise. Mutual-aid refreshed with two peer PPI operators (one-page MoUs replaced with detailed operational MAAs).

Total programme commitment: ≈₹3.8 crore per year OpEx plus ≈₹0.6 crore one-time CapEx, against a pre-programme baseline of ≈₹0.4 crore per year (the part-time BCM Manager's allocated cost and ad-hoc IT continuity spend). The programme is funded by top management as a defended line in the enterprise budget, with quarterly BCM Steering Committee review.

The execution

The programme runs over 12 months against the implementation roadmap in Section 17 of this guide. Key milestones:

• Month 1–2: BCM Manager onboards; Resource Management Policy and Procedure drafted and approved; Resource Inventory opened and back-filled (initially 64 lines, growing to 142 lines by Month 12).
• Month 3–4: First Capability Gap Assessment, 27 gaps identified, 9 closed within the programme (DRS SLA, immutable backups, deputy BCM Manager, BCM/GRC platform, WAR subscription, cyber insurance, CERT-In PoC, crisis-notification platform, retained advisers), 12 closed through the year, 6 accepted as documented risks with top-management sign-off.
• Month 5–6: Managed-DR service contracted and integrated; first technical recovery test (parallel run, target 4-hour RTO achieved in 3.7 hours).
• Month 7–8: BIA refreshed against the Tier-1 bank customer's contractual RTO/RPO; BC strategy revised (active-active between Mumbai and Hyderabad regions for the wallet-load and settlement workloads); BC plans rewritten.
• Month 9–10: Full-feasibility exercise (tabletop + simulation + parallel technical failover), target 2-hour RTO achieved in 1 hour 38 minutes; target 15-minute RPO achieved with zero data loss.
• Month 11–12: Tier-1 bank customer BC/DR audit completed successfully (right-of-audit exercised; the bank's auditor reviewed the inventory, the gap assessment, the feasibility test, the supplier contracts and the BCM Steering Committee minutes); contract awarded.

The results and the ROI

• RTO reduced from 18–24 hours (untested) to under 2 hours (tested). RPO reduced from "best-efforts" to 15 minutes (tested, zero loss).
• Tier-1 bank contract won: ₹28 crore per year revenue, ≈₹19 crore contribution margin.
• RBI supervisory dialogue: Sharda's enhanced BC/DR posture is reflected in the next supervisory liaison; no enforcement action.
• Insurance premium: Cyber insurance negotiated at ≈₹18 lakh per year for ₹50 crore cover, materially below the un-priced pre-programme exposure.
• Operational efficiency: The BCM/GRC platform and the structured resourcing discipline reduce the BCM Manager's administrative load by ≈30%, freeing capacity for higher-value work.
• Audit findings: The first post-programme surveillance audit (ISO 22301) closes with zero major nonconformities on Clause 7.1 (vs. two majors identified at the pre-programme internal assessment).

The ROI calculation (illustrative):

• Programme cost over 18 months: ≈₹6.3 crore (OpEx ₹3.8 cr × 1.5 years + ₹0.6 cr CapEx).
• Revenue from the won Tier-1 contract over 18 months: ≈₹42 crore (₹28 cr × 1.5 years), with ≈₹28 crore contribution margin.
• Avoided-loss estimate (one ransomware event at peer-industry probability and impact): expected-value avoidance ≈₹4–8 crore (illustrative, based on sector incident patterns; one major event over 5 years at ₹30–50 crore impact, probability-weighted).
• Direct measurable ROI: contribution margin of ₹28 crore against a programme cost of ₹6.3 crore over the same window = ≈4.4× return, before counting the avoided-loss estimate and the regulatory and audit benefits.

The lessons (Clause 7.1 success factors)

1. Top-management funding was visible and defended, the BCMS budget line was a board-notable item, not a residual.
2. The capability gap assessment drove the programme, every commitment traced to a BIA-derived demand or a regulatory expectation.
3. The feasibility test was the proof, the 2-hour RTO was demonstrated, not asserted; the customer's auditor accepted the evidence.
4. Supplier-funded resourcing was used appropriately, managed-DR, cloud HA and WAR subscription extended Sharda's capacity without CapEx build.
5. The regulator PoC was established before it was needed, supervisory dialogue was constructive, not confrontational.
6. People resourcing was the foundation, the full-time BCM Manager and the deputy were the precondition for everything else.
7. The seven-stage workflow was followed, no shortcuts; the discipline produced the evidence that won the contract.

The 7.1 investment was substantial in absolute terms (≈₹4.4 crore per year at steady state) but small relative to the revenue it enabled (the Tier-1 contract alone) and the loss it avoided (one mid-tier incident would have cost more than five years of programme spend).

Multi-Framework Mapping

The 7.1 discipline is reinforced by a network of frameworks and regulations, each of which either requires resourcing directly or implies resourcing through its substantive obligations. The mapping below uses real control numbers, articles and paragraph references. An organisation running an integrated management system can produce a single 7.1 evidence set that satisfies multiple frameworks simultaneously.

ISO/IEC 27001:2022, Information security management systems

• Clause 7.1 (Resources), structurally identical to ISO 22301 Clause 7.1 by virtue of the Harmonized Structure. An IMS produces one resource evidence set for both standards.
• Annex A 5.5 (Roles, responsibilities and authorities), the people-resourcing dimension; maps to 7.1 people class.
• Annex A 5.10 (Information security awareness), the awareness programme is a resourced activity under 7.1.
• Annex A 8.13 (Information backup), the backup capability is a 7.1 technology resource.
• Annex A 8.14 (Redundancy of information processing facilities), the DRS / HA architecture is a 7.1 technology + infrastructure resource.
• Annex A 8.15 (Logging), the log-retention infrastructure (per CERT-In 180-day requirement) is a 7.1 technology resource.

ISO 9001:2015, Quality management systems

• Clause 7.1 (Resources), structurally identical; the Harmonized Structure means people, infrastructure, environment, monitoring resources, organisational knowledge are all 7.1 lines in a quality+continuity IMS.

NIST SP 800-34 Rev 1, Contingency Planning

• Step 4 (Identify preventive controls and recovery strategies), the demand-side of resourcing; each identified control and strategy is a 7.1 resource demand line.
• Step 6 (Plan testing, training, exercises), the feasibility-test resource; the training resource.

NIST CSF 2.0

• Govern function, particularly GV.PO-02 (Funding). The CSF 2.0 Govern function explicitly addresses funding as a governance outcome, maps directly to 7.1 financial class and to Clause 5.1.

FFIEC BCM Booklet (November 2019)

• Governance and accountability section, board and senior management responsibility for resourcing; the BCM budget as a board-level concern.
• Continuity strategies section, the strategy-derived resourcing expectations.

DORA, Regulation (EU) 2022/2554 (applies 17 January 2025)

• Article 6 (ICT risk management framework), the framework is itself a resourced programme; Article 6(8) requires a digital operational resilience strategy with impact tolerance, implying resourcing to meet the tolerance.
• Article 11 (Response and recovery), Article 11(3) requires ICT response and recovery plans (a resourcing demand); Article 11(5) requires a BIA; Article 11(6) requires yearly testing (feasibility-test resourcing); Article 11(7) requires a crisis-management function (people resourcing).
• Article 12 (Backup and recovery), Article 12(1)–(5) segregated backup systems (technology resourcing); Article 12(4) redundant ICT capacity (technology + infrastructure resourcing); Article 12(6) RTO and RPO per function (the demand-side of resourcing).
• Article 17–23 (Incident management and reporting), the resourcing implications of the major-incident reporting regime (PoC, tooling, retained advisers).
• Article 26 (TLPT), every 3 years for systemic entities; the TLPT is a resourced exercise.
• Article 28–30 (ICT third-party risk), Article 28 right-of-audit and contractual minima; Article 30 exit strategies, the supplier-resourcing dimension.
• Article 35(8) (CTPP penalty), up to 1% of average daily worldwide turnover for critical third-party service providers, the cost-of-getting-resourcing-wrong dimension.

APRA CPS 230 (effective 1 July 2025)

• Paragraph 16(e) (BCPs as part of the framework), BCPs as a documented part of the operational risk management framework; the framework is a resourced programme.
• Paragraph 38 (tolerance levels), the BIA triple (max disruption period / max data loss / min service levels); the demand-side of resourcing.
• Paragraph 41 (maintain BCP-execution capabilities), explicitly requires the entity to maintain the capabilities (resources) to execute the BCP; this is the closest analogue to ISO 22301 Clause 7.1 in the global prudential landscape.
• Paragraph 47 (service-provider management), the supplier-resourcing dimension.

MAS TRM Guidelines (18 January 2021)

• System availability and resilience section, RTO/RPO definition and testing; the demand-side of technology resourcing.
• Disaster recovery section, DRS architecture, geographic separation, drill cadence; technology + infrastructure resourcing.

HKMA TM-G-2 and OR-2

• TM-G-2 (Business Continuity Planning, 31 May 2022), recovery/resumption resourcing per critical function.
• OR-2 (Operational Resilience, 31 May 2022), Important Business Services identification, impact-tolerance setting, severe-but-plausible scenario testing, each implies resourcing.

Indian regulatory instruments

• RBI Master Direction, IT Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024), board and senior-management oversight of IT budget; adequate staffing of IT and information-security functions; documented IT Service Continuity resourcing including DRS; qualified CISO and SOC staffing. The single most-citable Indian 7.1 anchor for banks and large NBFCs.
• RBI Cyber Security Framework in Banks (2 June 2016), board-approved cyber-security policy with allocated budget; 24x7 SOC resourcing; Cyber Crisis Management Plan resourcing.
• RBI Master Direction, Outsourcing of IT Services (10 April 2023), outsourcer continuity resourcing must meet RE standards; right-of-access; concentration-risk monitoring.
• SEBI Cybersecurity and Cyber Resilience Framework, CSCRF (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024), graded resourcing expectations across 5 RE categories; SOC staffing by category; periodic audit resourcing.
• SEBI BCP/DR for MIIs (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021), Near Site and DRS resourcing with RTO/RPO-derived capacity and geographic separation.
• IRDAI Information and Cyber Security Guidelines (24 April 2023), board-approved budget for information and cyber security; CISO resourcing; DR drill resourcing; ICT outsourcing oversight staffing.
• CERT-In Directions (20(3)/2022-CERT-In, 28 April 2022), PoC resourcing; 24x7 incident-response contactability; log-retention (180-day) infrastructure; NTP infrastructure.
• DPDP Act 2023 (Act 22 of 2023) Section 8(5), availability duty = resourcing duty for safeguards; Section 8(6), breach-notification resourcing; Significant Data Fiduciaries, DPIA, audit, DPO resourcing.
• Companies Act 2013 Section 134(3)(n), board risk statement implies BCMS resourcing; Section 177 and SEBI LODR Regulation 21, board committee oversight of risk-management systems including resourcing.
• NDMA Disaster Management Act 2005 + Chemical Disasters Guidelines 2007 + Disaster Management Plans 2014, on-site and off-site emergency plan resourcing; mutual-aid resourcing; integration with District DMPs.
• IT Act 2000 Section 70A (NCIIPC), 70B (CERT-In), 43 (civil compensation including availability/DoS), the statutory bedrock underneath every resourcing expectation.

Cross-framework synthesis

The cross-framework synthesis is striking: every major framework, regulation and prudential standard that touches operational resilience converges on a small number of resourcing expectations, a defined BCM/DR team, a contracted DRS with RTO/RPO-bearing SLA, an exercised feasibility test, a funded budget line, supplier continuity oversight, and a pre-existing regulator-PoC relationship. An Indian organisation that builds a single 7.1 evidence set addressing these expectations satisfies ISO 22301, ISO 27001, RBI, SEBI, IRDAI, CERT-In, DPDP, Companies Act and NDMA simultaneously, and is well-positioned for DORA, APRA CPS 230, MAS TRM and HKMA OR-2 if its operations extend into those jurisdictions.

Implementation Roadmap

The 7.1 implementation roadmap is sequenced over 30, 90, 180 and 365 days. The roadmap assumes a growing Indian organisation (250 to 2,000 staff) starting from a low-maturity baseline (L1 to L2). For growing companies (50 to 250 staff), compress the timeline by ≈30%; for multi-entity enterprises, extend by ≈50%.

Days 0–30, Foundation

• Day 1–5: Top-management briefing; charter the 7.1 programme; appoint the BCM Manager as the 7.1 programme lead; constitute the BCM Steering Committee with named members.
• Day 6–15: Draft the BCMS Resource Management Policy (toolkit document 01) and the Resource Management Procedure (toolkit document 02); circulate for review.
• Day 16–25: Open the BCMS Resource Inventory (toolkit document 09); run the resource-back-fill workshop (the "Quick Win" in Section 1) to populate the inventory with the prior 12 months of committed resources.
• Day 26–30: Policy and Procedure approved by top management; inventory baselined at the back-filled state (typically 40 to 120 lines).

Days 31–90, Analysis

• Day 31–45: Run the first Capability Gap Assessment (toolkit document 12), compare the demand register (derived from the BIA, the strategy, the objectives, the risk register, the regulatory landscape) against the supply inventory. Expect 20 to 60 gaps.
• Day 46–60: Build the BCMS Budget Plan (toolkit document 11) with the OpEx/CapEx split and the multi-year horizon. Defend the budget at the BCM Steering Committee.
• Day 61–75: Build the DRS and Alternate-Site Costing Model (toolkit document 10); make the DRS / alternate-site / WAR procurement decisions.
• Day 76–90: First BCM Steering Committee review of the resourcing portfolio; top-management acknowledgement of the accepted gaps; budget approval for the closing-gap spend.

Days 91–180, Build

• Day 91–120: Execute the closing-gap spend, DRS contract, WAR subscription, BCM/GRC platform, crisis-notification platform, cyber insurance, retained-adviser contracts.
• Day 121–150: BCM team build-out, recruit or confirm the BCM Manager, the deputies, the BCM Coordinators; appoint the CMT and alternates; cross-training for SPOF roles.
• Day 151–180: First technical recovery test (parallel run) on the new DRS, measure achieved RTO/RPO against the BIA targets; capture findings.

Days 181–365, Validate and Embed

• Day 181–240: BIA refresh and strategy revision if the resourcing programme has changed the achievable RTO/RPO; BC plans rewritten to match the validated capability.
• Day 241–300: Full feasibility exercise (tabletop + simulation + parallel technical failover), demonstrate the achievable RTO/RPO to top management and (if applicable) to customer-auditors and regulators.
• Day 301–365: First management-review cycle (Clause 9.3) with the full 7.1 input, inventory summary, gap assessment, KPI dashboard, feasibility-test results, renewal calendar, budget ask. Maturity reassessment against the L1–L5 model (Section 22). First internal-audit cycle (Clause 9.2) sampling 7.1 evidence.

Beyond Year 1, Sustain and Improve

• Annual capability gap assessment; annual feasibility exercise; annual budget defence; annual management review; annual internal audit.
• Continuous inventory maintenance; quarterly BCM Steering Committee review; monthly BCM Manager review.
• Continual-improvement initiatives: inventory migration from spreadsheet to GRC platform (typically Year 2 for mid-market); automation of the gap assessment (Year 2–3); integration with ISMS and ERM resourcing (Year 2–3); maturity advancement toward L4–L5.

FAQ

Q1. Does Clause 7.1 require a specific BCM team size?

No. The standard is silent on absolute FTE counts. The right team size is whatever the BIA-derived demand demonstrates is required. A bank with 30-minute RTO commitments needs a substantially larger team than a 250-person BPO with 7-day RTO commitments. The auditor's question is not "how many FTE?" but "how do you know this team size is sufficient?", answered by the capability gap assessment.

Q2. Can the BCM Manager role be a part-time assignment?

It depends on scope. For an Indian growing company with a modest BCMS scope, a part-time BCM Manager with calendared and defended time can be conformant. For a bank, MII, insurer, hospital, or any organisation with life-safety-critical or systemically-critical continuity commitments, the BCM Manager is almost always a full-time role. The test is whether the calendared time meets the demand derived from the scope and objectives.

Q3. Does 7.1 require a cloud DRS, or is on-premises DRS acceptable?

Both are acceptable. The standard is silent on own-vs-rent; the decision is a Clause 8.3 strategy and procurement question. What matters is that the chosen DRS is contractually committed, RTO/RPO-bearing, tested through exercises, and aligned with the BIA. RBI MD IT Governance (for banks and large NBFCs) and SEBI MII BCP-DR (for MIIs) add specific requirements on DRS architecture, geographic separation and Near Site that may influence the choice.

Q4. We use cloud for our production systems. Do we still need a separate DRS?

It depends on the cloud architecture and the BIA RTO/RPO. A multi-region active-active cloud architecture may deliver the BIA commitments without a separate "DRS", but the cloud-region failover must be tested, the data-residency and regulator-jurisdiction expectations must be met, and the supplier-continuity arrangement must be documented. Cloud is not automatically resilient; resilience is a design and resourcing choice.

Q5. Does 7.1 require cyber insurance?

Not explicitly. The standard requires the organisation to identify and provide the resources the BCMS needs; insurance is one of the financial-class resources. Whether cyber insurance is required depends on the BIA-derived risk profile and the organisation's risk appetite. For most Indian growing companies processing material digital data or operating digital services, cyber insurance is now a leading-practice resourcing decision, and increasingly a customer-contractual expectation.

Q6. Can supplier-funded resourcing (cloud SLA, managed-DR contract) substitute for in-house resourcing?

Yes, with conditions. Supplier-funded resourcing is a legitimate and often preferred pattern, especially for growing companies. The conditions: the supplier arrangement must be contractually committed (not marketing), must be SLA-bearing with measurable RTO/RPO, must be tested through exercises, must be right-of-audit, and must have an exit plan. RBI MD Outsourcing of IT Services (10 April 2023) and DPDP Section 8(5) impose additional conditions for regulated entities and Data Fiduciaries.

Q7. Does 7.1 require an annual feasibility exercise?

The standard does not specify a frequency. However, ISO 22313:2020 guidance and the practitioner consensus treat annual as the baseline frequency for the full feasibility exercise, with more frequent technical recovery tests (typically quarterly) for high-criticality systems. SEBI MII BCP-DR, IRDAI ICS Guidelines and the RBI MD IT Governance all impose specific drill cadences on regulated entities. APRA CPS 230 paragraph 43 explicitly requires an annual business-continuity exercise.

Q8. Our budget is constrained. Can we implement 7.1 incrementally?

Yes, incremental implementation is conformant provided the gaps are identified, risk-assessed, documented on the risk register, and either remediated on a defined schedule or accepted by top management. An under-resourced BCMS with a transparent gap assessment and a top-management-acknowledged remediation plan is conformant; an under-resourced BCMS with invisible gaps is nonconformant. The 30/90/180/365-day roadmap in Section 17 is designed for incremental implementation.

Q9. Does the BCM Steering Committee need to include top management (CEO, CFO)?

Yes. The BCM Steering Committee is the principal 7.1 governance forum and is the operational expression of Clause 5.1 leadership commitment. A BCM Steering Committee chaired below the C-suite (e.g., by the BCM Manager) is a red flag for the auditor, it suggests top-management commitment is nominal rather than substantive. For listed entities, SEBI LODR Regulation 21 and Companies Act Section 177 place BCMS resourcing explicitly in scope of the board's Risk Management Committee.

Q10. Does 7.1 require us to use BCM/GRC software?

No. A spreadsheet is conformant. BCM/GRC software is leading practice for larger organisations (typically upper mid-market and enterprise) but is not mandated. The decision should be a function of BCMS scope, complexity and maturity, not of vendor marketing. The tool comparison matrix in the toolkit (document 14) provides a category-level evaluation framework.

Q11. How does 7.1 relate to Clause 7.2 (Competence)?

The two clauses are tightly coupled. 7.1 provides the people resources; 7.2 ensures those people are competent. The BCM role catalogue (a 7.1 artefact) defines the competency profile for each role; the competence evidence (a 7.2 artefact) demonstrates that the named individuals meet the profile. A BCM team that is properly sized (7.1) but under-qualified (7.2) is nonconformant; so is a BCM team that is qualified (7.2) but under-sized (7.1).

Q12. What is the single most important 7.1 evidence for the certification audit?

The capability gap assessment. It is the only artefact that defensibly answers the auditor's central question: "how do you know these resources are sufficient?" Without the capability gap assessment, every other 7.1 evidence (inventory, budget, DRS contract, exercise report) is a collection of facts without an analytical framework. With it, the BCMS resourcing is a disciplined system rather than a collection of line items.

Q13. Does 7.1 apply differently to multi-entity groups?

Yes, in scale and integration but not in principle. A multi-entity group typically runs a group-level BCM/DR resourcing programme with cascaded subsidiary inventories, multi-jurisdiction regulatory-resourcing expectations (DORA, CPS 230, MAS TRM, RBI MD), and a group BCM Steering Committee. The 7.1 principle (identify, source, allocate, sustain, measure, review, improve) is identical; the complexity is greater.

Q14. How do we handle the CERT-In 6-hour reporting clock under 7.1?

The 6-hour clock (CERT-In Directions 28 April 2022) presupposes a resourced incident-response capability, a PoC function, a 24x7 contactable team, a tested notification procedure, a retained forensics capability, and a pre-existing CERT-In relationship. Each of these is a 7.1 resource line. An organisation that has not resourced them will miss the clock; the first interaction with CERT-In should not be on the day of an incident.

Q15. What is the relationship between 7.1 and the DPDP Act 2023 availability duty?

DPDP Act 2023 Section 8(5) makes the availability (and integrity, and confidentiality) of personal data a statutory duty of the Data Fiduciary. The duty presupposes that the Data Fiduciary has resourced the safeguards (technical, organisational, people) that protect availability, which is a Clause 7.1 question. For Significant Data Fiduciaries, the DPDP Rules 2025 add DPIA, periodic security audits and a DPO obligation, each of which is a resourcing demand. A 7.1 evidence set that addresses the DPDP availability duty is also the strongest defence under the DPDP penalty regime (up to ₹250 crore).

Industry-Specific Requirements

The 7.1 resourcing footprint varies materially by industry. The sector-specific guidance below addresses the five sectors most commonly encountered in Indian growing-company engagements.

BFSI, Banks, NBFCs, Payment System Operators

The BFSI sector has the deepest resourcing expectations in India, driven by the RBI Master Direction on IT Governance (7 November 2023, effective 1 April 2024), the RBI Cyber Security Framework (2 June 2016), the RBI Master Direction on Outsourcing of IT Services (10 April 2023), and (for SEBI-regulated entities) the CSCRF (20 August 2024) and the MII BCP-DR (22 March 2021). The 7.1 footprint typically includes: a dedicated BCM team (3 to 10+ FTE depending on entity size); a qualified CISO (per RBI MD); 24x7 SOC (in-house or managed); active-active DC or cloud HA architecture; DRS with RTO/RPO-bearing SLA; Near Site for MIIs; quarterly drill programme with semi-annual full failover; cyber insurance with material cover; retained legal, forensic, and crisis-communications advisers; documented board-IT-budget allocation. The board's Risk/IT Committee has explicit oversight of the resourcing.

Healthcare, Hospitals, Health-Tech, Diagnostic Chains

The healthcare sector has life-safety-critical resourcing expectations, driven by the clinical-care implications of outages (the AIIMS Delhi ransomware November 2022 is the marquee Indian example) and (for digital health) the DPDP Act 2023 and (for clinical records) the evolving digital-health regulatory framework. The 7.1 footprint typically includes: a DRS for EMR/HIS with near-zero RTO for life-critical functions; immutable backups; paper-based clinical fallback procedures; clinical-staff BC training; mutual-aid with neighbouring facilities (beds, theatres, blood, medical records); retained technical-forensics and crisis-communications advisers; medical and psychological-first-aid capacity; cyber insurance with healthcare-specific cover. The clinical-governance and BCM governance must be integrated.

IT-ITeS and SaaS

The IT-ITeS and SaaS sector has customer-contract-driven resourcing expectations, driven by customer BC/DR clauses, SLA credits, regulator-imposed expectations (RBI MD Outsourcing for BPOs serving banks; DORA Article 28 for ICT services serving EU financial entities; sector-specific expectations for vertical-specific SaaS). The 7.1 footprint typically includes: geo-diverse delivery (India + alternate geography for sovereignty-sensitive customers); cloud HA architecture; contracted DRS with customer-specific RTO/RPO commitments; per-customer BC documentation; key-person redundancy (particularly for niche technical skills); BCM/GRC platform to manage the multi-customer complexity; cyber insurance with customer- indemnity provisions. Customer-audits and right-of-audit are routine.

Manufacturing, Including Chemical and MAH Units

The manufacturing sector has NDMA-driven resourcing expectations, with the Chemical Disasters Guidelines 2007 and the Disaster Management Plans 2014 providing the canonical framework. For MAH units, the 7.1 footprint typically includes: on-site emergency control room staffed 24x7; mutual-aid agreements with the industrial cluster (foam, medical, evacuation); OT spare inventory and qualified maintenance; environmental monitoring (per State Pollution Control Board); evacuation drills; cyber-physical segmentation for OT/ICS; DRS for ERP, MES and quality systems; cyber insurance with business-interruption cover. The integration of physical-safety emergency planning (NDMA) and digital continuity (ISO 22301) is the distinctive manufacturing-sector challenge.

Government, PSU and Critical Infrastructure

The government and critical-infrastructure sector has NCIIPC-driven resourcing expectations (per IT Act Section 70A), with sovereign considerations layered onto the standard ISO 22301 framework. The 7.1 footprint typically includes: sovereign-cloud or on-prem DRS for classified systems; dedicated BC teams; interagency mutual-aid (with state / district / sector CERTs); sector-ministry reporting; classified-system recovery provisions; indigenous procurement preferences; cyber insurance (where available) or sovereign-backed risk retention. The integration with the NDMA framework (National Disaster Management Plan) and the sector-specific emergency-response frameworks is essential.

Maturity Model

The 7.1 maturity model is a five-level framework that describes the progression from a goodwill-driven BCMS to a continuously-improving, benchmarked resourcing system. The model is used for self-assessment, for the management-review maturity input, and for the continual-improvement roadmap.

Level 1, Initial / Goodwill

Description: The BCMS is resourced through informal commitments, the BCM role is a part-time assignment, the DRS is whatever IT has spare capacity for, the drill budget is whatever is left over at year-end, the BCM team has no deputy, the supplier-continuity arrangements are in marketing slides rather than contracts, the regulator-PoC relationship does not exist. There is no identifiable BCM budget line in the enterprise budget.

Evidence to expect: An inventory that is empty or aspirational; no capability gap assessment; no feasibility test; BCM Manager is the only person who knows the BCMS; accepted gaps are not on the risk register.

Typical Indian growing-company spend: <₹10 lakh per year OpEx (typically the part-time BCM Manager's allocated cost and ad-hoc IT continuity spend).

Advancement path: Run the resource-back-fill workshop; write the Resource Management Policy and Procedure; open the inventory; run the first capability gap assessment; defend a real budget line at the next budget cycle.

Level 2, Reactive / Compliance-Driven

Description: The BCMS is resourced to pass the certification audit, but the resourcing discipline is documentation-heavy and operationally light. The inventory exists but is updated only before the surveillance audit. The capability gap assessment is run reactively after audit findings. The DRS contract exists but is exercised only when forced. The BCM Manager is full-time but under-supported.

Evidence to expect: An inventory updated annually before the audit; a capability gap assessment that mirrors the audit findings; a feasibility test that meets but does not exceed the RTO; supplier-continuity arrangements that are in the contract but untested.

Typical Indian growing-company spend: ₹10 lakh to ₹50 lakh per year OpEx, plus modest CapEx (DRS subscription, BCM/GRC platform basic).

Advancement path: Move the inventory and the gap assessment to a continuous cycle (monthly review, quarterly refresh); exercise the supplier-continuity arrangements; build the BCM team depth (deputy, coordinators).

Level 3, Defined / Managed

Description: The BCMS is resourced through a defined, managed system that follows the seven-stage workflow. The inventory is complete across the five resource classes. The capability gap assessment is run annually and after every BIA revision. The feasibility exercise is run annually with RTO/RPO measurement. The BCM team has depth (deputy, coordinators). The supplier-continuity arrangements are tested. The budget is defended annually with the gap assessment as justification.

Evidence to expect: A complete inventory with all five classes; an annual capability gap assessment; an annual feasibility exercise with measured RTO/RPO; a BCM team with deputy and coordinators; tested supplier-continuity; a defended BCM budget line; the resource portfolio as a standing management-review input.

Typical Indian growing-company spend: ₹50 lakh to ₹3 crore per year OpEx, plus structured CapEx (DRS build or subscription, BCM/GRC platform, work-area recovery, cyber insurance).

Advancement path: Move the inventory to a GRC platform; automate the gap assessment; integrate with ISMS and ERM resourcing; advance the exercise programme toward full-failover and TLPT.

Level 4, Quantitatively Managed

Description: The BCMS resourcing is measured with KPIs that are benchmarked against sector peers. The capability gap assessment is continuous. The feasibility exercise is supplemented by quarterly technical recovery tests. The supplier-continuity arrangements are right-of-audit-exercised. The budget defence uses quantitative ROI and avoided-loss analysis. The BCM team has succession depth.

Evidence to expect: KPI dashboard with sector benchmarking; continuous gap assessment; quarterly technical recovery tests; supplier-audit programme; quantitative budget defence; documented succession for the BCM Manager and CMT Chair roles.

Typical Indian mid-market / enterprise spend: ₹3 crore to ₹15 crore per year OpEx, plus material CapEx (own-build or contracted DRS, integrated BCM/GRC platform, work-area recovery, programme spend).

Advancement path: Move to L5 by integrating the 7.1 system with enterprise risk management, by adopting advanced analytics (predictive gap assessment, ML-augmented exercise analysis), and by leading sector-peer benchmarking forums.

Level 5, Optimising

Description: The BCMS resourcing is continuously improved through advanced analytics, sector benchmarking, and integration with adjacent disciplines (ISMS, ERM, OT security, resilience engineering). The capability gap assessment is predictive (anticipating gaps before they arise). The feasibility exercise programme includes TLPT and cross-sector exercises. The supplier-continuity arrangements include contractual innovation (shared-resilience pools, reciprocal MAAs). The BCM team is a centre of excellence that mentors other functions.

Evidence to expect: Predictive gap assessment; TLPT programme; cross-sector exercise participation; supplier-resilience innovation; documented centre-of-excellence activities; sector-peer benchmarking leadership.

Typical Indian enterprise / regulated-entity spend: >₹15 crore per year OpEx, with material multi-year CapEx programmes.

Advancement path: At L5, the advancement path is to maintain, to sustain the optimisation discipline, to absorb new regulatory expectations (DORA, APRA CPS 230, DPDP Rules refinements), and to mentor the broader sector.

Maturity assessment cadence

The maturity is self-assessed annually by the BCM Manager, validated by the BCM Steering Committee, reported to top management at the management review (Clause 9.3), and independently verified by internal audit (Clause 9.2) at least every two years. The maturity trajectory is a standing input to the continual-improvement roadmap (Clause 10.2).

Emerging Trends

The 7.1 discipline is evolving in response to technology, regulatory and operational shifts. Six trends are reshaping how Indian growing companies resource their BCMS in 2025 to 2027.

Cloud-native resilience replacing DRS-as-a-place

The traditional DRS-as-a-place (a secondary DC with a defined rack count and an activation SLA) is being supplemented, and in some cases replaced, by cloud-native resilience patterns: multi-region active-active, multi-cloud failover, immutable infrastructure-as-code, and resilience orchestration. The 7.1 implication is that the technology-class inventory is shifting from physical capacity to architectural pattern. The feasibility test is shifting from "fail over to DRS" to "fail over to alternate region / cloud / availability zone". The auditor's question is shifting from "show me the DRS contract" to "show me the resilience architecture and the multi-region test evidence". This is most advanced in cloud-native SaaS and fintech; it is reaching BFSI (under RBI's cloud and outsourcing expectations) and is beginning to reach government (under sovereign-cloud programmes).

Regulator-driven resourcing granularity (RBI MD, CSCRF, CPS 230, DORA)

The regulatory expectations are becoming more granular and more quantitative. The RBI MD IT Governance (7 November 2023) prescribes specific resourcing expectations for banks and large NBFCs (board-IT-budget, CISO, SOC, IT Service Continuity). SEBI CSCRF (20 August 2024) grades REs into five categories with scaling resourcing expectations. APRA CPS 230 (effective 1 July 2025) paragraph 41 explicitly requires the entity to "maintain BCP-execution capabilities". DORA (applies 17 January 2025) Article 11 and Article 12 prescribe specific response, recovery and backup resourcing expectations. The 7.1 implication is that the demand-side of the resourcing equation is increasingly regulator-driven; the supply-side (the organisation's resourcing response) must be calibrated to the regulator's specific expectations, not to a generic ISO 22301 baseline.

Cyber resilience and OT convergence

The convergence of cyber resilience and operational continuity is accelerating, particularly in manufacturing, energy, healthcare and transport. The traditional BCMS focused on natural-disaster and outage scenarios; the modern BCMS must address ransomware, supply-chain compromise, OT/ICS attack, and wiper malware. The 7.1 implication is that the people-class inventory is expanding (cyber-security skills in the BCM team; BCM skills in the cyber-security team), the technology-class inventory is expanding (segmentation, immutable backups, EDR/XDR, MFA, PAM), and the feasibility-test programme is expanding (TLPT per DORA Article 26, ransomware tabletop, OT-attack simulation).

Climate-change adaptation and the BCMS

ISO 22301:2019 Amendment 1:2024 brought climate-change adaptation explicitly into the BCMS context (Clauses 4.1 and 4.2). The 7.1 implication is that the BIA and the strategy must address climate-driven disruption scenarios (extreme heat, flooding, cyclone intensification, water scarcity for cooling), and that the resourcing must follow. For Indian organisations, particularly those with coastal or riverine exposure, or with water- or temperature-sensitive operations, climate-driven resourcing is becoming a first-class 7.1 consideration.

Skills scarcity and the retained-adviser model

India faces a scarcity of qualified BCM professionals (a constraint well-documented in the BCI Horizon Scan and in the broader Indian cyber-skills discourse). The 7.1 implication is that the retained-adviser model (retained legal counsel, forensics, crisis communications, technical specialist) is becoming a structural part of the people-class inventory, not an ad-hoc arrangement. Organisations that cannot recruit full-time BCM talent are increasingly relying on retained advisers and managed-BCM services, a legitimate and often preferable pattern for growing companies, provided the retainerrs are contracted, evidenced and tested.

Data-driven BCMS and analytics

The use of data and analytics in the BCMS is advancing: predictive gap assessment (using CMDB, asset and configuration data to anticipate resourcing gaps before they bite), exercise analytics (using exercise data to drive the corrective-action pipeline), and KPI benchmarking (using sector-peer data to set targets). The 7.1 implication is that the BCM/GRC platform is becoming the system of record not just for the inventory but for the analytics layer that drives the seven-stage workflow. For Indian growing companies, the analytics maturity typically lags the inventory maturity by 12 to 24 months; both are advancing rapidly.

References and Further Reading

The references below are the primary standards, regulations and frameworks cited in this guide. They are the authoritative sources for the requirements paraphrased above. The guide does not reproduce any standard's text; all standard text is paraphrased.

ISO standards and guidance

• ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements (plus Amendment 1:2024 on climate change adaptation). International Organization for Standardization.
• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301. International Organization for Standardization.
• ISO 22300:2021, Security and resilience, Vocabulary (current edition; note that ISO/DIS 22300 (4th ed.) is under development at iso.org/standard/85749.html and not yet published before citing a year).
• ISO/TS 22317:2021, Security and resilience, Business continuity management systems, Guidelines for business impact analysis (current edition; the 2015 edition is withdrawn).
• ISO/TS 22318:2021, Business continuity management systems, Guidelines for supply chain continuity (current edition; the 2015 edition is withdrawn).
• ISO/TS 22331:2018, Security and resilience, Business continuity management systems, Guidelines for business continuity strategy. (Note: the ISO catalogue page iso.org/standard/50068.html lists this as ISO/TS 22331:2018; year requires confirmation against the live ISO page.)
• ISO/TS 22330:2018, Security and resilience, Guidelines for people aspects of business continuity.
• ISO 22316, Security and resilience, Organizational resilience, Guidelines.
• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements (Clause 7.1; Annex A 5.5, 5.10, 8.13, 8.14, 8.15).
• ISO 9001:2015, Quality management systems, Requirements (Clause 7.1).
• ISO 31000:2018, Risk management, Guidelines.

Indian regulatory instruments

• Reserve Bank of India, Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024). RBI portal id 12562.
• Reserve Bank of India, Cyber Security Framework in Banks (2 June 2016, DBS.CO/OC.No.114/33.01.001/2015-16).
• Reserve Bank of India, Master Direction on Outsourcing of Information Technology Services (10 April 2023).
• 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).
• Securities and Exchange Board of India, Guidelines for Business Continuity Plan and Disaster Recovery of Market Infrastructure Institutions (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021).
• Insurance Regulatory and Development Authority of India, Information and Cyber Security Guidelines, 2023 (24 April 2023).
• Indian Computer Emergency Response Team, Directions under Section 70B(6) of the IT Act, 2000 (No. 20(3)/2022-CERT-In, 28 April 2022).
• Digital Personal Data Protection Act, 2023 (Act 22 of 2023, enacted 11 August 2023); Digital Personal Data Protection Rules, 2025 (MeitY).
• Disaster Management Act, 2005 (Act 53 of 2005); NDMA Guidelines, Chemical Disasters (Industrial), 2007; Disaster Management Plans, 2014.
• Companies Act, 2013 (Section 134(3)(n), Section 177); SEBI Listing Obligations and Disclosure Requirements Regulations, 2015 (Regulation 21, Risk Management Committee).
• Information Technology Act, 2000 (Sections 43, 65, 66, 70, 70A, 70B, 72, 84A).

Global frameworks and prudential standards

• NIST SP 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems (May 2010). National Institute of Standards and Technology.
• NIST SP 800-160 Vol 1 (Update 2) and Vol 2 Rev 1, Systems Security Engineering and Cyber Resilience. National Institute of Standards and Technology.
• NIST Cybersecurity Framework 2.0 (NIST.CSWP.29, 26 February 2024), particularly the Govern (GV.PO) and Recover (RC) functions.
• FEMA Federal Continuity Directives FCD-1 (17 January 2017) and FCD-2 (13 June 2017) under PPD-40.
• FFIEC IT Examination Handbook, Business Continuity Management Booklet (November 2019; OCC Bulletin 2019-57 / FRB SR 19-13 / FDIC FIL-19071-2019).
• Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA). OJ L 333, 27.12.2022, p. 1. Applies 17 January 2025 (Article 64).
• APRA Prudential Standard CPS 230, Operational Risk Management (effective 1 July 2025; particularly paragraphs 16, 38, 41, 42, 43, 47).
• MAS Technology Risk Management Guidelines (18 January 2021).
• HKMA Supervisory Policy Manual TM-G-2 (31 May 2022) and OR-2 (31 May 2022).

Practitioner bodies of knowledge

• Business Continuity Institute, BCI Horizon Scan 2025 and 2024 (the most-citable BCM industry dataset; published at thebci.org).
• Practitioner bodies of knowledge (BCM professional practices), published by the accredited practitioner bodies; consult the issuing body's current edition directly.

How to use the references

The standards are the authoritative sources for the requirements paraphrased in this guide. For implementation, the ISO 22301:2019 / ISO 22313:2020 / ISO/TS 22331:2018 combination is the canonical core; the RBI MD IT Governance, SEBI CSCRF, IRDAI ICS, CERT-In Directions and DPDP Act are the binding Indian regulatory layer; DORA, APRA CPS 230, MAS TRM and HKMA OR-2 are the cross-jurisdictional layer for organisations with international operations. The NIST, FFIEC and FEMA references are the US-prudential and US-federal-continuity layer; cite them when mapping for US customers or US operations.

The references are point-of-departure reading; the practitioner should obtain current editions directly from the issuing body (ISO, RBI, SEBI, IRDAI, CERT-In, MeitY, NDMA, MCA, NIST, FFIEC, FEMA, EUR-Lex, APRA, MAS, HKMA) before relying on a specific paragraph or control number. Where this guide flags a verification item (e.g., the status of ISO/DIS 22300 (4th ed., under development)), the practitioner should re-confirm at the time of implementation.

End of guide. This guide is the Singahi Clause 7.1 reference; the accompanying toolkit (17 documents in the toolkit/ folder) operationalises the discipline for a first-cycle implementation. For engagement enquiries, contact the Singahi team.