ISO 22301 Clause 8.3: Business Continuity Strategies and Solutions

Quick Reference (60 Seconds)

If you only read one thing: Clause 8.3 is where the BCMS stops being analysis and starts being engineered resilience. The BIA (8.2) tells you how quickly you must recover and how much you can lose; Clause 8.3 is the clause where you decide how, which mix of redundant sites, alternate people, manual workarounds, and alternate suppliers will actually deliver those numbers, and then pay for and stand up those solutions. Get this clause right and your plans (8.4) write themselves; get it wrong and no amount of plan documentation or exercise theatre will save you during a real disruption.

What the Standard Actually Requires

Figure · Process

What Clause 8.3 asks you to do

The paraphrased requirement

ISO 22301 Clause 8.3 asks organizations to identify and select continuity strategies and solutions, covering the period before, during, and after a disruption, that are derived from the BIA and risk assessment, and to resource the chosen strategies across people, premises, technology, and suppliers. In practical terms, this means an organisation has to be able to answer seven questions in writing:

1. Strategy identification, For each prioritised activity from the BIA, what are the feasible continuity strategies and solutions that could keep it running or bring it back within its RTO, at its MBCO, and within its RPO?
2. Selection method, How do we choose among those options? What criteria (cost, RTO fit, RPO fit, MBCO fit, complexity, regulatory requirement, concentration risk) drive the decision, and how is the trade-off documented?
3. The three phases, What do we do before a disruption (prevention, mitigation, pre-positioning), during a disruption (response, alternate delivery, graceful degradation), and after a disruption (recovery, restoration, return to normal)? A strategy that only covers the "during" is incomplete.
4. The four resource areas, For each chosen strategy, who are the people, what are the premises, what is the technology, and which suppliers required to make it work? Are they identified, funded, and available?
5. Fit validation, Does the chosen solution actually satisfy the BIA-derived tolerances? If the BIA says RTO of 2 hours and the chosen DRS can only fail over in 6 hours, the strategy does not fit, and an auditor will find this in one question.
6. Resourcing, Are the resources (budget, people, contracts, facilities, technology) actually in place, or is the strategy aspirational? A strategy with no funded DRS contract is a wish, not a solution.
7. Living process, When and how will we re-do this, annually, on trigger (major change, M&A, new product, post-incident, post-exercise that exposed drift), and when the BIA itself changes?

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

Clause 8.3 is often conflated with the clauses around it. Being explicit about the boundary helps auditors and practitioners alike:

• It does not require the BIA itself. That is Clause 8.2. The BIA feeds strategy selection; 8.3 consumes its outputs (RTO/RPO/MBCO/MTPD, dependency map, risk register).
• It does not require writing the BC plans or procedures. That is Clause 8.4. The chosen strategy is the design the plans execute; the plans are the runbooks.
• It does not require exercising the strategy. That is Clause 8.5. Exercises validate that the chosen solutions deliver the RTO/RPO they claim; if they do not, the strategy is revised under 8.3 and re-tested under 8.5.
• It does not mandate any particular strategy type. ISO 22301 does not require active-active, or a hot DRS, or any specific technology. It requires that the chosen strategy demonstrably fits the BIA-derived tolerances. For some activities, a manual workaround is the right answer; for others, only active-active will do.
• It does not require the most expensive option. Cost is a legitimate selection criterion. The requirement is that the trade-off (cost vs RTO/RPO/MBCO fit vs risk) is made deliberately, documented, and approved by top management, not defaulted to "whatever we already have."
• It does not require a separate strategy per IT system. ISO 22301 is organisation-centric: the unit of strategy is the prioritised activity. IT-system-level recovery (the NIST SP 800-34 framing) feeds in, but a technology solution that recovers a server without recovering the business activity it serves is not a Clause 8.3 strategy.

The companion guidance (ISO 22313:2020 and ISO/TS 22331:2018)

The clause text is short; the method lives in companion documents. Both are paywalled, and citing the current edition matters:

• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301. The clause-by-clause companion. Use it as the authoritative explanation of what 8.3 evidence should look like and how strategy selection links to the BIA.
• ISO/TS 22331:2018, Security and resilience, Business continuity management systems, Guidelines for business continuity strategy. The dedicated strategy-selection methodology. Defines strategy options (active/active, active/passive, manual workaround, reciprocal, insurance, do-nothing/accept), trade-off criteria (cost vs RTO/RPO vs MBCO vs MTPD), implementation considerations, and how to validate that chosen solutions actually meet the tolerances. This is the how-to for Clause 8.3.
• ISO/TS 22318:2021, Business continuity management systems, Guidelines for supply chain continuity. Second edition; supersedes the withdrawn 2015 first edition. Extends strategy to the supplier resource area, essential given how many Indian continuity failures trace to a single supplier.
• ISO/TS 22330, Security and resilience, Business continuity management systems, Guidelines for people aspects of business continuity. The method behind the "people" resource area: succession, cross-training, welfare, work-area relocation.
• ISO 22300:2021, Security and resilience, Vocabulary. Third edition. The normative source of the definitions of continuity strategy, solution, prioritised activity, disruption, and the RTO/RPO/MBCO/MTPD terms the strategy must satisfy. A fourth edition (ISO/DIS 22300) is under development (enquiry stage) and will replace the 2021 edition when published; not yet published, re-confirm the year before quoting.

What auditors actually check

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

• The strategy document itself, options considered, selection criteria, chosen strategy per prioritised activity, resourcing plan across the four areas, cost-benefit analysis, top-management approval, version history.
• Traceability to the BIA, does the chosen strategy for each activity actually deliver its RTO/RPO/MBCO within its MTPD? Auditors will pick one activity, read the BIA's RTO, and ask "show me how your chosen solution achieves that." If the chain breaks, it is an immediate finding.
• Traceability to the plans, does the Clause 8.4 plan for that activity encode the chosen strategy? If the strategy says "fail over to warm DRS" but the plan says "restore from last night's backup to the same site," the plan and strategy are disconnected.
• Evidence of resourcing, is the DRS contracted? Is the work-area recovery seat booked? Is the alternate supplier onboarded? Is the cross-training done? A strategy with no funded resources is a non-conformity, not a strategy.

Common observations you should be ready for: (a) "your strategy names a DR site but you cannot show it achieves the RTO from your BIA" (an L2 finding); (b) "your strategy covers technology but has no people or premises solution, who staffs the DRS?" (a classic gap); (c) "your critical banking application has a single cloud provider with no exit or failover strategy" (a sectoral non-conformity under RBI Master Direction on Outsourcing of IT Services, 10 April 2023); (d) "your strategy was selected in 2022 and has not been reviewed despite two major architecture changes" (an L1 non-conformity).

Why This Control Matters

The business case

Clause 8.2 tells you what you cannot afford to lose and for how long. Clause 8.3 is where you spend money to protect it. This is the clause where budgets are committed, contracts are signed, sites are leased, and alternate suppliers are onboarded, or, just as legitimately, where you decide that a manual workaround is sufficient and an expensive DRS would be gold-plating.

The strategic insight is that continuity is a design decision, not a document. An organisation that writes a 200-page BC plan but has never stood up the recovery capability the plan assumes has a piece of fiction, not a strategy. Conversely, an organisation that has quietly engineered an active-active payments stack, cross-trained three people for every critical role, contracted a work-area recovery seat, and dual-sourced its critical cloud dependency has a real strategy, even if the plan document is short. Clause 8.3 forces the question: is the resilience real, or is it only on paper?

The financial logic is straightforward. The BIA quantifies the cost of disruption over time; the strategy selection compares that loss curve against the cost of each solution. The right strategy is the one where the cost of the solution is justified by the loss it avoids, adjusted for the probability of the disruption and the regulatory consequences of failing to recover. For a payments rail processing ₹5,000 crore daily, an active-active architecture costing ₹8 crore a year is obviously justified against a 6-hour outage that would lose ₹125 crore of float and trigger RBI scrutiny. For an internal HR portal, a 24-hour manual workaround costing ₹2 lakh is obviously the right answer. Clause 8.3 is the clause where those decisions are made deliberately, not by default.

The regulatory case (the part competitors omit)

In India, continuity strategy is no longer just an ISO artefact; it is a regulatory deliverable with specific architectural mandates. The instruments that bite hardest on Clause 8.3:

• RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (issued 7 November 2023, effective 1 April 2024). Applies to Scheduled Commercial Banks (excluding Payments Banks, LABs, RRBs), NBFCs with asset base ≥ ₹500 crore, All-India Financial Institutions, and Credit Information Companies. The IT Service Continuity / BCM chapter expects a board-approved BCP/DR policy, documented RTO/RPO for critical systems, a Disaster Recovery Site with defined failover, periodic live/parallel drills, and outsourcer/cloud continuity controls that inherit the RE's continuity standards. The DRS architecture is not optional; it is the mandated strategy shape.
• RBI Master Direction on Outsourcing of IT Services (10 April 2023). Requires Regulated Entities to ensure outsourcer/cloud-provider BCP and DR meets the RE's own continuity standards, with concentration-risk monitoring, exit/termination continuity plans, and right of RBI access to outsourcer controls. This is the supplier resource area of Clause 8.3, made regulatory. A single-cloud critical dependency with no exit strategy is a direct violation.
• RBI Cyber Security Framework in Banks (2 June 2016). Mandates a board-approved cyber-security policy, a Cyber Crisis Management Plan (CCMP), 24x7 SOC, incident reporting to RBI within 2–6 hours of detection, and periodic drills. The CCMP is a strategy document for the cyber-disruption phase.
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF), circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024, with phased 2025 deadlines (some reset by the March 2025 extension circular). Structured as 5 Cyber Resilience Goals × 6 Operational Functions (Identify, Protect, Detect, Respond, Recover, Learn). The Recover function embeds DR-site strategy, backup architecture, and recovery testing for all SEBI Regulated Entities, not just MIIs.
• SEBI BCP/DR Guidelines for Market Infrastructure Institutions, circular SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021, with modifications through 12 September 2024. Requires Near Site (NS) + Disaster Recovery Site (DRS) architecture for exchanges, RTO ≤ 2 hours for critical MII systems, defined RPO, live failover drills, geographic separation, and vendor/dependency BCP. This is the most prescriptive strategy mandate in Indian regulation: it names the topology (NS + DRS), the RTO ceiling (2 hours), and the validation method (live failover).
• IRDAI Information and Cyber Security Guidelines, 2023 (24 April 2023). Requires a board-approved Information & Cyber Security Policy that includes BCP/DR, CISO, 180-day log retention (aligned with CERT-In), vulnerability assessments and pen-testing, DR drills, data-locality for policyholder data, incident reporting to IRDAI and CERT-In, ICT outsourcing continuity oversight, and annual compliance reporting.
• CERT-In Directions No. 20(3)/2022-CERT-In, 28 April 2022. Six obligations, the most consequential being the 6-hour incident reporting clock for ~20 prescribed incident categories. The strategy must include the incident-response capability that makes the 6-hour clock achievable.
• DPDP Act 2023 (Act 22 of 2023). Section 8(5) imposes a statutory duty on Data Fiduciaries to protect the availability of personal data, continuity of personal-data systems is now a data-protection obligation, not just an operational one. Section 8(6) + the Schedule impose breach notification; the DPDP Rules 2025 (final notified November 2025) prescribe the 72-hour notification form. Schedule penalties reach ₹250 crore for failure to take adequate security safeguards and ₹200 crore for failure to notify a breach.
• Disaster Management Act, 2005 and NDMA guidelines (e.g., Chemical Disasters, 2007). For manufacturing, chemicals, and critical infrastructure, the strategy must integrate on-site and off-site emergency plans and mutual-aid arrangements. Section 51–60 create penalties for non-compliance with disaster authority directions during a disaster.

The board-level hooks: Companies Act 2013 §134(3)(n) requires the Board's Report to disclose risk management policy including risks that may threaten the existence of the company; §177 and SEBI LODR Regulation 21 require a Risk Management Committee for listed companies that explicitly covers cyber, operational, and continuity risk. A continuity strategy that the board has never seen is a governance failure, not just a BCM one.

Indian Context (why this hits harder here)

Several structural features of the Indian market make Clause 8.3 materially harder, and materially more valuable, than in most OECD markets:

• Geographic and climatic concentration. Chennai, Mumbai, Hyderabad, Pune, and Bengaluru are simultaneously India's primary delivery hubs and among its most flood-, cyclone-, and seismic-exposed cities. The Chennai floods of December 2015 submerged a major IT/BFSI delivery hub; Cognizant publicly disclosed 11 delivery centres affected. The lesson, now embedded in every Indian IT-services firm's strategy, is that geographic diversity of delivery is a continuity strategy, not a cost-optimisation decision. For growing companies headquartered in one city, the question is whether a single flood can take out both the primary site and the people.
• Power infrastructure exposure. The Mumbai blackout of 12 October 2020 (the cyber link of which is contested, Maharashtra state cited possible cyber sabotage via RedEcho/ShadowPad, while the Union Power Ministry attributed it to human error; present both positions, do not assert) halted local trains, hit hospitals, and affected the BSE for hours. Power continuity (UPS, genset, grid diversity) is upstream of every other technology strategy; a strategy that assumes clean power assumes away the most common Indian disruption.
• Supplier concentration. Indian fintech, SaaS, and BFSI rely heavily on a small number of cloud and payment-rail providers. The Jio outage of 17 September 2024 (a fire at a Jio data centre caused a nationwide outage; Cloudflare Radar measured AS55836 traffic down up to 53%) disrupted Google Cloud in parts of India. The UPI outage of 12 April 2025 (~5 hours, the longest in recent memory) showed that for systemically critical rails, continuity extends beyond the operator to the participating banks and PSPs. Single-supplier strategies are the norm; dual-sourcing is rare; this is precisely where Clause 8.3 bites.
• Skills and key-person risk. The Akasa Air pilot-exodus crisis of 2023 (43 pilots resigned in a single month, ~600–800 flights cancelled, reported losses of ~₹3 crore/day at peak) showed that people continuity is first-class BC for asset-light growth firms. Cross-training, succession, and enforceable notice periods are strategy decisions, not HR policy details.
• Regulatory enforcement that bites. The RBI action against HDFC Bank (2 December 2020, barring new digital products and fresh credit cards pending external IT audit, after repeated digital outages including a 21–22 November 2020 DC power failure) demonstrated that Indian regulators treat repeated continuity failures as board-level governance failures, not IT-ops issues. The ban was partially lifted only around August 2021 and fully by March 2022, a 15-month revenue impact. The strategy was effectively dictated by the regulator after the fact.

Scope and Applicability

By organisation size

By industry

• BFSI (banks, NBFCs, insurers, PSOs, MIIs): The most prescriptive. RBI MD IT Governance mandates DRS with defined failover; SEBI MII BCP-DR mandates Near Site + DRS with RTO ≤ 2 hours for critical systems; IRDAI mandates board-approved BCP/DR and DR drills. Strategy shape is largely dictated: active-passive (warm/hot DRS) minimum for core, active-active for Tier-1 payments/exchange systems. Supplier strategy must include RBI-compliant exit and concentration-risk controls.
• Healthcare (hospitals, pharma, medtech): Life-safety RTOs (minutes for ICU/allergy/prescription lookups). Strategy must include tested manual clinical workflow at MBCO (paper-mode downtime procedures), offline/immutable backups (the AIIMS Delhi 2022 ransomware encrypted both primary and backup servers), and for pharma manufacturing, OT/IT segmentation and NDMA chemical-disaster integration.
• IT/ITeS and SaaS: Delivery is the product. Strategy = geo-diverse delivery centres (the Chennai 2015 lesson), work-from-anywhere, endpoint fleet recovery (the CrowdStrike 19 July 2024 global crash that downed IndiGo check-in but was absorbed by Akasa's manual fallback), and for SaaS, multi-region cloud DR and customer-facing status-page comms.
• Manufacturing (automotive, chemicals, electronics): Production-line continuity. Strategy must address OT/IT segmentation, single-source component and engine risk (the Go First / Pratt & Whitney PW1100G failure), industrial relations (the Maruti Suzuki Manesar 2012 violence and fire), and NDMA on-site/off-site emergency plans for Major Accident Hazard units.
• Government and PSUs: NDMA Disaster Management Plan template (Prevention / Mitigation / Preparedness / Response / Relief / Recovery / Capacity Building); MeitY Cloud policy DR/BCP disclosures for cloud providers serving Government of India; statutory duties under DM Act 2005 §35/37/40.

Key Definitions and Terminology

Clause 8.3 introduces its own vocabulary. The terms below are paraphrased from ISO 22300:2021 and the structure of ISO/TS 22331:2018; where a term has a regulatory equivalent, it is noted.

Strategy vs solution

• Business continuity strategy, the high-level approach selected to keep a prioritised activity running or restore it within its tolerances. The strategy is the what and why: e.g., "for our payments rail, we will use an active-active architecture across two geographically separated data centres, because the BIA sets RTO at near-zero and MTPD at 30 minutes." The strategy is chosen from the options matrix and justified by cost-benefit and BIA fit.
• Business continuity solution, the specific, resourced implementation of the chosen strategy. The solution is the how: e.g., "active-active across Data Centre A (Mumbai) and Data Centre B (Pune), with synchronous replication, automated failover, and a contracted work-area recovery seat for 40 staff in Pune." A solution is funded, contracted, and testable; a strategy without a solution is aspirational.

The distinction matters for auditors: Clause 8.3 requires both. A strategy with no solution is a wish; a solution with no strategy rationale is an unexamined expense.

The three phases (before, during, after)

• Before (prevention and mitigation), actions taken in advance to reduce the likelihood or impact of a disruption: preventive controls (fire suppression, UPS/genset, patching, segmentation), pre-positioned resources (alternate site contracted, backup data seeded, work-area seats booked), training and awareness, supplier due diligence and contractual BCP clauses. The "before" phase is where most strategy investment actually lands.
• During (response and alternate delivery), actions taken from the moment of disruption to the resumption of the activity at MBCO: activation, crisis management, failover to alternate site or manual workaround, graceful degradation, communications to stakeholders and regulators (CERT-In 6-hour clock, RBI/SEBI reporting). The "during" phase is what the Clause 8.4 plans encode.
• After (recovery and restoration), actions taken from resumption at MBCO to full return to normal: restoration of primary site, data reconciliation, catch-up processing, performance validation, post-disruption review (Clause 8.6), and corrective action (Clause 10.1). The "after" phase closes the loop back into strategy revision.

A strategy that addresses only the "during" (failover) but not the "before" (prevention, pre-positioning) or the "after" (restoration, reconciliation) is incomplete and will be flagged.

The four resource areas

ISO 22301 Clause 8.3 explicitly requires the chosen strategies to be resourced across four areas. Each has its own options taxonomy:

• People, the human resources to run the activity during disruption: cross-training (multiple people can perform each critical role), succession (deputy for each key person), work-area relocation staff, welfare and safety, and for large disruptions, surge staffing. Method: ISO/TS 22330.
• Premises, the physical locations from which the activity can be delivered: alternate work sites, work-area recovery seats, geo-diverse delivery centres, and increasingly, work-from-home as a premises strategy. Includes facilities (power, cooling, security, connectivity) at the alternate site.
• Technology (facilities and information), the ICT systems, data, networks, and applications: DRS topologies (cold, warm, hot, active-active/mirror), replication modes (synchronous, asynchronous, near-zero-RPO), backup architecture (online, offline, immutable/air-gapped), network redundancy, and cloud DR. This is where most strategy budget is spent and where most audit scrutiny lands.
• Suppliers, the third parties whose continuity the activity depends on: dual-sourcing, alternate suppliers, contractual BCP clauses, exit and termination continuity plans, supplier DR drill participation, and concentration-risk monitoring. Method: ISO/TS 22318:2021.

Recovery strategy taxonomy (the options matrix)

These are the strategy options from which the selection is made (structure follows ISO/TS 22331:2018):

Critical nuance: insurance and acceptance are legitimate strategy options, but they do not restore the activity, they only address the financial consequence. An auditor will accept them only where the BIA shows the activity can tolerate the disruption (MTPD not breached) or where no feasible solution exists. They are complements to, not substitutes for, a recovery solution.

DRS topology (technology resource area, deepened)

For the technology resource area, the Disaster Recovery Site topology is the core decision. The industry-standard tiers (aligned with the widely-used tiered classification and with SEBI/RBI expectations):

• Tier I / Cold, a designated site with hardware but no data; restore from off-site backups. RTO 24–72 hours. Suitable for non-critical back-office.
• Tier II / Warm (partial), hardware with some data replicated periodically (e.g., nightly). RTO 8–24 hours. Suitable for activities with daily RPO tolerance.
• Tier III / Warm (near-real-time), near-real-time replication; failover with some manual steps. RTO 1–4 hours. The SEBI MII baseline (RTO ≤ 2 hours for critical systems).
• Tier IV / Hot (active-passive), synchronous or near-synchronous replication; automated failover. RTO minutes–1 hour. The RBI expectation for core banking.
• Active/active, two live sites, load-balanced; either serves full load. RTO near-zero. For Tier-1 payments, exchange matching engines, and other near-zero-RTO activities.

The RTO/RPO/MBCO/MTPD spine (recap from 8.2)

The strategy must satisfy the BIA-derived tolerances; they are recapitulated here because 8.3 is the clause where they become engineering targets:

• MTPD (Maximum Tolerable Period of Disruption; also called MAO), when impact becomes intolerable. The ceiling. Discovered from the BIA's impact-over-time analysis.
• RTO (Recovery Time Objective), target resumption time. Must be ≤ MTPD (ideally 25–50% of MTPD, giving a safety margin for execution failure).
• RPO (Recovery Point Objective), max tolerable data loss, measured backward from disruption. Drives replication/backup design. Independent of RTO.
• MBCO (Minimum Business Continuity Objective), minimum service level to resume at. Defines what "resumed" means; RTO defines when; RPO defines how much data is lost.

The strategy's job is to choose solutions whose delivery actually satisfies RTO/RPO/MBCO inside MTPD. APRA CPS 230 (effective 1 July 2025) paragraph 38 is the cleanest regulatory restatement: for each critical operation, set tolerance for (a) maximum period of disruption, (b) maximum extent of data loss, (c) minimum service levels under alternative arrangements, i.e., MTPD, RPO, and MBCO in binding prudential text. DORA (Regulation (EU) 2022/2554, applies 17 January 2025) Article 12(6) requires RTO and RPO per function, considering criticality.

Relationship to Other Clauses and Frameworks

The Clause 8 flow

Clause 8.3 sits at the centre of the Operation clause and is the bridge between analysis and execution:

   8.1 Operational planning & control
            │
            ▼
   8.2 BIA + risk assessment  ────► RTO/RPO/MBCO/MTPD + dependency map + risk register
            │
            ▼
   8.3 Strategy & solutions   ────► Chosen strategy per activity + resourced solutions
            │                     (people, premises, technology, suppliers)
            ▼
   8.4 Plans & procedures     ────► Runbooks that execute the chosen strategy
            │
            ▼
   8.5 Exercise programme     ────► Validates that solutions deliver RTO/RPO/MBCO
            │                     (if not → back to 8.3 to revise strategy)
            ▼
   8.6 Evaluation             ────► Post-disruption / post-change review
            │                     (loops back to 8.2 and 8.3)

The dependency is strict: 8.3 without 8.2 is ungrounded (strategy with no tolerances to satisfy); 8.4 without 8.3 is runbooks with no architecture to run; 8.5 without 8.3 is theatre with nothing to validate.

Cross-framework mapping (real numbers)

Clause 8.3 maps to specific, citable provisions across every major framework. The table below is the load-bearing mapping; fuller detail is in Section 16.

The ISO 223xx companion stack

• ISO/TS 22331:2018 is the strategy-selection how-to (the 8.3 equivalent of what ISO/TS 22317 is to 8.2).
• ISO/TS 22318:2021 extends strategy to supply-chain continuity (the suppliers resource area). Current edition; the 2015 edition is withdrawn.
• ISO/TS 22330 covers the people resource area (succession, cross-training, welfare).
• ISO 22313:2020 is the clause-by-clause companion guidance.

Detailed Implementation Guidance, The Worked Strategy Selection

This section is the practitioner core. It walks through a complete strategy-selection cycle for a representative growing company, showing the artefacts, the decisions, and the trade-offs. The worked example uses a fictional but realistic Indian fintech ("Northstar Payments") processing ~₹400 crore of daily transaction value, with 600 staff across Mumbai (primary) and a small Pune office. Names are illustrative; the numbers are realistic for the segment.

Step 1, Inherit the BIA outputs

The strategy cycle begins with the BIA (Clause 8.2) outputs. For Northstar Payments, the BIA produced:

Without these numbers, strategy selection is guesswork. The first audit question is always: "show me the BIA row for this activity." If the BIA does not exist or is stale, stop and fix 8.2 first.

Step 2, Build the strategy-options matrix

For each prioritised activity, list the feasible strategy options and score them against the BIA-derived tolerances. The matrix below is the core Clause 8.3 artefact.

For the payment switch (RTO 5 min, RPO 0):

Selected: Active/active across two cloud regions (Mumbai + Hyderabad), with synchronous replication and automated health-check failover. The 5-minute RTO and zero-RPO requirements rule out everything below hot DRS; active/active is chosen over hot DRS because the marginal ₹5 crore over three years is trivial against a 30-minute MTPD for a ₹400-crore-daily rail.

For customer support (RTO 2 hr, RPO 1 hr, MBCO 30%):

Selected: Work-from-home fallback (laptops, soft-phone, VPN to cloud CRM) for the primary strategy, with the BPO partner on surge contract for scale. The low cost and low concentration risk of WFH make it the clear winner for a 30% MBCO; the BPO partner covers the throughput gap.

This matrix, one per prioritised activity, is the heart of the Clause 8.3 evidence base. It shows the auditor that the selection was deliberate, criteria-based, and traceable to the BIA.

Step 3, The four resource areas, worked through

For each chosen strategy, document the resourcing across all four areas. Using the payment switch (active/active) as the worked example:

People

• Primary ops team: 12 staff across Mumbai (8) and Hyderabad (4), cross-trained on switch operations, failover procedures, and incident command.
• Cross-training: Every critical role (switch operator, settlement ops, incident commander) has at least two trained alternates. The cross-training matrix is maintained in the BCM register and refreshed quarterly.
• Succession: The Head of Payments has a designated deputy (the Hyderabad ops lead) empowered to declare an incident and authorise failover.
• Surge: A contracted on-call rotation covers off-hours; a 4-person bench at the BPO partner can be activated for reconciliation catch-up post-incident.
• Welfare and safety: For a site evacuation scenario, the people strategy includes a muster protocol, an emergency contact tree, and a work-from-anywhere fallback (laptops, mobile hotspot, cloud access).

Premises

• Primary site: Mumbai office (seating for 8 switch ops + support).
• Alternate site: Hyderabad office (seating for 4 switch ops + support), the active/active architecture means either site can run the switch.
• Work-area recovery: A contracted seat (20 seats, Pune) for the larger business-continuity team in a Mumbai-only evacuation scenario. Contract includes 24-hour activation SLA, dedicated power, and secure connectivity.
• Work-from-home: All ops staff have laptops and secure remote access; for a pandemic or city-wide disruption, the ops function can run distributed.
• Facilities: Both primary and alternate sites have UPS (30 minutes battery) plus diesel genset (72-hour fuel contract), and dual ISP connections from different providers.

Technology

• DRS topology: Active/active across two cloud regions (Mumbai region + Hyderabad region), with the payment switch deployed in both regions behind a global load balancer.
• Replication: Synchronous database replication (zero RPO) for the transaction ledger; near-synchronous for the configuration data.
• Failover: Automated health-check failover (if Mumbai region fails three consecutive health checks, traffic routes to Hyderabad). Failover tested monthly.
• Backups: Hourly immutable snapshots retained 30 days; daily offline backups exported to a separate cloud account with independent credentials (the AIIMS lesson, primary and backup must not share a control plane); weekly backups copied to an offline/object-locked store. Restoration tested quarterly.
• Network redundancy: Dual ISP at each physical site; the cloud DR is in a different region to insulate from a single-region cloud outage (the Jio 17 September 2024 lesson, where a single DC fire took down a nationwide service).
• Endpoint resilience: Laptops configured to function without the corporate VPN for critical SaaS; golden images and patch-management that validates updates before fleet-wide deployment (the CrowdStrike 19 July 2024 lesson).

Suppliers

• Cloud provider: Primary cloud in Mumbai region; DR in Hyderabad region of the same provider (the provider's own region-pair DR). Concentration risk acknowledged: a provider-wide outage would affect both regions. Mitigation: a documented exit strategy, quarterly provider DR drill participation, and a monitored option to replicate the switch to a second provider (cost-justified but not yet stood up, a conscious risk-acceptance documented in the strategy).
• UPI rails (NPCI): Dependency on NPCI's UPI infrastructure. The 12 April 2025 UPI outage (~5 hours) showed this is a systemic dependency the organisation cannot fully control. Strategy: participate in NPCI's ecosystem drills, maintain a manual queue-and-reconcile mode for when UPI is unavailable, and monitor NPCI's own resilience communications.
• KYC vendor: Dual-sourced (primary + alternate onboarded); the alternate can be switched to within 4 hours.
• BPO partner: Contract includes BCP clauses (their own DR site, 24-hour activation for surge, right of audit of their BCP), aligned with RBI MD Outsourcing of IT Services (10 April 2023).
• Telecom: Dual ISP (different providers, different physical paths) at each site.

Step 4, Cost-benefit analysis and the loss-avoided logic

The strategy selection must include a cost-benefit analysis that compares the cost of the solution against the loss it avoids. For Northstar Payments' payment switch:

• Cost of active/active: ~₹14 crore over three years (infrastructure + replication + work-area + cross-training).
• Loss avoided: The BIA quantified a 30-minute outage of the payment switch at ~₹35 crore (lost float, SLA penalties, reputational impact, regulatory scrutiny). The MTPD is 30 minutes, so any outage beyond that is "intolerable."
• Probability: The BIA risk assessment estimated a ~20% annual probability of a disruption exceeding 30 minutes without active/active (based on cloud-outage frequency, regional risk, and cyber-attack likelihood).
• Expected annual loss without strategy: 0.20 × ₹35 cr = ₹7 cr/year, or ₹21 cr over three years.
• Expected residual loss with active/active: Near-zero (the strategy delivers near-zero RTO).
• Net benefit: ₹21 cr loss avoided − ₹14 cr solution cost = ₹7 crore net benefit over three years, plus regulatory compliance (RBI MD IT Governance) and reputational protection.

This calculation, documented per activity, is what transforms the strategy from an expense into a justified investment. It is also what the Board's Risk Committee needs to see under Companies Act 2013 §134(3)(n) and SEBI LODR Regulation 21.

Step 5, Validate fit (the strategy must deliver)

Selecting a strategy is not enough; Clause 8.3 requires evidence that the chosen solution actually delivers the RTO/RPO/MBCO from the BIA. This is validated in three ways:

1. Engineering validation, the solution architecture is reviewed against the RTO/RPO targets. For active/active, this means confirming the replication mode (synchronous = zero RPO), the failover automation (health-check driven, sub-minute), and the capacity (each region sized for full load).
2. Test validation (Clause 8.5), periodic failover tests measure achieved RTO/RPO against target. The first failover test is the moment of truth: if the achieved RTO is 12 minutes against a 5-minute target, the strategy does not fit and must be revised. This is why 8.3 and 8.5 are tightly coupled.
3. Real-event validation, actual disruptions (a region outage, a failed deployment, a ransomware attempt) are the ultimate test. Post-disruption review (Clause 8.6) feeds back into strategy revision.

Step 6, Top-management approval and the resourcing commitment

The strategy is not final until top management approves it and commits the resources. This is not a rubber stamp: the approval must include:

• The strategy-options matrix (what was considered, what was chosen, why).
• The cost-benefit analysis (what it costs, what it avoids).
• The resourcing plan (who, what premises, what technology, which suppliers, and the budget/contracts that make them real).
• The risk-acceptance log (where the organisation consciously accepted a risk, e.g., single-cloud for now, with a documented mitigation plan).

For BFSI, this approval flows to the Board's Risk/IT Committee under RBI MD IT Governance and SEBI LODR Reg 21. The approval minutes are audit evidence.

Step 7, Feed Clause 8.4 and schedule the review

The approved strategy is the design specification for the Clause 8.4 plans. Each plan encodes the chosen strategy: the active/active payment switch plan describes the failover runbook; the customer-support plan describes the WFH activation. The strategy-to-plan traceability is what the auditor checks.

Finally, schedule the review: at minimum annually, and on trigger, major architecture change, new product, M&A, post-incident (Clause 8.6), post-exercise that exposed drift (Clause 8.5), and when the BIA itself changes.

Tools, Technologies, and Solutions

Per the IP-and-sourcing rules that govern this series, this section is at the category level, no vendor names appear. Shortlist candidates within each category, evaluate against the criteria in toolkit doc 14, and verify capability, India presence, and pricing on the vendor's official domain.

Tool categories for Clause 8.3

1. BCM suites with a strategy-selection module, the system of record for the strategy-options matrix, the resourcing plan, and the traceability to BIA and plans. Enterprise IRM suites (BCM as one module) and specialist BCM SaaS platforms both fit; specialists often have deeper strategy-selection workflows, enterprise IRM broader integration. This is the same platform class that supports 8.2; ideally the BIA and strategy live in one tool.
2. DR replication tech, the technology that makes the DRS topology real: storage-level replication, hypervisor-level replication, database replication, and cloud-region failover. The choice of replication mode (synchronous vs asynchronous) directly determines achievable RPO.
3. Immutable-backup platforms, backup solutions that protect against ransomware encryption of backups (the AIIMS failure: both primary and backup encrypted). Look for object-lock / WORM storage, air-gapped copies, and independent credentials. This is a core ransomware-resilience strategy.
4. Cloud DR / resilience hubs, cloud-native tools that assess, orchestrate, and fail over cloud workloads across regions or providers. Essential for SaaS and cloud-native firms.
5. Work-area recovery providers, contracted alternate-office facilities with seats, power, cooling, and connectivity, activated on notice. India has several providers in Mumbai, Pune, Bengaluru, Hyderabad, and the NCR.
6. ITSM-platform CMDB / dependency-mapping tools, for maintaining the dependency map that feeds the supplier and technology resource areas. Often the same ITSM platform already in use.
7. Risk-register / IRM platforms, for the concentration-risk and supplier-risk dimensions of the strategy.

Category-level cost bands (India, growing companies)

All figures are illustrative third-party estimates, not Singahi pricing. Costs vary widely by negotiation, scale, and India-region availability.

Selection guidance

• Start with the BIA tool. If you already have a BCM suite for Clause 8.2, use its strategy module for 8.3 rather than introducing a second tool, the traceability is the value.
• Separate the strategy tool from the DR tech. The BCM suite records the strategy; the DR replication tech executes it. They are different procurements with different owners (BCM Lead vs IT DR).
• For ransomware resilience, prioritise immutable backups. The AIIMS, Cognizant Maze (SEC-filed, $50–70M Q2 2020 impact), and Sun Pharmaceutical (2023) cases all show that traditional backups that share a control plane with production are not a strategy, they are a single point of failure.
• For work-area recovery, contract before you need it. The contracted seat is cheap relative to the cost of not having it. Growing companies can typically secure 10–50 seats for ₹3–15 lakh/year.
• For cloud DR, test cross-region failover. The Jio 17 September 2024 DC fire showed that a single-region cloud deployment is not a DR strategy. Test that your failover actually works, this is a Clause 8.5 requirement but the strategy must enable it.

Policy and Procedure Templates

The full templates are in the toolkit (docs 01 and 02). The key elements, paraphrased:

Business Continuity Strategy Policy (doc 01)

The policy is the top-management-approved statement that mandates strategy selection and resourcing. Sample "shall" clauses (Singahi's own drafting, for your adaptation):

• "The organisation shall identify and select continuity strategies and solutions for every prioritised activity identified in the BIA, covering the period before, during, and after a disruption."
• "The organisation shall resource each chosen strategy across the four resource areas: people, premises, technology, and suppliers."
• "Each chosen strategy shall demonstrably satisfy the RTO, RPO, and MBCO derived in the BIA for the corresponding activity."
• "Strategy selection shall be based on a documented cost-benefit analysis that considers the cost of the solution against the loss avoided."
• "The organisation shall review and, where necessary, revise the continuity strategy at least annually, and on the occurrence of a trigger event including major change, a new product or service, a disruption, or an exercise that exposes drift."
• "For outsourced critical activities, the organisation shall ensure that the supplier's BCP and DR arrangements meet the organisation's own continuity standards, and that an exit or termination continuity plan is documented."

Strategy Selection Procedure (doc 02)

The procedure is the operating steps for one strategy-selection cycle (covered in Section 7 above, formalised in the toolkit). It covers: inherit BIA outputs; build options matrix; score options; select; resource the four areas; cost-benefit; validate fit; approve; feed 8.4; schedule review.

Risk Assessment and Treatment

Clause 8.3 inherits the risk assessment from 8.2 but adds strategy-specific risks that must be assessed and treated:

Strategy-level risks

• Single-point-of-failure risk, a chosen solution that itself has a single point of failure (e.g., a DRS that shares the primary's auth domain, so a ransomware attack encrypts both). Treatment: immutable/air-gapped backups, independent credentials, segmentation.
• Concentration risk, over-reliance on a single supplier, cloud provider, data centre, or region. Treatment: dual-sourcing, multi-region, documented exit plans, contractual BCP clauses. This is the RBI MD Outsourcing and DORA Art 29 core concern.
• Strategy-BIA mismatch risk, a chosen solution that cannot achieve the BIA's RTO/RPO. Treatment: engineering validation and Clause 8.5 failover testing; revise strategy if fit fails.
• Untested strategy risk, a solution that has never been failed over to. Treatment: mandatory annual failover test (APRA CPS 230 para 43; SEBI MII live drills; IRDAI DR drills).
• Resource-availability risk, a strategy that assumes people, seats, or bandwidth that may not be available during a disruption (e.g., a work-area seat in the same city as the primary). Treatment: geographic separation, contracted SLAs, work-from-home fallback.
• Supplier-failure risk, a critical supplier whose own BCP is inadequate. Treatment: supplier BCP questionnaires (toolkit doc 10), right of audit, dual-sourcing, exit plans.

Treatment options

Treatment follows the standard ISO 31000 hierarchy: avoid (change the architecture to remove the risk), reduce (add controls, redundancy, segmentation, testing), transfer (insurance, contractual risk transfer), accept (consciously, with documentation and top-management sign-off). The key Clause 8.3 requirement is that the treatment is documented and approved, silent acceptance is a non-conformity.

Audit and Compliance Checklist

The following 25 questions reflect what certification auditors and regulators actually probe. Each has expected evidence and a red flag.

Metrics and KPIs

Process KPIs

Outcome KPIs

Leading-indicator KPIs

Common Pitfalls and Audit Failures

"We have a DR site, never failed over to it"

The single most common Clause 8.3 finding. A DRS contract is not a strategy; a DRS that has never been tested is a liability, not an asset. The auditor will ask for the last failover test report; if it does not exist or is > 12 months old, it is a non-conformity. The fix is simple: test it (Clause 8.5), measure the achieved RTO/RPO, and revise the strategy if it does not fit.

"RTO set in the meeting room, not the BIA"

A strategy that targets an RTO that was not derived from the BIA's impact-over-time analysis is ungrounded. The auditor traces the RTO back to the BIA; if the chain breaks ("we picked 4 hours because that's what our DRS vendor quoted"), the strategy does not satisfy Clause 8.3. Fix: re-derive the RTO from the BIA and adjust the strategy if needed.

"Single-vendor everything"

The concentration-risk trap. A single cloud provider, a single DRS, a single telecom, a single KYC vendor, all in the same region. The strategy "document" lists redundancy, but every redundant component is the same vendor in the same place. The Jio 17 September 2024 DC fire and the UPI 12 April 2025 outage are the lessons. Fix: identify concentration points; dual-source where feasible; document exit plans where not.

"Backups share the production control plane"

The AIIMS Delhi 2022 pattern: ransomware encrypted both primary and backup servers because they shared authentication and network access. A backup that can be encrypted alongside the primary is not a backup, it is a second copy of the same vulnerability. Fix: immutable/object-locked backups, air-gapped copies, independent credentials, separate cloud account.

"Technology strategy with no people strategy"

A classic gap: the DRS is contracted and tested, but nobody asked who staffs it during a Mumbai evacuation. The technology resource area is resourced; the people resource area is not. Fix: cross-training matrix, alternate staffing, work-area recovery for the people, welfare and safety provisions.

"Strategy covers 'during' but not 'before' or 'after'"

The strategy document describes failover but not prevention, pre-positioning, restoration, reconciliation, or post-incident review. A strategy that only covers the middle phase is incomplete. Fix: explicitly address all three phases (before, during, after) per activity.

"Strategy is an IT document, not a business decision"

The strategy was written by the IT team, approved by the IT Director, and never seen by the business or the Board. The cost-benefit was never done; the resourcing was never committed. Fix: top-management approval, Board Risk Committee visibility, cost-benefit per activity.

"No strategy for critical suppliers"

The Go First pattern: the organisation's strategy assumes its critical supplier will always deliver, but the supplier's own BCP was never verified. Fix: supplier BCP questionnaires, contractual BCP clauses, right of audit, dual-sourcing, exit plans (RBI MD Outsourcing of IT Services, 10 April 2023).

Illustrative Scenario 1: Failure, Go First and the Single-Source Engine Trap

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

Illustrative scenario. The following is a paraphrased account drawn from public reporting (The Hindu; Reuters; LiveMint; NCLT filings) and used here for teaching. Some figures are from the airline's own disclosure dated 31 July 2023.

What happened

Go First (formerly GoAir), a Wadia Group airline, filed for voluntary insolvency before the National Company Law Tribunal on 2 May 2023, blaming Pratt & Whitney PW1100G geared turbofan engine failures (allegedly caused by contaminated powdered-metal in the engine's high-pressure turbine) for grounding approximately half its fleet of around 55 Airbus A320neo aircraft. The airline cancelled all flights from 3 May 2023; they never resumed. The DGCA later deregistered 54 aircraft at lessors' requests, and the Committee of Creditors moved the airline toward liquidation. In its disclosure of 31 July 2023, Go First stated a refund liability of approximately ₹597 crore owed to around 15.5 lakh (1.55 million) passengers. By April 2025, the airline was moving toward liquidation and refunds had largely stopped. The groundings also triggered sector-wide airfare spikes.

Why it is a Clause 8.3 failure

Go First is a textbook Clause 8.3 failure in the suppliers resource area, specifically, single-source supplier concentration with no viable alternate strategy:

• Single-source engine dependency. The A320neo fleet was equipped exclusively with PW1100G engines. While the A320neo airframe offers an engine option (CFM LEAP-1A is the alternative), Go First had committed to the Pratt & Whitney variant across its fleet. For an airline, engine availability is the business, without airworthy engines, no flight departs. The dependency map should have flagged this as a single point of failure with no in-fleet alternate.
• No alternate-supply strategy. The continuity strategy for "operate the flight schedule" depended entirely on Pratt & Whitney delivering serviceable engines and MRO turnaround within a feasible window. There was no documented alternate: no leased-engine arrangement, no fleet diversification toward CFM, no capacity-sharing mutual-aid with another carrier, no insurance structure that could substitute for the lost operating capability. The strategy was, in effect, "accept that P&W delivers", a silent risk-acceptance with no documentation or mitigation.
• No buffer or redundancy. The airline operated with minimal spare-engine inventory and no slack in the fleet for a sustained grounding. When the powder-metal contamination issue affected a large batch of engines simultaneously, there was no buffer to absorb it.
• The "before" phase was missing. A defensible supplier-continuity strategy would have included, in the "before" phase: supplier health monitoring (P&W's powder-metal issue was known to the industry for years before Go First's collapse), engine-diversification in fleet planning, spare-engine leases, and a documented trigger for invoking an alternate-supply plan. None of this appears to have existed at a level that could absorb the disruption.
• The regulatory and commercial consequence. The failure was not merely operational, it was existential. The NCLT insolvency, the ₹597 crore refund liability, the loss of the entire business, and the sector-wide impact (airfare spikes affecting consumers) illustrate that for some activities, continuity strategy is not about recovering from a disruption; it is about preventing the disruption from becoming terminal.

What "good" would have looked like

A defensible Clause 8.3 supplier strategy for a single-engine-type fleet would have produced:

• A dependency map flagging PW1100G as a single point of failure for "operate the flight schedule," with the MTPD for fleet grounding set at days-to-weeks (after which the airline cannot survive as a going concern).
• A strategy-options matrix considering: engine-type diversification (mixed PW/CFM fleet in future orders), leased spare engines, capacity-sharing or wet-lease arrangements with another carrier, insurance for groundings, and a conscious risk-acceptance of the single-source exposure with documented mitigation.
• A resourcing plan: spare-engine lease budget, a wet-lease standby agreement, a fleet-planning policy mandating engine-option diversification, and a supplier-health monitoring programme.
• A cost-benefit analysis comparing the cost of diversification against the loss avoided, the ₹597 crore refund liability alone dwarfs any plausible diversification cost.
• A "before" phase: active monitoring of P&W service bulletins, an escalation path with the supplier, a pre-defined grounding threshold that triggers the alternate-supply plan.

Lessons for Indian industry

Go First is the clearest recent Indian example of a supplier-continuity strategy failure. The lesson generalises beyond airlines: any organisation whose critical activity depends on a single supplier with no viable alternate, a single cloud provider for a SaaS firm, a single API vendor for a fintech, a single component supplier for a manufacturer, a single offshore delivery centre for an IT-services firm, carries the same structural risk. ISO/TS 22318:2021 (supply chain continuity) is the method; RBI MD Outsourcing of IT Services (10 April 2023) and DORA Art 29 (concentration risk) are the regulatory teeth. The auditor's question is simple: "if your single critical supplier fails, what is your strategy, and is it resourced?"

Illustrative Scenario 2: Success, Akasa Air and the Manual-Fallback Strategy

Illustrative scenario. The following is a paraphrased account drawn from public reporting (Emerald EEMCS illustrative scenario; LiveMint; The Hindu) and used here for teaching. The contrast with IndiGo's 283 cancellations the same day is the teaching point.

What happened

On 19 July 2024, a faulty content update to a widely-used endpoint security agent caused a global blue-screen crash on Windows hosts, the CrowdStrike incident. Indian airlines were hit hard: IndiGo, the country's largest carrier, saw its check-in, booking, and airport systems crash and cancelled 283 flights on 19 July 2024, with long queues and manual check-ins at Mumbai, Delhi, Bengaluru, and Hyderabad. Akasa Air, a newer and smaller carrier, was hit by the same endpoint crash, but claimed zero flight cancellations, switching to manual booking and check-in procedures and keeping its schedule operating.

Why it is a Clause 8.3 success

Akasa's performance is a Clause 8.3 success in the technology and people resource areas, specifically, the selection and resourcing of a manual-workaround strategy as the continuity solution for check-in and booking during an endpoint-system failure:

• A manual workaround was a deliberately selected strategy, not a heroic improvisation. The strategy-options matrix for "check-in and boarding" should list, among other options, "manual check-in using printed manifests and hand-written boarding passes at MBCO." For most airlines, this option exists on paper but is never resourced or practised. Akasa appears to have resourced it: staff were trained, the manual process was documented, and the stations had the printed materials and authority to switch to manual mode.
• The MBCO was defined. Manual check-in is slower; the MBCO for the activity is "100% of flights depart, with longer check-in queues and slower boarding." Akasa accepted the throughput reduction but protected the schedule, the right trade-off for an airline where a cancelled flight is far more costly than a delayed boarding.
• The people resource area was resourced. Manual check-in requires more staff per gate and empowered station staff who can authorise the switch without waiting for head-office approval. The cross-training and authority delegation are the people strategy.
• The technology strategy enabled the fallback. The manual process depends on having access to the passenger manifest (printed or on a non-affected device) and the ability to reconcile after systems return. The technology strategy was not "prevent the endpoint crash" (impossible for a single airline) but "survive the endpoint crash by degrading gracefully to manual mode."
• The contrast is the lesson. IndiGo, the larger and more resourced carrier, cancelled 283 flights. Akasa, the smaller and newer carrier, cancelled zero. The difference was not scale or budget, it was strategy. IndiGo's check-in continuity appears to have depended on the endpoint systems being available; when they crashed, there was no resourced fallback. Akasa's strategy treated manual mode as a real, resourced, practised option.

The ROI of the strategy

The return on investment of a manual-workaround strategy is measured in losses avoided:

• Avoided cancellation cost. An airline cancellation costs roughly ₹50,000–₹2 lakh per domestic flight (passenger rebooking/refund, crew repositioning, slot loss, reputational impact). For a carrier of Akasa's size (~30–60 daily flights), avoiding a day of cancellations saves on the order of ₹1.5–12 crore in direct and indirect costs, and, critically, preserves the brand and customer trust that a startup airline cannot afford to lose.
• Avoided regulatory scrutiny. Mass cancellations attract DGCA attention (the SpiceJet 2022 enhanced surveillance and 50% schedule cap is the cautionary tale). Avoiding cancellations avoids that escalation.
• Cost of the strategy. Manual-workaround resourcing is cheap: documentation, printed forms, staff training, periodic drills. The annual cost is on the order of ₹5–15 lakh, trivial against the avoided loss.
• Net benefit. A single day of avoided cancellations pays for years of manual-workaround strategy investment. This is the cost-benefit analysis that justifies the strategy.

Lessons for Indian industry

Akasa's success generalises: the cheapest continuity strategy is often a well-rehearsed manual workaround, and the most expensive strategy is an untested technology solution that fails on the day. For growing companies, the lesson is that Clause 8.3 is not about buying the most expensive DRS, it is about selecting, for each activity, the strategy that fits its RTO/RPO/MBCO at the right cost. For check-in (where MBCO is "flights depart, queues longer"), manual is the right strategy. For a payment switch (where MBCO is "100% throughput, zero data loss"), only active/active will do. The art of Clause 8.3 is matching the strategy to the activity, and resourcing whichever strategy is chosen, whether it is a ₹14-crore active/active stack or a ₹5-lakh manual-process drill.

Multi-Framework Mapping

The table below maps Clause 8.3 to specific, citable provisions across the major frameworks. Cells with an article/paragraph number are direct cross-references; cells with a name only are methodological analogues.

How to use this mapping

• For BFSI serving the EU: DORA Art 12(6) (RTO/RPO per function) and Art 29 (concentration risk) are the direct foreign obligations. An Indian fintech or IT/BPO serving EU financial entities must be able to show its Clause 8.3 strategy satisfies DORA's per-function RTO/RPO and concentration-risk expectations, DORA applies to the EU client, and the Indian provider inherits it contractually.
• For BFSI with Australian exposure: APRA CPS 230 para 38 is the cleanest regulatory statement of the MTPD/RPO/MBCO triple. Citing it earns credibility, a prudential regulator has set the tolerance dimensions in binding text.
• For US-listed or US-banking-adjacent: NIST SP 800-34 Steps 3–4 and the FFIEC BCM Booklet give the US framing; SOC 2 Availability is the audit-grade outcome.
• For multi-framework firms: The ISO 22301 Clause 8.3 strategy document can serve as the master, with crosswalks to DORA, CPS 230, NIST, FFIEC, and ISO 27001, this is the "integrated compliance" play that reduces redundant effort.

Implementation Roadmap

A phased 30/90/180-day roadmap for a growing company (50–2,000 staff) implementing Clause 8.3 for the first time. Milestones: M0 (start), M30, M90, M180.

Days 0–30 (M0–M30): Foundation

• M0: Confirm BIA (Clause 8.2) is current and approved; identify the top 10–20 prioritised activities and their RTO/RPO/MBCO/MTPD. If the BIA is stale, fix 8.2 first, 8.3 cannot proceed without it.
• M0–M15: Stand up the strategy-selection working group (BCM Lead, IT DR, Facilities, HR, Procurement, business owners for top activities). Brief on Clause 8.3, ISO/TS 22331:2018, and the regulatory landscape (RBI/SEBI/IRDAI/CERT-In/DPDP as applicable).
• M15–M30: Draft the strategy-options matrix for the top 5–10 activities (rows = activities, columns = strategy options, cells = RTO/RPO fit and cost band). Identify the current (as-is) strategy per activity and the gap to the BIA-derived target.

M30 milestone: Strategy-options matrix draft for top 5–10 activities; gap list; working group chartered.

Days 31–90 (M30–M90): Selection and resourcing

• M30–M60: Complete the options matrix for all top 10–20 activities. Run the cost-benefit analysis per activity. Select the target strategy per activity. Document the selection rationale and the risk-acceptance log.
• M60–M90: Resource the four areas for the selected strategies: initiate DRS contracting (or validate existing), contract work-area recovery (if not in place), begin cross-training for critical roles, issue supplier BCP questionnaires to critical suppliers, draft exit plans for critical ICT providers. Prepare the top-management approval pack.

M90 milestone: Strategy selected and resourced for top 10–20 activities; approval pack ready; resourcing contracts initiated.

Days 91–180 (M90–M180): Validation and integration

• M90–M120: Top-management (Board Risk Committee for BFSI/listed) approval of the strategy and resourcing commitment. Feed the approved strategy to Clause 8.4 plan authors.
• M120–M150: Engineering validation of fit (does the solution architecture deliver the RTO/RPO?). Schedule the first failover test (Clause 8.5) for the top 3–5 activities.
• M150–M180: Execute the first failover tests; record achieved RTO/RPO; revise strategy where fit fails. Complete the supplier BCP attestation cycle. Publish the strategy coverage dashboard (KPIs).

M180 milestone: Strategy approved, resourced, and initially validated for top activities; integrated with 8.4 plans; first failover test done; dashboard live.

Beyond 180 days

• Roll the strategy cycle to the next tier of activities (activities 21–60).
• Mature the cost-benefit to quantitative loss modelling for Tier-1 activities.
• Integrate with the BIA tool and CMDB for dependency-driven strategy updates.
• Build the cross-framework crosswalk (DORA, CPS 230, NIST, FFIEC, ISO 27001).
• Establish the annual strategy review and the event-trigger review (post-incident, post-exercise, on major change).

FAQ

Q1. Do we need a DRS for every system? No. You need a continuity strategy for every prioritised activity. For some activities, a manual workaround, work-from-home, or acceptance is the right strategy. The DRS is one technology option, appropriate where the BIA-derived RTO/RPO cannot be met by simpler means. Buying a DRS for every system regardless of BIA is gold-plating, not compliance.

Q2. Is a manual workaround acceptable to auditors? Yes, if it is documented, resourced, practised, and delivers the MBCO. The Akasa Air example shows a manual workaround can outperform a multi-crore technology solution that was never tested. The auditor's test is whether the workaround actually delivers the RTO/RPO/MBCO, not whether it is expensive.

Q3. We are a SaaS company using a single cloud provider. Is that a Clause 8.3 failure? Not necessarily, but it is a concentration risk that must be identified and treated. If your BIA-derived RTO/RPO can be met by the provider's own multi-region DR, and you have tested failover, and you have a documented exit strategy, that may be acceptable. If you have a single region, no exit plan, and no test, it is a non-conformity, and a violation of RBI MD Outsourcing of IT Services if you are a regulated entity.

Q4. How often must the strategy be reviewed? At least annually, and on trigger: major architecture change, new product or service, M&A, post-incident (Clause 8.6), post-exercise that exposed drift (Clause 8.5), and when the BIA itself changes. A strategy reviewed only at certificate-renewal time is a non-conformity.

Q5. Does Clause 8.3 require insurance? No. Insurance is one strategy option (risk transfer), but it does not restore the activity, it only addresses financial consequence. It is a complement to, not a substitute for, a recovery solution. An auditor will accept insurance where the BIA shows the activity can tolerate the disruption or where no feasible solution exists; it is not a blanket answer.

Q6. What is the difference between a strategy and a solution? The strategy is the high-level approach (e.g., "active/active across two regions"). The solution is the specific, resourced implementation (e.g., "active/active across Mumbai and Hyderabad regions with synchronous replication and automated failover"). Clause 8.3 requires both: a strategy with no solution is aspirational; a solution with no strategy rationale is an unexamined expense.

Q7. How does Clause 8.3 relate to ISO 27001 A.5.30 (ICT readiness)? They overlap heavily. ISO 27001 A.5.30 requires ICT services to meet continuity requirements, which is 8.3's technology resource area in ISMS language. An organisation certified to both standards can use one strategy document to satisfy both, with a crosswalk. The key difference: ISO 22301 is business-activity-centric; ISO 27001 is information-security-service-centric.

Q8. Our BIA says RTO of 2 hours, but our DRS vendor says they can only do 4 hours. What do we do? This is a strategy-BIA mismatch, a Clause 8.3 finding. You have three options: (a) revise the solution (find a vendor or architecture that delivers 2 hours, hot DRS or active/active); (b) revise the BIA (if the 2-hour RTO was not well-derived, re-derive it, but do not relax it just to fit the vendor); (c) accept the risk consciously, with top-management sign-off and a mitigation plan. Option (c) is legitimate only if the MTPD is not breached by the 4-hour recovery.

Q9. Do we need to test failover to production? For the highest-criticality activities, yes, a live failover (or at least a failover to a production-equivalent environment) is the only way to validate the strategy. SEBI MII BCP-DR requires live failover drills; APRA CPS 230 para 43 requires an annual exercise. For lower-criticality activities, a tabletop or simulation may suffice. The test depth should match the activity's criticality.

Q10. How do we handle a supplier whose BCP we cannot verify? If the supplier is critical and will not share BCP evidence, treat it as a single point of failure: dual-source, build an exit plan, and document the risk-acceptance. For RBI-regulated entities, the RBI MD Outsourcing of IT Services gives you the right to require BCP evidence and right of audit as a contractual term, use it.

Industry-Specific Requirements

BFSI (Banks, NBFCs, Insurers, PSOs, MIIs)

The most prescriptive sector. Strategy shape is largely dictated:

• Banks/NBFCs (RBI MD IT Governance, eff 1 Apr 2024): Board-approved BCP/DR policy; documented RTO/RPO for critical systems; DRS with defined failover; periodic live/parallel drills; outsourcer/cloud continuity inheriting the RE's standards. Minimum strategy: warm/hot DRS for core banking; active/active for Tier-1 payments.
• MIIs (SEBI BCP-DR, 22 Mar 2021 + mods 12 Sep 2024): Near Site + DRS architecture; RTO ≤ 2 hours for critical systems; defined RPO; live failover drills; geographic separation; vendor/dependency BCP. The NS + DRS topology is mandated.
• Insurers (IRDAI Guidelines, 24 Apr 2023): Board-approved BCP/DR; 180-day logs; DR drills; ICT outsourcing continuity oversight; data locality for policyholder data.
• PSOs (RBI PSO cyber resilience MD): Board-approved cyber resilience framework with BCP/DR.
• Cross-border (DORA, eff 17 Jan 2025): For Indian IT/BPO serving EU financial entities, the strategy must satisfy DORA Art 12(6) per-function RTO/RPO and Art 29 concentration risk, inherited contractually.

Healthcare (Hospitals, Pharma, Medtech)

• Hospitals: Life-safety RTOs (minutes for ICU/allergy/prescription lookups). Strategy must include tested manual clinical workflow at MBCO (paper-mode downtime procedures), offline/immutable backups (AIIMS lesson), and for EMR, an isolated read-only viewer for recent records. IRDAI Guidelines apply to insured services.
• Pharma manufacturing: OT/IT segmentation; isolated OT segments; validated backups; regulated-disclosure playbook (Sun Pharmaceutical 2023 disclosure is the model). NDMA Chemical Disaster Guidelines (2007) apply to Major Accident Hazard units.
• Medtech/SaaS health: DPDP §8(5) availability duty for personal/health data; strategy must include personal-data-system continuity and breach notification (DPDP Rules 2025: 72-hour notification).

IT/ITeS and SaaS

• Delivery continuity: Geo-diverse delivery centres (Chennai 2015 lesson); work-from-anywhere; endpoint fleet recovery (CrowdStrike 19 July 2024 lesson); for SaaS, multi-region cloud DR and customer-facing status-page comms.
• Customer-facing SLAs: The strategy must deliver the uptime committed in customer contracts, SOC 2 Availability is the audit grade.
• Supply-chain pivot risk: The Wipro 2019 phishing breach (attackers pivoted through the vendor to its customers) showed that for IT-services firms, the customer's BC depends on the vendor's identity security. Strategy includes MFA, PAM, SOC detection on internal admin paths.

Manufacturing (Automotive, Chemicals, Electronics)

• OT/IT segmentation: Production-line continuity requires OT networks segmented from IT; ransomware that crosses the boundary stops production (Tata Technologies 2023, Bajaj Auto).
• Single-source component risk: The Go First / P&W engine failure is the cautionary tale. Strategy includes dual-sourcing critical components, inventory buffers, and alternate-supplier onboarded.
• Industrial relations: The Maruti Suzuki Manesar 2012 violence and fire (GM-HR killed, ~₹1,400 crore lockout loss) showed workplace violence is a disruption scenario. Strategy includes security, mutual-aid with police, and alternate-site production.
• NDMA integration: On-site and off-site emergency plans for MAH units; integration with District Disaster Management Plans.

Government and PSUs

• NDMA Disaster Management Plan template (Prevention / Mitigation / Preparedness / Response / Relief / Recovery / Capacity Building); DM Act 2005 §35/37/40 duties.
• MeitY Cloud policy DR/BCP disclosures for cloud providers serving Government of India; empanelment requires DR evidence.
• Statutory duties under DM Act §51–60 (penalties for non-compliance with disaster authority directions).

Maturity Model

The maturity model below uses a five-level scale (L1–L5). The INR figures are indicative cumulative investment ranges (one-time + ongoing) for a growing-company-scale organisation (50–2,000 staff); they scale up for enterprise.

Level 1, Initial / Ad hoc

• A strategy document exists for the top 3–5 activities; DRS identified for core systems; manual workarounds noted informally; reviewed yearly.
• No options matrix; no cost-benefit; no formal resourcing plan.
• People/premises/suppliers areas largely unaddressed.
• Indicative investment: ₹3–12 lakh of internal effort. Tooling: spreadsheet + existing DR contract.
• Audit posture: Stage 1 finding; not conformant.

Level 2, Repeatable

• Strategy-options matrix documented for top 10–20 activities.
• Selected strategy per activity; cost-benefit informal; resourcing plan for technology (DRS) and partial for people.
• Annual review in place; event-trigger informal.
• Work-area recovery considered; supplier BCP questionnaires sent to top suppliers.
• Indicative investment: ₹12–40 lakh cumulative. Tooling: structured workbook + DR contract + work-area contract.
• Audit posture: Stage 1 pass with L2 minor findings on people/premises/suppliers completeness.

Level 3, Defined

• Full ISO/TS 22331:2018-aligned strategy-selection methodology.
• All prioritised activities have options matrix, selected strategy, cost-benefit, four-area resourcing plan.
• Engineering validation of fit; first failover tests done.
• Top-management approval; Board Risk Committee visibility (for BFSI/listed).
• Supplier BCP attestations current; exit plans for critical ICT providers.
• BCM tooling introduced (SMB BCM SaaS or structured CMDB-backed workbook).
• Indicative investment: ₹40 lakh–₹1.5 crore cumulative. Tooling: ₹12–40 lakh/yr.
• Audit posture: Stage 2 certifiable.

Level 4, Managed (measured)

• Integrated strategy/BIA/CMDB/risk tooling (enterprise IRM/BCM suite).
• Active-active or hot DRS validated by regular failover for Tier-1; work-area recovery contracted and tested; dual-sourced critical suppliers.
• Quantitative loss modelling for top activities; cost-benefit per activity.
• Full traceability to Clause 8.4 plans and 8.5 exercises.
• Board-level strategy coverage dashboard with RTO/RPO achievement trends.
• Indicative investment: ₹1.5–4 crore cumulative. Tooling: ₹40 lakh–₹2.5 crore/yr.
• Audit posture: Mature certified; surveillance audits clean.

Level 5, Optimising (continuous improvement)

• Strategy fed by real-time telemetry (DR drills, incident actuals, supplier SLA reports, dependency health).
• Predictive analytics on solution fitness; quantitative RTO confidence intervals.
• Cross-framework integrated (22301 + 27001 + SOC 2 + DORA + APRA + MAS + RBI/SEBI/IRDAI).
• Continuous improvement loop with Clause 8.6 and 10.1 tightly coupled; strategy revised within 30 days of any trigger.
• Indicative investment: ₹4 crore+ cumulative. Tooling: ₹1–10 crore/yr.
• Audit posture: Exemplar; the auditor cites your practice to other clients.

Advancing levels, the typical moves

• L1→L2: Document the options matrix; train the working group; introduce cost-benefit; formalise the annual review; send supplier BCP questionnaires.
• L2→L3: Adopt ISO/TS 22331:2018 explicitly; complete the four-area resourcing; engineering validation; first failover tests; top-management approval; BCM tooling.
• L3→L4: Integrate with CMDB; quantitative loss modelling; active-active for Tier-1; dual-source critical suppliers; board dashboard; full traceability.
• L4→L5: Real-time telemetry; predictive analytics; continuous-improvement loop; cross-jurisdictional integrated compliance; strategy revision within 30 days of trigger.

Emerging Trends

From continuity to operational resilience

The clear global trajectory, visible in DORA, APRA CPS 230, HKMA OR-2, and the UK FCA/PRA/CB operational-resilience policy, is from "continuity of operations" (recover the activity after disruption) to "operational resilience" (remain within tolerance through severe disruption). The practical difference: continuity asks "how fast can we recover?"; resilience asks "can we stay within tolerance even if we never fully recover?" This shifts strategy selection toward prevention, degradation, and impact tolerance rather than just recovery. ISO 22301:2019 Clause 8.3 is compatible with this shift, the before/during/after framing and the MBCO dimension already encode it, but firms should expect regulators to push harder on the "stay within tolerance" framing over time.

Ransomware-resilient backup architecture

The AIIMS Delhi 2022, Cognizant Maze 2020 (SEC-filed $50–70M impact), and Sun Pharmaceutical 2023 cases have made immutable/air-gapped backups a baseline expectation, not an advanced control. The strategy now must assume the production environment (including traditional backups sharing its control plane) will be encrypted, and design recovery from copies the attacker cannot reach. Object-lock storage, independent credentials, separate cloud accounts, and offline copies are the new standard. NIST SP 800-160 Vol 2 Rev 1's cyber-resilience techniques (non-persistence, diversity, segmentation) inform this design.

Cloud-native DR and multi-region as default

For SaaS and cloud-native firms, multi-region cloud DR is becoming the default rather than the exception, driven by DORA, the Jio 17 September 2024 DC fire, and the increasing maturity of cloud-region failover tooling. The strategy question is shifting from "do we have a DR?" to "have we tested cross-region failover, and is our RPO actually what we claim?"

Supplier concentration and exit strategies

RBI MD Outsourcing of IT Services (10 April 2023), DORA Art 29/30, and APRA CPS 230 para 56 all converge on the same requirement: critical supplier concentration must be monitored, and exit/termination continuity plans must exist. The Go First collapse is the visceral illustration. Expect regulators to push for multi-sourcing of critical ICT providers and for tested exit plans, not just documented ones.

People resilience as a first-class strategy

The COVID-19 pandemic and the Akasa Air pilot-exodus crisis (2023, ~₹3 crore/day losses at peak) have elevated people continuity from an HR footnote to a core strategy dimension. Cross-training, succession, remote-work capability, and surge staffing are now strategy decisions, not policy details. ISO/TS 22330 (people aspects) is the method.

Climate change and physical-risk strategy

ISO 22301:2019 Amendment 1:2024 added climate-change adaptation to Clauses 4.1/4.2 (context). The downstream effect on Clause 8.3: climate-driven physical risks (flooding, heat, cyclones, sea-level rise) must inform premises and supplier strategy, site selection, geographic diversity, and supply-chain routing. For Indian firms in coastal cities (Mumbai, Chennai, Kolkata, Visakhapatnam), this is not theoretical; the Chennai 2015 and Kerala 2018 floods are the recent precedent.

AI and predictive continuity

Emerging practice uses AI/ML on operational telemetry (DR drill results, incident logs, supplier SLA data, dependency health) to predict strategy fitness and flag drift before a real disruption. This is an L5 capability; most growing companies should focus on L3–L4 fundamentals first, but the trajectory is clear.

References and Further Reading

Standards and guidance (verify current editions on iso.org)

• ISO 22301:2019 + Amendment 1:2024, Security and resilience, BCMS, Requirements.
• ISO 22313:2020, Guidance on the use of ISO 22301.
• ISO/TS 22331:2018, Guidelines for business continuity strategy (the how-to for Clause 8.3).
• ISO/TS 22318:2021, Guidelines for supply chain continuity (suppliers resource area; 2015 edition withdrawn).
• ISO/TS 22330, Guidelines for people aspects of business continuity (people resource area).
• ISO 22300:2021, Vocabulary (a 2025 edition is under development (ISO/DIS 22300, 4th ed.) and not yet published; verify).
• ISO 27001:2022, A.5.29, A.5.30, A.8.13, A.8.14.

Indian regulatory instruments (verify on the issuing body's portal)

• RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (7 Nov 2023, eff 1 Apr 2024), rbi.org.in, portal id 12562.
• RBI Master Direction on Outsourcing of IT Services (10 Apr 2023), rbi.org.in.
• RBI Cyber Security Framework in Banks (2 Jun 2016), rbi.org.in.
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF), SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 (20 Aug 2024), sebi.gov.in.
• SEBI BCP/DR for MIIs, SEBI/HO/MRD1/DTCS/CIR/P/2021/33 (22 Mar 2021; mods 12 Sep 2024), sebi.gov.in.
• IRDAI Information and Cyber Security Guidelines, 2023 (24 Apr 2023), irdai.gov.in.
• CERT-In Directions No. 20(3)/2022-CERT-In (28 Apr 2022), cert-in.org.in.
• DPDP Act 2023 (Act 22 of 2023) + DPDP Rules 2025, meity.gov.in.
• Disaster Management Act, 2005 + NDMA Guidelines (Chemical Disasters, 2007), ndma.gov.in.
• Companies Act 2013 §134(3)(n), §177; SEBI LODR Regulation 21, mca.gov.in / sebi.gov.in.
• IT Act 2000 §43/65/66/70/70B, indiacode.nic.in.

Global frameworks (verify on the issuing body's official domain)

• NIST SP 800-34 Rev 1 (May 2010), csrc.nist.gov.
• NIST SP 800-160 Vol 2 Rev 1 (Sep 2021), csrc.nist.gov.
• NIST CSF 2.0 (26 Feb 2024, NIST.CSWP.29), nist.gov.
• FFIEC IT Handbook, BCM Booklet (Nov 2019), ffiec.gov.
• FEMA FCD-1 / FCD-2 (2017), fema.gov.
• DORA, Regulation (EU) 2022/2554 (applies 17 Jan 2025), eur-lex.europa.eu.
• APRA CPS 230 (eff 1 Jul 2025), apra.gov.au.
• MAS TRM Guidelines (18 Jan 2021), mas.gov.sg.
• HKMA SPM TM-G-2 / OR-2 (31 May 2022), hkma.gov.hk.

Practitioner bodies and data reports

• BCI practitioner guidance (31 Oct 2023), thebci.org.
• BCI Horizon Scan 2025, thebci.org.
• DRI professional-practice framework, drii.org.

Incident anchors (primary-sourced, used in scenarios)

• Go First insolvency (NCLT filing, 2 May 2023; ₹597 cr refund liability per airline disclosure 31 Jul 2023), thehindu.com; reuters.com; livemint.com.
• Akasa Air zero-cancellation response to CrowdStrike 19 Jul 2024 (contrast IndiGo 283 cancellations), Emerald EEMCS case; thehindu.com.
• AIIMS Delhi ransomware (23 Nov 2022), Indian Journal of Information Management case; thehindu.com.
• Cognizant Maze ransomware (Apr 2020, SEC-filed $50–70M Q2 impact), sec.gov (CTS Holdings 10-K).
• Chennai floods (Dec 2015, Cognizant official statement), news.cognizant.com; nidm.gov.in.
• HDFC Bank RBI action (2 Dec 2020), finextra.com; livemint.com.
• Jio outage (17 Sep 2024, Cloudflare Radar AS55836 down ~53%), datacenterdynamics.com; economictimes.indiatimes.com.
• UPI outage (12 Apr 2025, ~5 hrs), timesofindia.indiatimes.com; orfonline.org.

© Singahi. This guide is provided for the receiving organisation's internal use. The paraphrased requirement, the worked examples, and the templates are Singahi's own drafting. ISO 22301:2019's clause text is not reproduced. All framework references are to public instruments named; verify current versions on the issuing body's official portal before relying on them. Incident accounts are paraphrased from public reporting and used for teaching; some figures are flagged [UNVERIFIED] where primary confirmation was not available.