ISO 22301 Clause 8.5: Exercise Programme

Quick Reference (60 Seconds)

The single sentence to remember: a plan that has never been exercised is a hypothesis, not a capability. Clause 8.5 is the clause that converts documented intent into demonstrated competence, and it is the clause Indian regulators most frequently use to separate paper-BCP organisations from genuinely resilient ones.

What the Standard Actually Requires

Figure · Process

What Clause 8.5 asks you to do

ISO 22301 Clause 8.5 asks organizations to exercise and test continuity strategies and plans regularly through scenarios that validate them and build capability. In practical terms, the clause requires an organisation to move beyond authoring business continuity plans and to prove, on a planned and recurring basis, that those plans can actually be invoked, that the chosen continuity strategies deliver the recovery objectives (RTO, RPO, MBCO) defined in the BIA, and that the people who must execute the plans know their roles under stress.

What the clause requires in substance

The requirement set, read alongside ISO 22313:2020 (the companion guidance) and ISO 22300:2021 (vocabulary), breaks into six interlocking obligations:

1. A programme, not a one-off event. The clause contemplates a planned programme of exercises conducted over time, typically a rolling multi-year schedule that escalates in scope, realism, and risk. A single annual fire drill does not satisfy this; a calendar of tabletops, drills, simulations, and periodic live failovers does.
2. Coverage of strategies and plans. Exercises must validate both the strategies selected in Clause 8.3 (does the alternate site actually receive traffic? does the manual workaround actually sustain MBCO?) and the plans and procedures documented in Clause 8.4 (can the crisis team be convened? does the communications tree reach customers and regulators within the required windows?).
3. Scenario-driven design. Exercises are built around disruption scenarios, drawn from the BIA (Clause 8.2) and the risk assessment, that are severe but plausible. The phrase "severe but plausible" recurs across DORA, APRA CPS 230, the FFIEC BCM Booklet, and HKMA OR-2, and it is the design discipline that separates a genuine test from a rehearsal of the easy path.
4. Defined objectives and success criteria. Each exercise has stated objectives (what capability is being validated), scope (what is in and out), and measurable success criteria (RTO achieved? comms within target? decision quality acceptable?). Without these, an "exercise" degenerates into a discussion.
5. Evaluation and after-action. Every exercise produces an evaluation, what worked, what did not, what assumptions proved false, captured in an after-action report (AAR) and feeding corrective actions under Clause 10.1.
6. Capability building. The exercise programme is also the primary engine for building the human capability that Clauses 7.2 (competence) and 7.3 (awareness) require. People learn their roles by performing them in a safe environment; this is why exercise participation, not just attendance, matters.

What the clause does NOT require

This demarcation matters because over-scoping an exercise programme wastes money and frightens leadership:

• It does not require every system to fail over live on every cycle. The frequency and depth should be risk-based: a tier-1 payment system warrants annual live failover; a tier-3 reporting warehouse may warrant only a restore test.
• It does not require real customers to be impacted. Parallel runs, technical failovers during maintenance windows, and simulations with synthetic data all satisfy the clause when designed to validate the same capability.
• It does not require a specific exercise methodology (HSE, Homeland Security Exercise and Evaluation Program, or any named framework). ISO 22313:2020 gives the structural guidance; the organisation chooses the method.
• It does not require exercises to succeed. A well-designed exercise that surfaces a broken failover is a successful exercise; the failure is the finding. The nonconformity arises only if the finding is not corrected (Clause 10.1).

What auditors actually check

A certification auditor (BSI Group, DNV, SGS, TÜV, Bureau Veritas, Intertek, TQCS, or any accredited body operating under ISO/IEC 17021-1) will look for:

• A documented exercise programme with a multi-year horizon, approved at the level the BCMS scope requires (board for regulated entities, executive sponsor otherwise).
• An exercise schedule/calendar showing planned exercises by type, scope, and date for the current and next cycle.
• Exercise plans for the most recent exercises: objectives, scenario, scope, participants, injects, success criteria.
• After-action reports with findings rated, root causes assigned, and corrective actions linked to a tracker with owners and due dates.
• Evidence of closure, corrective actions actually completed and verified, not just opened.
• Coverage evidence, a matrix showing that every BIA-prioritised activity and every Clause 8.4 plan has been exercised within a defensible cycle (commonly 12 months for tier-1, 24 months for tier-2).
• Progression evidence, the programme escalating over time (tabletop → simulation → failover), not stuck at the same depth year after year.
• People evidence, rotation of participants so that capability is not concentrated in one or two individuals; new-joiner induction into the exercise cycle.

The auditor will also test whether the organisation can explain its exercise philosophy, why this scenario, why this frequency, why this depth. An organisation that cannot articulate its risk-based rationale is typically assessed as immature regardless of how many drills it has run.

Why This Control Matters

The business risk of the unexercised plan

The most expensive sentence in business continuity is "We had a plan, but it didn't work when we needed it." Every major continuity failure of the last decade traces back to a plan that existed on paper but had never been validated under realistic conditions:

• Tokyo Stock Exchange, 1 October 2020, the Arrowhead trading system failed over to a backup device that did not work because of a settings drift that no exercise had caught. The result was a full-day trading halt on the world's third-largest exchange and executive resignations. The failover was assumed, never validated.
• British Airways, 27 May 2017, a contractor's power work caused an "uncontrolled return of power" that took down both the primary and the supposedly redundant systems together, because they shared a failure domain that no exercise had exposed. Roughly 75,000 passengers were stranded and around 400–700 flights were cancelled.
• Maersk, NotPetya, 27 June 2017, the network was rebuilt in ten days from a single surviving domain controller in Ghana that survived only because of a power cut, not because of any tested isolation design. The disclosed cost was around USD 200–300 million.

These are not IT operations failures; they are exercise-programme failures. In each case the strategy and the plan existed. What did not exist was a rehearsed, validated capability to execute them.

The Indian regulatory context

In India, Clause 8.5 is not merely a certification expectation, it is a direct regulatory obligation for entire sectors, and the regulators enforce it with actions, not advisories:

• RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (issued 7 November 2023, effective 1 April 2024) consolidates the requirement for periodic BCP drills including live and parallel DR drills for banks, NBFCs (asset base ≥ ₹500 crore), and All-India Financial Institutions. The earlier 2016 Cyber Security Framework had already mandated a Cyber Crisis Management Plan and periodic drills with incident reporting to RBI within 2–6 hours.
• SEBI BCP/DR for Market Infrastructure Institutions (CIR/2021/33, 22 March 2021) requires MIIs (stock exchanges, clearing corporations, depositories) to conduct live failover drills against a Near Site + Disaster Recovery Site architecture, with RTO of ≤ 2 hours for critical systems and defined RPO. The 2024 modifications tightened drill frequencies and UAT/DR expectations. The 2024 CSCRF (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024) extended recovery-testing expectations across all SEBI Regulated Entities under the "Recover" operational function.
• IRDAI Information and Cyber Security Guidelines, 2023 (24 April 2023) require insurers to conduct DR drills and demonstrate board-level oversight of BCP/DR through the Risk/IT committee, with annual compliance reporting within 90 days of financial year-end.
• CERT-In Directions (No. 20(3)/2022-CERT-In, 28 April 2022) impose the 6-hour cyber-incident reporting clock that only a rehearsed incident-response capability can meet. An organisation that has never run a tabletop against the 6-hour clock will almost certainly miss it under real pressure.
• DPDP Act 2023 (Act 22/2023) Section 8(5) imposes an availability duty on personal data, and Section 8(6) plus the Schedule impose breach notification to the Data Protection Board and affected individuals, with penalties up to ₹250 crore for inadequate safeguards and up to ₹200 crore for failure to notify. Breach notification under DPDP is, in practice, an exercise-rehearsed capability.
• Disaster Management Act 2005 and NDMA guidelines (notably the Chemical Disasters guidelines, 2007) require on-site and off-site emergency plans and their periodic rehearsal for Major Accident Hazard units, with penalties under Sections 51–60 for non-compliance with disaster authority directions during a disaster.

The cost of non-compliance

The cost of a missing or deficient exercise programme is layered:

• Direct regulatory cost. HDFC Bank was barred by RBI on 2 December 2020 from new digital products and fresh credit cards after repeated digital outages (November 2018, December 2019, 21–22 November 2020), the ban was partially lifted only around August 2021 and fully lifted around March 2022. The regulator treated repeated outages as a board-level governance failure, not an IT-ops issue. SpiceJet was ordered by DGCA on 27 July 2022 to operate at 50% of approved flights for 8 weeks (extended to 29 October 2022) after multiple in-flight snags, a chronic asset-integrity failure that is itself a continuity failure regulators escalate.
• Direct incident cost. Cognizant disclosed in SEC filings a USD 50–70 million Q2 2020 impact from the Maze ransomware. AIIMS Delhi's November 2022 ransomware took the e-Hospital system down for roughly 6–15 days, with a media-reported ransom of around ₹200 crore (unconfirmed by AIIMS/Delhi Police). LG Polymers' Vizag styrene gas leak (7 May 2020) drew an NGT interim penalty of ₹50 crore and a ₹730 crore relief package from LG Chem, with the plant permanently closed.
• Opportunity cost. Go First's May 2023 insolvency, blamed on Pratt & Whitney PW1100G engine failures grounding around half the fleet, left a refund liability of ₹597 crore owed to around 15.5 lakh passengers, with the airline moving toward liquidation. A continuity strategy for single-source supplier concentration that had been exercised (alternate engine lessors, wet-lease arrangements, capacity-sharing) might have surfaced the fragility before it became terminal.
• Reputational cost. Jio's 17 September 2024 nationwide outage (a data-centre fire; Cloudflare Radar measured traffic down up to 53%) was compounded by a crisis-communications gap between the "minor" framing and the measured 53% drop. Rehearsed crisis communications close that gap.

Why it matters for growing companies

For growing companies, the mid-market (250–2,000 employees) and the smaller firms climbing toward it, the exercise programme is often the last BCM discipline to receive investment, which is precisely why it is the highest-use one. A growing company typically has a BIA, a strategy, and a plan authored for certification or for a customer questionnaire, but no validated capability to invoke them. The first real disruption then exposes the gap, and the gap is rarely just technical: it is that no one has ever practiced the cutover, the call tree, or the manual fallback under time pressure. A modest, well-designed exercise programme, even at L2 maturity, converts a paper plan into a working capability at a fraction of the cost of a single avoided incident.

Scope and Applicability

Who must comply

Clause 8.5 applies to every organisation that has adopted ISO 22301:2019 as the basis for its BCMS, there is no size or sector exemption. In practice, the organisations that feel it most acutely are:

• Regulated entities for whom exercising is also a statutory duty: banks, NBFCs, payment system operators, MIIs, insurers, and healthcare providers under their sectoral regulators.
• Critical-infrastructure operators under the IT Act 2000 (Section 70/70A, NCIIPC for protected systems) and the DM Act 2005 framework.
• Vendors and processors whose customers' BCPs depend on them: IT-ITeS and SaaS firms serving BFSI or healthcare, cloud and managed-service providers, and BPO/KPO operators whose SLAs carry continuity obligations.
• Manufacturing and process industries with Major Accident Hazard exposure, where NDMA/chemical-disaster guidelines mandate emergency-plan rehearsal.
• Growing companies pursuing ISO 22301 for market access (EU financial-services customers increasingly require it as a DORA-aligned assurance), for tender eligibility, or for board-mandated resilience.

Scope by organisation size

Scope by industry (summary; deep treatment in Section 21)

• BFSI, the most prescriptive: RBI MD drill cadence, SEBI MII live failover, IRDAI DR drills. RTO targets are short (≤ 2 hours for SEBI MII critical systems; ≤ 4 hours cited in MAS TRM-style guidance for critical systems).
• Healthcare, clinical continuity and patient safety dominate; exercises must include manual-mode fallback for EHR/LIS outages (the AIIMS 2022 lesson).
• IT-ITeS and SaaS, customer-contractual RTO/RPO drive exercises; multi-tenant failover, tenant-isolation during failover, and ecosystem participation in customer drills.
• Manufacturing, OT/IT joint exercises, supplier-failover drills, chemical-emergency rehearsal under NDMA.
• Government and public sector, NDMA DMP template-driven exercises; integration with District DMPs; PPD-40/FEMA FCD-style COOP for equivalent Indian agencies.

Key Definitions and Terminology

Clause 8.5 has its own vocabulary. The terms below are drawn from ISO 22300:2021 (vocabulary) and ISO 22313:2020 (guidance), paraphrased; the BCI/DRI practitioner usage is noted where it diverges.

Exercise and test, the distinction

• Exercise. A planned, scenario-driven activity in which people and plans are rehearsed to validate capability, build competence, and surface gaps. Exercises emphasise decision-making and coordination and may be discussion-based or operations-based. An exercise is the umbrella term for the activities the clause requires.
• Test. A pass/fail evaluation of a specific component or system against defined criteria, typically technical (does the failover complete within the RTO? does the backup restore to a usable state?). A test is narrower than an exercise; an exercise often contains several tests.

The two are complementary: ISO 22301 Clause 8.5 requires both exercising (people, plans, decisions) and testing (systems, components, timings). Indian regulatory language often uses "drill" to mean either; treat "drill" as context-dependent.

The exercise continuum (taxonomy)

The exercise programme should progress through a continuum of increasing realism, scope, and risk. The taxonomy below is the working set used across ISO 22313, NIST SP 800-34 Rev 1 (Step 6), the FFIEC BCM Booklet, and the BCI/DRI professional practices, reconciled into one ladder:

The continuum is also a risk-management ladder: each level introduces more realism (and more risk of disruption to live operations), so each level requires more preparation, rollback planning, and, at levels 5 and 6, explicit change-control and executive sign-off.

Scenario, inject, MSEL

• Scenario. The disruption narrative the exercise is built around. A good scenario names the hazard, the affected prioritised activity, the time-pressure, and the degradation, and is severe but plausible.
• Inject. A piece of information delivered during the exercise to advance the scenario (a simulated alert, a regulator call, a media query, a supplier outage notice). Injects are pre-scripted and timed.
• Master Scenario Events List (MSEL). The exercise director's chronological list of injects, expected actions, and evaluation points. The MSEL is the conductor's score of the exercise.

After-action report (AAR)

The structured post-exercise evaluation document. It records: objectives and whether they were met; observations (what happened); findings (what that means); recommendations (what to change); and corrective actions (who will do what, by when). The AAR is the bridge from Clause 8.5 to Clause 10.1 (corrective action) and is the artefact auditors most often request.

Severe but plausible

The design constraint that defines an acceptable scenario. "Severe" means it stresses the organisation beyond comfort (it tests the margins, not the easy path). "Plausible" means it is credible given the organisation's threat landscape (a Mumbai fintech planning for a cyclone-driven grid failure is plausible; the same firm planning for a meteor strike is not). DORA, APRA CPS 230 (para 43), the FFIEC BCM Booklet, and HKMA OR-2 all use this phrase or its equivalent.

Failover and failback

• Failover. The act of switching from the primary site/system to the alternate. Tested at level 5 of the continuum.
• Failback. The act of returning to the primary after restoration. Frequently untested, and a common cause of a second, post-recovery outage. A defensible exercise programme tests both directions.

Hot, warm, cold, and why it matters for exercises

The recovery-site tier determines what an exercise can validate. A hot site with active replication can be tested with a real cutover (level 5). A warm site with staged data requires a longer exercise window to reach MBCO. A cold site (empty space, shipped hardware) typically cannot be exercised to full failover within a practical window, which is itself a finding: if your strategy depends on a cold site you have never stood up, the exercise programme has not yet validated the strategy, and Clause 8.5 is arguably not met for that activity.

Relationship to Other Controls

Clause 8.5 is the validation engine of the BCMS. It consumes the outputs of the planning and strategy clauses and produces the evidence that feeds the evaluation and improvement clauses.

Upstream dependencies (what 8.5 consumes)

• Clause 8.2 (BIA and risk assessment), the BIA's prioritised activities, RTO/RPO/MBCO/MTPD values, and dependency maps are the source of exercise scenarios and success criteria. An exercise without a BIA linkage is theatre: there is no way to know whether the RTO was met because no RTO was defined.
• Clause 8.3 (strategies and solutions), the selected continuity strategies (active/active, active/passive, manual workaround, reciprocal, insurance) are what gets tested. An exercise that does not stress the chosen strategy validates nothing about the strategy.
• Clause 8.4 (plans and procedures), the response structure, incident response plans, communications procedures, and plans for each prioritised activity are what gets rehearsed.
• Clause 7.2 (competence) and 7.3 (awareness), the exercise programme is the primary mechanism by which competence is demonstrated and awareness is sustained. A team that has never rehearsed its plan is, by definition, not competent in it, regardless of training records.
• Clause 6.2 (objectives), measurable BC objectives set the targets the exercise validates.

Downstream consumers (what 8.5 feeds)

• Clause 8.6 (evaluation of documentation and capabilities), exercise findings are a principal input to the periodic evaluation of whether the documentation and capabilities remain suitable, adequate, and effective. The exercise programme is essentially 8.6 operating in real time.
• Clause 9.1 (monitoring, measurement, analysis and evaluation), exercise results (RTO achieved vs target, findings counts, closure rates) are core BCMS performance metrics.
• Clause 9.2 (internal audit), the internal audit samples the exercise programme for design adequacy and closure effectiveness.
• Clause 9.3 (management review), top management reviews exercise outcomes; this is where recurrent findings escalate to leadership attention (the HDFC pattern: repeated outages reaching the board because the corrective-action loop did not close).
• Clause 10.1 (nonconformity and corrective action), every exercise finding that represents a gap becomes a corrective action. The discipline of the programme is measured by closure rates, not by the number of drills run.
• Clause 10.2 (continual improvement), the programme itself improves over time (deeper scenarios, broader scope, higher realism), which is continual improvement in action.

Cross-framework relationships (summary; full mapping in Section 16)

Within the ISO 27001 family, Clause 8.5 maps most directly to A.5.30 (ICT readiness for business continuity), A.8.13 (information backup, including verification of restoration), and A.8.14 (redundancy of information processing facilities). NIST SP 800-34 Rev 1 Step 6 (plan testing, training, and exercises) is the US-federal analogue. DORA Art 25 (testing) and Art 26 (TLPT every 3 years) are the EU financial-sector analogue. APRA CPS 230 para 43 (annual BC exercise with severe-but-plausible scenarios) is the Australian prudential analogue. The FFIEC BCM Booklet's "testing" principle is the US banking analogue. Section 16 develops these mappings with the real article and paragraph numbers.

Detailed Implementation Guidance

This is the operational core of the clause. It is written to be usable by a BCM manager building a programme from scratch, and to be deep enough that a seasoned practitioner can lift the structure directly. It is organised into seven steps that mirror the exercise lifecycle: design the programme, design the scenario, prepare, conduct, evaluate, improve, and govern.

Step 1, Design the exercise programme (the multi-year plan)

A programme is not a calendar of disconnected drills; it is a risk-based, escalating, multi-year plan that deliberately builds capability over time. The design outputs are:

7.1.1 Exercise philosophy statement. A one-page document, approved by the BCMS sponsor, that states: the organisation's risk appetite for live testing; the depth the programme will reach (e.g., "annual live failover for tier-1 systems, bi-annual simulation for tier-2, annual tabletop for tier-3"); the regulatory drivers (RBI/SEBI/IRDAI/CERT-In as applicable); and the escalation path over the next three years (e.g., "Year 1: reach L2; Year 2: first live failover; Year 3: ecosystem drill with top three customers"). This statement is the document the auditor reads first to judge whether the programme is designed or merely accumulated.

7.1.2 Coverage matrix. A grid with BIA-prioritised activities on one axis and plan components on the other, showing for each cell when it was last exercised, by what type, and when it is next due. The coverage matrix forces honesty: it instantly reveals the activities that have a plan but have never been exercised (the highest-risk cells). A defensible target is that every tier-1 activity is exercised within 12 months and every tier-2 activity within 24 months.

7.1.3 Annual exercise calendar. A forward-looking 12-month schedule with planned exercises by type, scope, owner, and quarter. The calendar should be sequenced so that lower-risk exercises (tabletops, component tests) precede higher-risk ones (simulations, failovers), building capability before testing it. Reserve a contingency slot for an unplanned "real" event that becomes a learning opportunity.

7.1.4 Budget and resourcing. People time is the largest cost (typically 60–70% of the programme), followed by external facilitation (15–20%), tooling (10–15%), and venue/logistics (5–10%). For a mid-market (250–2,000) firm, a realistic annual budget is ₹15–45 lakh; for a large enterprise, ₹1–5 crore. The budget should explicitly fund corrective actions, an exercise programme that surfaces findings it cannot afford to fix has defeated its own purpose.

7.1.5 Risk-based prioritisation. Not everything needs to fail over live. Prioritise by: (a) BIA tier (RTO urgency); (b) regulatory mandate (RBI/SEBI drills are non-negotiable); (c) change-velocity (systems with recent major changes need re-testing); (d) finding-recurrence (areas with open findings need re-exercise after closure); (e) single-points-of-failure (SPOFs identified in the BIA need the deepest testing).

Step 2, Design the scenario

A good scenario is the difference between an exercise that surfaces real gaps and one that rehearses the easy path. The design method:

7.2.1 Anchor the scenario in the BIA and risk assessment. The scenario must target a specific prioritised activity and stress a specific continuity strategy. Generic "there is a flood" scenarios produce generic findings. "The Chennai delivery centre is uninhabitable for 72 hours during monsoon, the primary DC loses power, and the manual workaround for claims processing must sustain MBCO of 50% throughput" is a scenario that will surface real gaps.

7.2.2 Apply the severe-but-plausible test. Severe: does it push the organisation beyond its comfort zone (multi-failure, peak hour, key-person unavailable, regulator on the line)? Plausible: is it credible given the threat landscape (geography, sector, threat intel, BCI Horizon Scan data)? The BCI Horizon Scan 2025 ranks safety incidents (risk index 14.64) and cyber attacks (the top organisational risk for 2026, with around half of respondents having thwarted a cyber attack in the prior year) as the dominant disruptors, these are the credible scenario seeds.

7.2.3 Build the scenario narrative. A scenario has: a trigger (the initiating event), a timeline (how it unfolds), complications (what else goes wrong, the second and third failures), injects (information delivered during the exercise), and decision points (where the team must choose). A scenario that has only a trigger and no complications is too easy; real disruptions cascade.

7.2.4 Multi-hazard scenario library. Maintain a curated library of scenarios covering: cyber (ransomware, wiper, supply-chain compromise, account takeover), natural hazard (flood, cyclone, earthquake, heatwave, increasingly climate-driven per ISO 22301 Amendment 1:2024), infrastructure (grid failure, telecom outage, DC fire), people (key-person loss, mass resignation, pandemic-absenteeism, workplace violence, the Maruti Suzuki Manesar 2012 pattern), supplier (critical vendor failure, concentration risk), and regulatory (a 6-hour CERT-In clock triggered by a reportable incident). The library is a living asset, refreshed from real incidents and threat intel.

7.2.5 Define objectives and success criteria. Each exercise states 3–7 objectives, each with measurable success criteria. "Test the DR failover" is not an objective; "Validate that the core banking system fails over to the DRS within the 2-hour RTO, with zero data loss beyond the 5-minute RPO, and that customer comms issue within 30 minutes" is. Without measurable criteria, the after-action review collapses into opinion.

Step 3, Prepare

Preparation determines whether the exercise produces useful findings or just frustration.

7.3.1 Exercise plan document. For each exercise, a plan covering: objectives and success criteria; scenario summary; scope (in/out); participants (players, facilitator, scribe, observers, evaluators, simulators); schedule and timeline; inject list (the MSEL); logistics (venue, platform, materials); safety and abort criteria (for operations-based exercises); rollback plan (for live failovers); communications to non-participants (so the exercise is not mistaken for a real event); and evaluation method.

7.3.2 Participant preparation. Players receive a pre-read (plan summary, their role, the scenario context, not the injects or the resolution). Brief them on the exercise rules: this is a safe environment; decisions are evaluated, not individuals; "I don't know" is an acceptable and informative answer. For tabletops, ensure the right people are in the room, the actual decision-makers, not deputies who will defer.

7.3.3 Technical preparation (for failovers). For a live failover: confirm replication health, take a pre-exercise backup, document the current state (so you can prove return-to-normal), stage the rollback, notify dependent teams and customers (as appropriate), and schedule within a maintenance window with a buffer. Have a named "abort owner" with the authority to halt and roll back.

7.3.4 Safety and abort criteria. Any operations-based exercise must have explicit abort triggers: unexpected data loss, impact to live customers beyond the agreed tolerance, a real incident occurring during the exercise, or safety risk to participants. The abort procedure must be documented and rehearsed by the exercise director before the exercise begins.

Step 4, Conduct

7.4.1 Facilitation discipline. The facilitator's job is to deliver the scenario, manage pace, ensure all participants engage, and resist the temptation to "help" the team succeed. A facilitator who steers the team to the right answer is running a training session, not an exercise. For tabletops, pace is managed by inject timing; for simulations, by a real or accelerated clock.

7.4.2 Observation and logging. Every exercise has a scribe (or multiple scribes for larger exercises) capturing: decisions made, time taken, information requested (and whether it was available), assumptions stated, and breakdowns in process. The log is the raw material for the AAR. Audio recording (with consent) is valuable for tabletops.

7.4.3 Inject management. Injects are delivered per the MSEL. The facilitator may add or withhold injects based on the team's pace, if the team is foundering on an early inject, withholding a later complication is legitimate (the exercise has already surfaced its findings). Inject realism matters: a simulated regulator call from a person playing the regulator (with a prepared query) is more realistic than a printed card.

7.4.4 Hot wash. Immediately after the exercise, conduct a "hot wash", a structured debrief with all participants while memory is fresh. Ask three questions: what went well, what did not, what will we change. The hot wash captures the emotional and intuitive findings that evaporate within 48 hours and that a delayed written AAR will miss.

Step 5, Evaluate

7.5.1 After-action report. Within 10–15 working days, the facilitator/BCM manager produces the AAR covering: exercise overview (date, scope, participants, scenario); objectives and success criteria with met/not-met status; chronological narrative; observations (factual); findings (analytical, what the observation means); recommendations; and corrective actions with owners and due dates. The AAR should distinguish plan findings (the plan is wrong), capability findings (the plan is right but people cannot execute it), strategy findings (the chosen continuity solution cannot meet the objective), and dependency findings (a supplier or upstream system failed).

7.5.2 Rating findings. Use a consistent severity scale: Critical (strategy/plan will fail in a real disruption, e.g., failover does not complete within RTO), Major (significant degradation, e.g., comms issued but late), Minor (inefficiency, e.g., redundant steps), and Observation (good practice or learning). The rating drives corrective-action priority.

7.5.3 Validation of objectives. Explicitly record whether each success criterion was met. "RTO achieved: 1h 47m against 2h target, met" is the evidence the auditor and the regulator want. "RTO not achieved: 3h 12m against 2h target, not met; root cause: DNS TTL cached for 1 hour" is a finding that becomes a corrective action.

Step 6, Improve (close the loop)

7.6.1 Corrective-action register. Every finding with a recommendation becomes a tracked corrective action in the BCMS corrective-action register (the same register used for Clause 10.1 nonconformities). Each action has: owner, due date, planned action, verification method, and closure status. The register is reviewed at management review (Clause 9.3).

7.6.2 Closure verification. A corrective action is "closed" only when its effectiveness has been verified, typically by re-exercising the relevant component. "We updated the runbook" is not closure; "we updated the runbook and the next drill completed the cutover within RTO" is closure. This is the discipline that separates mature programmes from paper-closure programmes, and it is the precise failure that the DBS/MAS recurrence pattern illustrates (repeated outages because corrective actions were "closed" without effectiveness verification).

7.6.3 Re-exercise. Schedule a re-exercise (often a targeted component test rather than a full re-run) to verify closure. The coverage matrix (7.1.2) should show re-exercise dates for areas with prior findings.

Step 7, Govern

7.7.1 Roles and accountability. The exercise programme needs a named owner (the BCM manager), an executive sponsor (CISO, COO, or for regulated entities a board-mandated CRO), and clear accountability for closure (finding owners are typically activity/process owners, not the BCM manager). The RACI is developed in the toolkit.

7.7.2 Reporting to leadership. A quarterly exercise dashboard to the BCMS sponsor covering: exercises completed vs planned, objectives met vs not met, findings by severity, corrective-action closure rate, and upcoming high-risk exercises. For regulated entities, an annual summary to the board/Risk Committee (RBI MD, SEBI, IRDAI all expect board visibility).

7.7.3 Programme review. Annually, review the programme itself: is it escalating in depth? Is coverage improving? Are closure rates trending up? Are findings recurring (a sign the corrective-action loop is weak)? Adjust the philosophy statement and calendar accordingly. This is Clause 10.2 (continual improvement) applied to the exercise programme.

7.7.4 Independent challenge. Periodically (every 2–3 years), bring in an external facilitator or auditor to challenge the programme's design and self-assessment. Internal exercises develop blind spots; an external eye surfaces them. This is analogous to the internal-audit independence principle (Clause 9.2) applied to the exercise programme.

Tiered implementation by maturity

For growing companies, the path from L1 to L4 is typically:

• First 90 days (L1 → L2): Write the exercise philosophy; build the coverage matrix from the BIA; schedule and run the first tabletop on the top-priority activity; produce a simple AAR; open the first three corrective actions.
• 3–9 months (L2): Quarterly tabletop cadence established; first component tests (restore, call-tree); first cross-functional simulation; corrective-action tracker live; dashboard to sponsor.
• 9–18 months (L2 → L3): First full failover of a tier-1 system in a maintenance window; failback tested; supplier-failover test with the top critical vendor; after-action rigour increased with severity ratings and closure verification.
• 18–36 months (L3 → L4): Annual live failover for all tier-1; bi-annual simulations across business units; ecosystem drill with key customers/regulator; closure-verification re-exercises embedded; programme independently reviewed.

Special considerations

7.9.1 Exercises that must include third parties. Where a prioritised activity depends on a supplier (cloud, SaaS, payment processor, logistics), the exercise programme must include supplier-failover tests. RBI's Master Direction on Outsourcing of IT Services (10 April 2023) and SEBI/IRDAI outsourcing rules all require that outsourced continuity meets the RE's own standards, which is only demonstrable through joint exercises. Build supplier exercise participation into contracts (see toolkit doc 10).

7.9.2 Exercises for the CERT-In 6-hour clock. Run a tabletop specifically against the CERT-In 6-hour reporting scenario: discovery → triage → classification → notification drafting → escalation → reporting. Measure elapsed time at each step. Most organisations that have never run this tabletop will discover their first attempt takes 8–12 hours, which is the finding, and the corrective action.

7.9.3 Climate-driven scenarios (Amendment 1:2024). ISO 22301:2019/Amd 1:2024 added climate-change adaptation to Clauses 4.1/4.2 context. Exercise scenarios should now include climate-amplified hazards (heatwave-driven DC cooling failure, monsoon-intensity flooding, cyclone-driven multi-site disruption) as plausible, not exotic, events. For Indian organisations, these are already the dominant natural-hazard scenarios.

7.9.4 People-resilience scenarios. The Akasa Air pilot-exodus pattern (43 pilots resigning in a month, around 600–800+ flights cancelled, losses around ₹3 crore/day at peak) is a people-continuity scenario as valid as any cyber or natural-hazard scenario. Exercise scenarios should include key-person loss, mass-skill shortage, and workforce-displacement (a Chennai-2015-style flood that makes staff physically unable to reach site).

7.9.5 Failback is part of failover. Always test the return to primary. A failover that succeeds but a failback that breaks leaves the organisation in a degraded steady state, and is the source of many "second outages" after a nominal recovery.

Tools, Technologies, and Solutions

The exercise programme is, above all, a human and process discipline; tooling supports it but does not substitute for it. This section describes the tool categories a growing company should evaluate, with category-level descriptors only, no vendor names, consistent with Singahi's sourcing discipline. Specific product selection should follow the evaluation matrix in toolkit doc 14.

Tool categories

8.1.1 BCM programme management platforms (enterprise IRM suite / GRC SaaS (250–2,000 band) / BCM-specialist SaaS). These platforms host the BIA, strategy, plans, exercise calendar, findings, and corrective-action register in one place, and are the system of record for the BCMS. For the exercise programme specifically, they provide: exercise scheduling, participant management, finding-to-action tracking, coverage-matrix dashboards, and audit-evidence export. The enterprise IRM suites (broad risk-management suites with a BCM module) suit large, regulated entities that want one platform for ISO 22301 + ISO 27001 + operational risk. GRC SaaS (250–2,000 band) suits organisations in that band wanting BCM + audit + policy in one tool. BCM-specialist SaaS suits organisations whose primary need is BCM depth (exercise design, scenario libraries, AAR workflows) over broad GRC. Indicative cost: enterprise IRM ₹40 lakh–₹2 crore/year; GRC SaaS (250–2,000 band) ₹8–40 lakh/year; BCM-specialist SaaS ₹6–25 lakh/year.

8.1.2 Exercise simulation and inject-delivery platforms. Specialised platforms for running tabletop and simulation exercises, managing the MSEL, delivering injects to participants, capturing decisions with timestamps, and producing a structured log for the AAR. Useful for distributed teams and for organisations running frequent exercises. Indicative cost: ₹4–15 lakh/year for the 250–2,000 band.

8.1.3 Crisis-notification / mass-notification platforms. Used both in real incidents and in exercises to test the call tree and deliver time-bound messages to staff, stakeholders, and (where integrated) customers. The exercise use case is call-tree validation: the platform reports delivery rates, response times, and acknowledgment, giving objective evidence for the AAR. Indicative cost: ₹3–12 lakh/year for the 250–2,000 band; usage-based pricing common.

8.1.4 DR orchestration and failover-automation tooling. For live failover exercises (level 5), orchestration platforms automate the cutover sequence, enforce runbook order, and provide abort/rollback. They transform a manual, error-prone cutover into a repeatable, testable process, and their "run as exercise" mode (cutover with automated validation, then failback) is how tier-1 systems should be failover-tested. Indicative cost: ₹10–60 lakh/year depending on infrastructure complexity; some infrastructure vendors include baseline orchestration with their platforms.

8.1.5 Backup and restore verification tooling. Backup platforms that support automated restore-testing (spin up a restored copy in an isolated environment, validate it boots and data is present, tear down) convert "we have backups" from a claim into continuously-tested evidence. This directly satisfies ISO 27001 A.8.13 verification and ISO 22301 Clause 8.5 for the data-recovery dimension.

8.1.6 Collaboration and web-conferencing platforms. The backbone of distributed tabletops and simulations. Adequate for most discussion-based exercises; pair with a dedicated simulation platform for complex MSEL management.

8.1.7 ITSM / ticketing platforms. For logging and tracking corrective actions from exercises through to closure. The exercise programme should integrate with the ITSM workflow so findings become tickets with owners, SLAs, and escalation, not items in a spreadsheet that drift.

8.1.8 Threat-intel and scenario-intelligence feeds. Services that provide current threat-actor behaviour, sector incidents, and emerging hazards to refresh the scenario library. The BCI Horizon Scan (annual) is the most-citable open dataset; commercial threat-intel feeds add real-time depth for cyber scenarios.

Selection guidance for growing companies

For a mid-market (250–2,000) Indian firm building a first defensible programme, the pragmatic stack is: a BCM-specialist SaaS or GRC SaaS (250–2,000 band) for programme management (₹8–25 lakh/year), the existing collaboration platform for tabletop delivery, a mass-notification platform for call-tree testing (₹3–8 lakh/year), the existing ITSM for corrective-action tracking, and the backup platform's restore-test feature for data-recovery validation. DR orchestration tooling is typically justified only once annual live failover is established and the manual cutover cost/risk becomes visible. Avoid buying an enterprise IRM suite before the programme is mature enough to use it, an unused GRC platform is a common waste.

Build vs buy for the scenario library

The scenario library is almost always better built than bought, because it must reflect the organisation's specific BIA, geography, sector, and threat landscape. A generic library is a starting point; the curated, organisation-specific library is the asset. Singahi's toolkit provides a starter scenario library (doc 09) that organisations adapt to their context.

Policy and Procedure Templates

This section provides the skeleton of the exercise programme policy and procedure. The full, ready-to-customize templates are in the toolkit (docs 01 and 02); the extracts here illustrate the structure and the sample "shall" clauses, which are our own drafting (only ISO 22301's own clause text is paraphrased).

Exercise Programme Policy (skeleton)

Purpose. This policy establishes the organisation's commitment to validating its business continuity strategies, plans, and capabilities through a planned programme of exercises, in accordance with ISO 22301:2019 Clause 8.5 and applicable regulatory mandates (RBI Master Direction on IT Governance; SEBI CSCRF and BCP/DR for MIIs; IRDAI Information & Cyber Security Guidelines 2023; CERT-In Directions).

Scope. Applies to all BIA-prioritised activities, their associated continuity strategies and plans, all sites within the BCMS scope, and all personnel with assigned BCMS roles.

Policy statements (sample "shall" clauses, our own drafting):

1. The organisation shall maintain a documented, multi-year exercise programme approved by the BCMS sponsor and, for regulated activities, by the board Risk/IT Committee.
2. The exercise programme shall progress through a continuum of exercise types, reaching at least one full failover exercise per tier-1 prioritised activity per year.
3. Every exercise shall have documented objectives, success criteria, scope, and an after-action report.
4. Every exercise finding shall be entered into the corrective-action register with a named owner and due date, and shall be verified closed through re-exercise or equivalent validation.
5. The organisation shall exercise its incident-response and notification procedures against the CERT-In 6-hour reporting clock at least annually.
6. Critical suppliers and outsourced service providers shall participate in joint continuity exercises at a frequency proportionate to the criticality of the service.
7. Exercise participation and performance shall be an input to competence evaluation under Clause 7.2.

Exercise Procedure (skeleton)

The procedure operationalises the policy across the seven lifecycle steps (Section 7): programme design, scenario design, preparation, conduct, evaluation, improvement, governance. It defines: the exercise calendar approval workflow; the exercise plan template; participant briefing requirements; abort criteria and safety; the AAR template and timeline (draft within 10 working days, hot wash within 24 hours); the corrective-action workflow (logged within 5 working days of AAR, owner assigned, due date set, closure verified); and the quarterly reporting pack to the sponsor. The full procedure is in toolkit doc 02.

Sample after-action report structure

1. Exercise overview (date, type, scope, participants, scenario summary)
2. Objectives and success criteria, met/not-met status with evidence
3. Chronological narrative
4. Observations (factual, per phase)
5. Findings (analytical, severity-rated: Critical/Major/Minor/Observation)
6. Recommendations
7. Corrective actions (owner, due date, verification method)
8. Sign-off (facilitator, BCM manager, sponsor for Critical findings)

The complete AAR template is toolkit doc 17.

Risk Assessment and Treatment

Clause 8.5 has its own risk dimension: the exercise itself can disrupt operations. A risk-managed exercise programme treats this explicitly.

Exercise-inherent risks

Risk treatment for the programme itself

The programme-level risks, under-coverage, stagnation, paper closure, concentration of capability, are treated by the governance controls in Section 7.7 (coverage matrix, escalation evidence, closure verification, rotation, independent challenge). The risk that the programme is theatrical (exercises designed to succeed rather than to find gaps) is the deepest risk and is treated by: the severe-but-plausible design discipline, external facilitation, willingness to publish failures internally, and leadership culture that treats a surfacing-of-failure as a success.

Risk register integration

Exercise findings that represent unmitigated risks should flow into the enterprise risk register (Clause 6.1), not just the corrective-action register. A finding that the tier-1 payment system cannot meet its RTO is a risk the board should see, not just a ticket the BCM manager tracks.

Audit and Compliance Checklist

The following 27 questions cover the audit surfaces for Clause 8.5. Each lists the expected evidence and the red flag that indicates a finding.

1. Is there a documented exercise programme? Evidence: a programme document or philosophy statement with multi-year horizon. Red flag: only a calendar of drills with no design rationale.
2. Is the programme approved at the appropriate level? Evidence: sign-off by the BCMS sponsor; board/Risk Committee minutes for regulated entities. Red flag: BCM-manager-only approval.
3. Does the programme reference the BIA? Evidence: coverage matrix linking exercises to prioritised activities and RTO/RPO/MBCO. Red flag: exercises with no BIA linkage.
4. Is there a forward-looking exercise calendar? Evidence: 12-month schedule by type, scope, owner, quarter. Red flag: no forward plan; only retrospective drill records.
5. Does the programme escalate in depth over time? Evidence: progression from tabletop to simulation to failover across years. Red flag: same-depth tabletop every year.
6. Are scenarios severe-but-plausible and drawn from the risk assessment? Evidence: scenario library with risk-assessment traceability. Red flag: generic scenarios unrelated to the org's threat landscape.
7. Does each exercise have documented objectives and success criteria? Evidence: exercise plan with measurable criteria. Red flag: "test the DR plan" with no measurable target.
8. Are after-action reports produced for every exercise? Evidence: AARs on file. Red flag: drills run with no written evaluation.
9. Do AARs rate findings by severity? Evidence: Critical/Major/Minor/Observation classification. Red flag: undifferentiated lists.
10. Are corrective actions logged with owners and due dates? Evidence: corrective-action register entries. Red flag: findings in AARs with no tracking.
11. Are corrective actions actually closed (not just opened)? Evidence: closure status with verification. Red flag: open actions months past due.
12. Is closure verified by re-exercise? Evidence: re-exercise records for prior findings. Red flag: "closed" because the runbook was updated, with no re-test.
13. Are tier-1 activities exercised within 12 months? Evidence: coverage matrix dates. Red flag: tier-1 activity with no exercise in >12 months.
14. Has there been at least one live failover of a tier-1 system? Evidence: failover exercise record with cutover timing. Red flag: DR site never had a live cutover.
15. Is failback tested, not just failover? Evidence: failback record. Red flag: failover tested, return to primary never validated.
16. Are communications procedures exercised? Evidence: call-tree test, regulator-notification drill. Red flag: comms plan never tested.
17. Is the CERT-In 6-hour clock exercised? Evidence: tabletop or simulation with elapsed-time measurement against 6 hours. Red flag: IR plan exists but never timed.
18. Are critical suppliers included in exercises? Evidence: joint exercise records with suppliers/DR providers. Red flag: critical cloud/SaaS supplier never tested.
19. Is there participant rotation? Evidence: participant lists across exercises showing breadth. Red flag: same two people in every exercise.
20. Are new joiners inducted into the exercise cycle? Evidence: induction records. Red flag: capability concentrated in long-tenured staff.
21. Is there a hot wash immediately after each exercise? Evidence: hot wash notes within 24 hours. Red flag: AAR produced weeks later with no hot wash.
22. Are exercise results reported to leadership? Evidence: quarterly dashboard; board/Risk Committee pack. Red flag: results sit with the BCM manager only.
23. Are recurrent findings escalated? Evidence: escalation to management review (Clause 9.3). Red flag: same finding recurs across exercises with no escalation.
24. Is the exercise programme itself periodically reviewed? Evidence: annual programme review record. Red flag: programme unchanged for years.
25. Has the programme had independent challenge? Evidence: external facilitator or internal-audit review of programme design. Red flag: entirely self-assessed.
26. Are exercise abort criteria and safety documented for operations-based exercises? Evidence: exercise plans with abort section. Red flag: live failover with no documented abort/rollback.
27. Do DPDP-breach-notification procedures get exercised? Evidence: tabletop against the DPDP Section 8(6) notification timeline. Red flag: breach-notification plan never timed.

Metrics and KPIs

The exercise programme needs process metrics (is the programme running?), outcome metrics (is it producing capability?), and improvement metrics (is the organisation getting better?). The following 13 KPIs cover all three.

Process metrics

Outcome metrics

Improvement metrics

Dashboard design

The quarterly exercise dashboard should present these on a single page: completion and coverage (process), RTO/RPO attainment and 6-hour-clock (outcome), closure and recurrence (improvement), with a trend line over four quarters. For regulated entities, a regulator-facing subset (drill cadence, RTO/RPO attainment, corrective-action status) supports the annual compliance return (IRDAI within 90 days of FY-end; SEBI/CSCRF reporting; RBI supervisory returns).

The KPI that matters most

If forced to choose one, it is closure-verification rate for Critical findings, the percentage of Critical findings closed by re-exercise rather than by paperwork. This single KPI distinguishes a mature programme (closed and proven) from a paper programme (closed and asserted), and it is the KPI most predictive of real-incident performance.

Common Pitfalls / Audit Failures

The recurring failure modes, named so they are memorable:

13.1 "We have a DR plan, never exercised." The classic. The plan exists for certification or for a customer questionnaire; no one has ever cut over. The first real disruption exposes that the runbook references retired server names, the DNS TTL is wrong, the replication has been silently broken for months, and no one knows who has the DRS credentials. This is the TSE 2020 pattern and the most common Clause 8.5 finding.

13.2 "Tabletop theatre." The organisation runs tabletops that are too easy: the scenario is gentle, the facilitator steers the team to the right answer, the injects are predictable, the AAR concludes "all went well." The programme produces no findings because it is designed not to. Auditors spot this by reading the AARs: a programme with zero findings across multiple exercises is not mature; it is theatrical.

13.3 "Paper closure." Findings are "closed" by updating the runbook or sending an email, with no re-exercise. The corrective-action register shows 100% closure; the next real incident shows the gap persists. This is the DBS/MAS recurrence pattern, repeated outages because the corrective-action loop did not actually close.

13.4 "Failover without failback." The live failover succeeds and is celebrated; the return to primary is never tested. The next real incident fails at failback, leaving the organisation stranded on the DR site with degrading performance. Always test both directions.

13.5 "The same two heroes." Every exercise has the same two capable people. They hold the capability; when one is on leave or has left the organisation during a real disruption, the team cannot execute. Rotation and induction are the corrective controls.

13.6 "RTO set in the meeting room, not the BIA." The exercise "validates" an RTO that was never derived from the BIA, it was picked because it sounded achievable. The exercise "succeeds" against a target that bears no relationship to the organisation's actual tolerance. Link every RTO back to the BIA's MTPD.

13.7 "Single-vendor everything, never tested together." The continuity strategy depends on one cloud provider, one SaaS, one DR site, and none has ever been exercised jointly. The first real disruption surfaces that the supplier's failover and the organisation's failover are not coordinated. Joint exercises with critical suppliers are non-negotiable for RBI MD / SEBI / IRDAI compliance.

13.8 "The exercise that became an incident." A live failover with no abort criteria, no rollback, and no maintenance window causes an unplanned outage. Exercise-inherent risk must be treated (Section 10).

13.9 "Stale scenario library." The same three scenarios (fire, flood, server failure) run for years. New threats, ransomware-as-a-service, supply-chain compromise, climate-amplified hazards, people-resilience, are absent. The library must be refreshed annually from threat intel and real incidents.

13.10 "No regulator drill." For regulated entities, the regulator-witnessed drill is treated as a performance to pass rather than a test to learn from. The organisation pre-rehearses the exact scenario until it is theatrical, and the regulator signs off, but the underlying capability is narrow. Build general capability, not drill-specific performance.

13.11 "Exercises exclude the board." The crisis team is exercised but the board/Risk Committee is not. A real disruption surfaces that the board cannot convene effectively, cannot make capital-allocation decisions under time pressure, and cannot speak coherently to the regulator. Include board-level decision rehearsal at least annually for regulated entities.

13.12 "Findings don't reach the risk register." Exercise findings sit in the BCM corrective-action register and never surface in the enterprise risk register or the management review. A Critical finding that the tier-1 system cannot meet its RTO is a board-level risk; if it is tracked only as a BCM ticket, the system has failed to escalate.

Illustrative Scenario 1: Failure

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

Illustrative scenario. The following is a composite, fictionalised account drawn from publicly documented failure patterns (TSE 2020 untested failover; HDFC repeated-outage regulatory action; Chennai 2015 site-concentration). It is presented for instruction; any resemblance to a specific firm is incidental.

The organisation

"Sahayak Financial Services" (name illustrative) is a mid-sized NBFC (around 1,200 employees) headquartered in Mumbai, with a lending platform serving around 8 lakh customers and an Assets-under-Management of roughly ₹4,000 crore. The firm employs around 1,200 people across Mumbai (corporate office and primary DC) and Pune (a secondary site marketed internally as the "DR site"). Sahayak had invested in ISO 22301 certification in 2024 to meet RBI Master Direction expectations and tender requirements. The BIA identified the lending platform, the customer portal, and the collections system as tier-1 activities with an RTO of 4 hours and an RPO of 15 minutes.

The exercise programme (in theory)

Sahayak had a documented exercise programme. It called for an annual tabletop, a bi-annual component test, and an annual live failover of the tier-1 lending platform. In practice, the annual tabletops had run faithfully since certification. The component tests were limited to backup-restore verifications. The live failover had been deferred each year, first because of a core-system upgrade, then because of a regulator inspection, then because "the business cannot afford the risk right now." The DR site in Pune had never received live traffic. The BCM manager, Priya Sharma, had flagged this in two consecutive quarterly reports; the executive sponsor had acknowledged but not rescheduled.

The disruption

On 14 July, during the monsoon, a combination of grid instability (a Mumbai-power-grid-style event) and a DC power-conditioning failure took the primary DC offline. The UPS held for the expected ride-through window, then the generator failed to start (a fuel-feed issue that no maintenance log had flagged). The lending platform went dark. Priya invoked the DR failover at 14:32 IST.

What went wrong

The failover failed, in sequence, for reasons that a single live exercise would have surfaced:

1. Replication had been silently broken for four months. A storage change in March had misconfigured the async-replication link; the monitoring alert had been generated but routed to a distribution list that no longer existed after a team reorganisation. The Pune DR site was 4 months stale.
2. The runbook referenced retired server names. The lending platform had been re-platformed in February; the DR runbook had not been updated. The ops team spent 90 minutes reconciling the runbook against the live environment.
3. DNS had not been cut in a failover before. The DNS TTL was set to 1 hour for "performance"; the failover plan assumed a 5-minute cutover. Customer traffic continued to route to the dead primary for the full TTL window.
4. The DRS credentials were held by two people. One was on leave; the other was in traffic. The credentials were eventually recovered from a sealed envelope after 70 minutes.
5. The crisis-communications tree had not been tested. The first customer-facing communication went out 3 hours after the outage began, by which time social media and a Downdetector-style surge had already defined the narrative.
6. The regulator notification was late. The CERT-In 6-hour clock was missed by 2 hours; the RBI incident notification was sent at 9 hours. Both were first attempts for the team.

Impact

The lending platform was dark for 62 hours against an RTO of 4. Loan disbursals stalled for 3 days; EMI collections queued; around 18,000 customer transactions were affected. Direct financial loss was estimated at ₹18 crore (lost interest, waived fees, manual-processing overtime). Reputational cost was larger: an estimated ₹40 crore in customer churn over the following two quarters, and a credit-rating outlook revision citing "operational resilience deficiencies." RBI initiated a supervisory review under the Master Direction framework. Sahayak's ISO 22301 certification survived only because of a rapid, evidenced corrective-action programme, but the recertification audit issued a major nonconformity against Clause 8.5 (live failover never performed) and a minor against Clause 8.6 (evaluation had not flagged the deferral).

Root causes and lessons

• The deferral was the failure. Each year's deferral of the live failover was treated as a scheduling decision; it was in fact a decision to operate without validated continuity capability, the precise condition Clause 8.5 exists to prevent.
• Tabletops validated comprehension, not capability. The annual tabletops confirmed that the team understood the plan; they did not validate that the plan would work. Comprehension is necessary but not sufficient.
• Monitoring drift invalidated the strategy. The broken replication was a Clause 9.1 (monitoring) failure that became a Clause 8.5 failure because no exercise caught it.
• Concentration of capability (two credential holders) was a people-resilience gap that a single exercise would have surfaced.
• The regulatory cost was the dominant cost. The ₹18 crore direct loss was dwarfed by the reputational and supervisory consequences, which is typical for regulated entities.

The corrective-action programme, led by Priya, included: a mandatory live failover within 90 days (executed in a November maintenance window, with a parallel run first); automated replication-health monitoring with a secondary alert path; runbook-as-code with environment validation; DNS TTL reduction to 5 minutes with a tested cutover procedure; credential vaulting with break-glass; a quarterly call-tree test; and an annual CERT-In-clock tabletop. The programme cost around ₹35 lakh to implement, a fraction of the loss.

Illustrative Scenario 2: Success

Illustrative scenario. The following is a composite, fictionalised account drawn from publicly documented success patterns (Akasa Air's zero-cancellation response to the 19 July 2024 CrowdStrike event; Cognizant's Chennai 2015 BCP invocation mitigating financial impact). It is presented for instruction; any resemblance to a specific firm is incidental.

The organisation

"Tarang Mobility Technologies" (name illustrative) is a mid-sized SaaS platform company (around 600 employees) headquartered in Bengaluru. The platform provides ride-hailing and fleet-management services to logistics clients, processing around ₹200 crore per year in transactions. Tarang had adopted ISO 22301 in 2023 as a customer-requirement response (several enterprise clients required BCM assurance) and had built its exercise programme deliberately over the preceding 18 months under the leadership of its BCM manager, Rahul Sharma.

The exercise programme (as built)

Tarang's programme was modest in budget (around ₹45 lakh per year, mostly people time) but well-designed:

• Quarterly tabletops rotating across the top four BIA-prioritised activities (booking engine, payments processing, driver-dispatch, customer support).
• Bi-annual functional simulations with the full crisis team, including a "severe-but-plausible" multi-failure scenario (a cyber incident during a peak festival day with the on-call lead unavailable).
• Annual full failover of the tier-1 booking engine to the secondary cloud region, including failback, conducted each February in a Sunday maintenance window, with a parallel run the week before.
• Monthly component tests of the call tree (via the mass-notification platform), backup restores (automated), and the payment-failover procedure.
• An annual CERT-In 6-hour-clock tabletop with elapsed-time measurement.
• A joint exercise with the top two critical suppliers (the cloud provider and the payment processor) each year, contractually obligated.

Crucially, the programme had a closure-verification discipline: every Critical finding was re-exercised within 90 days of "closure." Rahul had built a coverage matrix showing every tier-1 activity exercised within 12 months and every tier-2 within 24.

The disruption

On 19 July 2024, the global CrowdStrike Falcon sensor content-configuration update triggered a Windows boot-loop (BSOD) on around 8.5 million devices worldwide, a real, documented event. At Tarang, around 40% of the endpoint fleet (customer-support workstations and some ops consoles) crashed within a 90-minute window. The booking engine itself ran on Linux and was unaffected, but the customer-support function was degraded, and several fleet clients called in reporting that their dispatch operators could not access the platform.

What went right

The response drew on capabilities that had been exercised, not improvised:

1. Crisis team convened in 12 minutes. The call-tree test (run monthly) meant the mass-notification platform reached all 14 crisis-team members within 8 minutes; the team was in a war-room bridge by minute 12. The target was 15 minutes (exercised).
2. Customer communications issued within 15 minutes. The comms procedure had been exercised in the bi-annual simulation; pre-approved holding statements and a status-page update were live by minute 15. The target was 20 minutes (exercised).
3. Manual booking fallback activated. For the affected fleet clients, Tarang invoked the manual-booking fallback (phone/SMS-based dispatch) that had been rehearsed in the March tabletop. Drivers were dispatched without interruption for the affected clients.
4. Cloud-region failover not needed, but validated as ready. The booking engine was unaffected, so failover was unnecessary. But because the February failover exercise had validated that the cutover completes in 38 minutes (against an RTO of 60 minutes), the team had the confidence not to invoke a risky unnecessary failover, a decision quality that only an exercised capability produces.
5. Endpoint recovery runbook executed. The CrowdStrike remediation (boot into Safe Mode, delete the problematic channel file) was executed against the documented runbook, which had been validated in a May component test of the endpoint-recovery procedure. Affected endpoints were restored over 6 hours; the alternative would have been days of per-device manual remediation.
6. Regulator and customer notifications met. Although not a CERT-In-reportable event (no personal-data breach), Tarang's enterprise customers were notified proactively within 30 minutes per contractual SLA, a capability exercised in the joint supplier drill.

Outcome and ROI

Tarang suffered zero customer-facing outage of the booking engine. The RTO target (60 minutes for tier-1) was not even invoked because the tier-1 system did not fail; the degraded functions (customer support) were restored to MBCO within 90 minutes. No SLA penalties were triggered. Estimated revenue protected on the day: ₹3.2 crore (the peak-day transaction value that would have been lost had the platform darkened). Avoided SLA penalties: around ₹80 lakh. Avoided customer churn: estimated ₹2–4 crore over the following quarter, based on the churn patterns of a competitor that suffered a similar event without a rehearsed response.

ROI of the exercise programme:

Beyond the single event, the programme produced a steady stream of improvements: the February failover exercise had surfaced (and fixed) the DNS TTL issue before it could become a real-incident failure; the May endpoint-recovery test had produced the runbook that was executed on 19 July; the monthly call-tree test had kept the notification platform's contact data current. Each of these was a finding closed by re-exercise, the closure-verification discipline that the failure case (14) lacked.

Lessons

• Modest budget, disciplined design. Tarang did not outspend its peers; it out-designed them. The exercise philosophy, the coverage matrix, and the closure-verification discipline were the differentiators.
• Exercised capability produces decision quality. The decision not to invoke an unnecessary failover was only available to a team that had validated the failover worked. Unexercised teams either over-panic (invoke a risky failover) or under-react (miss the window).
• The runbook that saved the day was written by an exercise. The endpoint-recovery runbook existed because the May component test had required it. Exercises are a forcing function for runbook completeness.
• Joint supplier exercises pay off in real incidents. The cloud provider and payment processor responded as rehearsed because they had rehearsed.
• ROI is realised in the events that do not become public. Tarang's 19 July never made the news, which is the point. The ROI of a good exercise programme is measured in the incidents that did not become incidents.

Multi-Framework Mapping

Clause 8.5 maps to the testing/exercise provisions of every major operational-resilience framework. The table below gives the real control/article/paragraph numbers. Frameworks and regulations are citable by name (they are the subject matter); this is not competitor naming.

Mapping table

The densest mappings

The two strongest regulatory anchors for "you must exercise, not just plan" are:

1. DORA Article 26 (TLPT every 3 years). For EU-exposed financial entities (including Indian IT/BPO firms serving EU banks), DORA requires Threat-Led Penetration Testing on live production at least every three years, aligned with TIBER-EU. This is the deepest end of the exercise continuum (level 6) and is now a binding legal obligation. Indian firms with EU financial-services customers should treat TLPT-readiness as a Clause 8.5 extension.
2. APRA CPS 230 paragraph 43 (annual BC exercise, severe-but-plausible). For APRA-regulated entities (effective 1 July 2025), the annual business-continuity exercise with severe-but-plausible scenarios is a binding prudential requirement. Para 43 is the cleanest regulatory restatement of the ISO 22301 8.5 expectation.

For the Indian context, the densest anchors are the RBI Master Direction's live/parallel DR drill mandate, SEBI's RTO ≤ 2 hours for MII critical systems (the tightest RTO in Indian regulation, validated only by live failover), and the CERT-In 6-hour clock (an exercised IR capability is the only way to meet it).

Harmonisation insight

Across all these frameworks, a single exercise programme, designed to the ISO 22301 8.5 continuum, with severe-but-plausible scenarios, measurable objectives, AARs, and closure verification, satisfies the exercise expectations of all of them simultaneously. A growing company serving multiple regulated markets should design one programme that maps to all applicable frameworks, not a separate programme per regulator. The coverage matrix (7.1.2) should carry a column for each applicable framework so that a single exercise can be evidenced against multiple obligations.

Implementation Roadmap

A pragmatic 180-day roadmap for a growing company moving from L1 to L2, plus the longer horizon to L4.

First 30 days, establish the foundation

• Appoint the BCM manager as exercise programme owner; confirm executive sponsor.
• Write the one-page exercise philosophy statement (Section 7.1.1).
• Build the coverage matrix from the BIA (Section 7.1.2); identify the tier-1 activities with no exercise in the last 12 months (the highest-risk cells).
• Draft the 12-month exercise calendar.
• Schedule the first tabletop on the top-priority tier-1 activity.
• Stand up the corrective-action register (in the ITSM or a dedicated tracker).

Days 31–90, first exercises and the AAR discipline

• Conduct the first tabletop; produce a hot wash within 24 hours and an AAR within 10 working days.
• Log the first corrective actions; assign owners and due dates.
• Conduct the first component tests: a backup-restore verification and a call-tree test.
• Run the first CERT-In 6-hour-clock tabletop; measure elapsed time (expect the first attempt to miss, that is the finding).
• Report the first quarterly dashboard to the sponsor.
• Review and refresh the scenario library (Section 7.2.4); ensure at least one cyber, one natural-hazard, one supplier, and one people-resilience scenario.

Days 91–180, simulations and supplier engagement

• Conduct the first cross-functional simulation (level 4); include the crisis team and at least one board-level participant for regulated entities.
• Engage the top critical supplier on a joint exercise (tabletop first; component test later).
• Plan the first live failover (level 5) for a tier-1 system; target a maintenance window in the next quarter.
• Verify closure of at least 50% of the corrective actions from the first exercises; re-exercise at least one Critical finding.
• Begin the quarterly cadence: tabletop, component test, simulation per the calendar.

Days 181–365, first live failover

• Conduct the first live failover of a tier-1 system: parallel run first, then cutover, then failback. Measure RTO and RPO against BIA targets.
• Produce a complete AAR; log all findings; assign corrective actions.
• Re-exercise the Critical findings within 90 days.
• Conduct the annual programme review (Section 7.7.3); adjust the philosophy and calendar.
• For regulated entities, present the annual exercise summary to the board/Risk Committee.

Year 2, reach L3/L4

• Annual live failover for all tier-1 systems; bi-annual simulations.
• Bi-annual joint exercises with the top two critical suppliers.
• Begin an ecosystem drill with key customers (for SaaS/BPO firms) or with the regulator (for MIIs).
• Bring in an external facilitator for one exercise per year.
• Achieve closure-verification rate ≥ 70% for Critical/Major findings.

Year 3, L4 and TLPT-readiness

• Quarterly tabletops, bi-annual simulations, annual live failover as business-as-usual.
• For EU-exposed entities: TLPT-readiness (DORA Art 26); engage a TIBER-EU-aligned testing provider.
• Independent programme review (external).
• Closure-verification rate ≥ 90% for Critical findings; finding-recurrence rate ≤ 10%.

Budget profile (250–2,000 band, INR)

FAQ

Q1. We are a small company (under 250 staff). Do we really need a full exercise programme? Clause 8.5 applies regardless of size, but the depth is risk-based. A small firm can satisfy the clause with annual tabletops on its top three prioritised activities, annual restore tests, and a biennial call-tree test. The investment is mostly staff time. The risk of no exercise programme is the same for a small firm as for a large one, the plan does not work when invoked.

Q2. Our DR site has never had a live cutover. How do we start? Begin with a parallel run (traffic to both primary and DR simultaneously, with DR read-only) to validate replication and routing. Then schedule a cutover in a maintenance window with a documented abort/rollback and a named abort owner. Start with a tier-2 system before a tier-1. Always test failback. If the first cutover fails, that is the finding, log it, fix it, re-exercise.

Q3. The business says it cannot afford the risk of a live failover. How do we respond? The risk of not doing a live failover is greater: operating with an unvalidated strategy. Frame it as: the first live failover can be a parallel run (no customer impact); the abort/rollback makes it reversible; the maintenance window contains it. The cost of a real-incident discovery that the failover does not work (see Illustrative Scenario 1) is orders of magnitude higher than the cost of a planned exercise.

Q4. How often should we exercise each system? Risk-based: tier-1 (RTO ≤ 4 hours), annual live failover plus quarterly tabletop/component tests; tier-2 (RTO 4–24 hours), bi-annual simulation and bi-annual failover; tier-3 (RTO > 24 hours), annual tabletop and bi-annual restore test. Regulatory mandates may tighten this (SEBI MII critical systems: RTO ≤ 2 hours, live failover per the circular's cadence).

Q5. What is the difference between an exercise and a test? An exercise rehearses people, plans, and decisions (tabletop, simulation). A test evaluates a specific component or system pass/fail (restore test, failover timing). ISO 22301 8.5 requires both, exercising the response capability and testing the technical recovery. "Drill" (the regulatory term) usually means either.

Q6. Do we need to include the board in exercises? For regulated entities (RBI/SEBI/IRDAI), yes, at least annually, the board/Risk Committee should participate in a decision-rehearsal tabletop, because real disruptions require board-level decisions (capital allocation, regulator engagement, public statements). For non-regulated entities, a board-level tabletop annually is best practice.

Q7. How do we exercise the CERT-In 6-hour clock? Run a tabletop that starts at simulated discovery and walks the team through triage, classification, notification drafting, escalation, and reporting, measuring elapsed time at each step. Most first attempts take 8–12 hours. The finding drives corrective action (pre-drafted templates, pre-identified recipients, clear classification criteria). Re-run annually.

Q8. Our supplier (cloud/SaaS) says they test their DR. Do we still need a joint exercise? Yes. The supplier's DR test validates their failover; it does not validate your failover with them, the integration points, the notification chain, the shared runbook. RBI's Outsourcing of IT Services Master Direction and SEBI/IRDAI rules require that outsourced continuity meets your standards, which is only demonstrable through joint exercises.

Q9. What if our exercise causes a real incident? Treat exercise-inherent risk explicitly (Section 10): maintenance windows, abort criteria, rollback plans, pre-exercise backups, isolated restore environments. The exercise plan must document the abort triggers and the abort owner. With these controls, the residual risk is low; without them, it is high.

Q10. How do we avoid "tabletop theatre"? Three controls: (a) severe-but-plausible scenarios that stress the margins; (b) a facilitator who does not steer the team to the right answer; (c) willingness to publish failures internally and to rate them honestly in the AAR. An exercise that produces no findings is a red flag, not a success.

Q11. Do we need to exercise DPDP breach notification? Yes. DPDP Section 8(6) and the Schedule require breach notification to the Data Protection Board and affected individuals. Run a tabletop that measures the elapsed time from discovery to notification, against the DPDP Rules 2025 timeline (notify the Board within 72 hours of becoming aware). This is a Clause 8.5 exercise that also satisfies a statutory duty.

Q12. Our corrective-action closure rate is low. What does that indicate? Either the actions are under-resourced (no time/money to fix) or the findings are under-specified (no clear fix). Both are programme weaknesses. Escalate to management review (Clause 9.3); ensure the budget funds corrective actions; ensure findings have clear root-cause analysis before corrective actions are assigned.

Q13. We are an IT services firm serving EU financial clients. Do we need TLPT? If you are designated a critical ICT third-party service provider under DORA, or if your EU clients require TLPT evidence contractually, yes, DORA Art 26 requires TLPT every 3 years for systemic entities. Even if not directly designated, TLPT-readiness is increasingly a customer requirement. Begin planning 12–18 months ahead (TIBER-EU-aligned testing, tester independence, live-production scope).

Q14. Can we use the same exercise for multiple frameworks? Yes, and you should. A single well-designed exercise can be evidenced against ISO 22301 8.5, ISO 27001 A.5.30/A.8.13/A.8.14, DORA Art 25, APRA CPS 230 para 43, RBI MD drills, and SEBI CSCRF recovery, provided the coverage matrix carries the framework columns and the AAR documents the multi-framework relevance. Design one programme; evidence it many ways.

Q15. How do we measure the ROI of the exercise programme? Track: incidents avoided or reduced (revenue protected), SLA penalties avoided, regulatory actions avoided, insurance premium reductions (exercised programmes can reduce cyber-insurance premiums), and audit findings avoided. The single-event payback in Illustrative Scenario 2 (~14× annual programme cost) is representative of mature programmes; the first 2–3 years are investment, after which the ROI compounds.

Industry-Specific Requirements

BFSI (Banking, NBFCs, Payment Systems)

The most prescriptive exercise regime in India. RBI Master Direction on IT Governance (7 Nov 2023, eff 1 Apr 2024) requires periodic BCP drills including live and parallel DR drills for banks, NBFCs (≥ ₹500 crore asset base), and AIFIs. The 2016 Cyber Security Framework mandates a Cyber Crisis Management Plan with periodic drills and 2–6 hour RBI incident reporting. SEBI BCP/DR for MIIs (CIR/2021/33) requires live failover drills with RTO ≤ 2 hours for critical systems, the tightest RTO in Indian regulation. The 2024 CSCRF extends recovery-testing expectations across all SEBI Regulated Entities. For BFSI, the exercise programme must include: annual live failover of the core banking/trading/clearing system; bi-annual cyber-incident simulations against the RBI/CERT-In clocks; joint exercises with payment networks (NPCI/UPI ecosystem drills); and regulator-witnessed drills. DORA applies to EU-exposed entities (including Indian IT/BPO serving EU banks) from 17 January 2025, with TLPT every 3 years for systemic entities.

Insurance (IRDAI)

IRDAI Information & Cyber Security Guidelines 2023 (24 April 2023) require DR drills, board Risk/IT committee oversight of BCP/DR, 180-day log retention (aligned with CERT-In), and annual compliance reporting within 90 days of FY-end. The exercise programme must include: annual DR drill of the policy administration and claims systems; simulation of a mass-claims event (a natural-catastrophe spike); and a tabletop against the IRDAI incident-reporting timeline. Insurers handling policyholder data must also exercise DPDP breach notification.

Healthcare

Healthcare continuity is patient-safety-adjacent, and the AIIMS Delhi November 2022 ransomware (e-Hospital down ~6–15 days, primary and backup servers encrypted, OPD/admissions/billing/labs reverted to paper) is the defining Indian lesson. The exercise programme must include: annual failover of the EHR/LIS systems; simulation of a ransomware-driven clinical-downgrade to manual-mode (the exercise validates that manual-mode is actually workable); a tabletop against patient-safety escalation (when does a continuity failure become a patient-transfer decision?); and a breach-notification exercise (DPDP for personal data; sectoral rules for health data). Clinical-continuity exercises should involve clinical leadership, not just IT.

IT-ITeS and SaaS

For IT services and SaaS firms, the exercise programme is driven by customer-contractual RTO/RPO and by ecosystem participation. Key exercises: annual failover of the SaaS platform to the secondary region (with failback); multi-tenant failover (validating tenant isolation during cutover); joint exercises with the top critical customers (especially for BPO/KPO whose customers' BCPs depend on the vendor); supply-chain-compromise tabletops (SolarWinds-style and MOVEit-style scenarios); and DORA TLPT-readiness for EU-financial-services-serving firms. For BPOs, the exercise programme should also address people-resilience (the Akasa pilot-exodus pattern applies to any key-skill-concentrated workforce).

Manufacturing and Process Industries

NDMA Chemical Disasters Guidelines (2007) require on-site and off-site emergency plans and their periodic rehearsal for Major Accident Hazard units, with integration into District DMPs. The LG Polymers Vizag styrene gas leak (7 May 2020; NGT ₹50 crore interim penalty; LG Chem ₹730 crore relief package; plant permanently closed) is the defining lesson. The exercise programme must include: OT/IT joint exercises (IT/OT dependency modelling, the Colonial Pipeline 2021 lesson that a billing outage can force an OT shutdown); supplier-failover drills for single-source critical inputs (the Go First P&W engine pattern); chemical-emergency rehearsal under NDMA; and ransomware tabletops that include the production-stoppage decision (the Sun Pharma 2023 pattern, for pharma/mfg, a containment decision is a production-stoppage decision). The Maruti Suzuki Manesar 2012 pattern (workplace violence and fire) is a reminder that industrial-relations and workplace-violence scenarios belong in the exercise library alongside fire, flood, and cyber.

Government and Public Sector

NDMA's Disaster Management Plan template (Prevention/Mitigation/Preparedness/Response/Relief/Recovery/Reconstruction/Capacity Building) drives the exercise structure for ministries, departments, PSUs, and CPSEs. The Disaster Management Act 2005 (Sections 51–60) creates penalties for non-compliance with disaster-authority directions during a disaster, making exercised emergency-response a statutory expectation. Government exercises should integrate with District DMPs and State DMAs, and (for critical-infrastructure operators) with NCIIPC under IT Act Section 70A. The FEMA FCD-1/FCD-2 four-phase COOP model (Readiness/Preparedness → Activation/Relocation → Continuity Operations → Reconstitution) is a useful structural reference for Indian public-sector COOP exercises, adapted to the NDMA framework.

Maturity Model

The five-level maturity model for the Clause 8.5 exercise programme. INR estimates are annual running cost for a mid-market (250–2,000) firm; large enterprises scale up by an order of magnitude.

Level 1, Initial / Ad hoc

• Characteristics: Exercises are unplanned, infrequent, and run only when required (e.g., a customer audit or a regulator query). No programme document; no coverage matrix; no AAR discipline; no corrective-action tracking. The DR site has never had a live cutover.
• Evidence: A fire-drill log; a backup-restore test record; an ad hoc tabletop from last year.
• Audit outcome: Major nonconformity against Clause 8.5.
• Typical loss exposure: A real disruption will cause 3–10× the RTO in outage time and significant regulatory/reputational cost (the Illustrative Scenario 1 pattern).
• Annual cost: ₹0–3 lakh (mostly reactive).
• Priority actions: Write the philosophy; build the coverage matrix; schedule the first tabletop.

Level 2, Managed / Repeatable

• Characteristics: A documented programme with annual calendar; quarterly tabletops; component tests (restore, call-tree); first AARs; corrective-action register live. No live failover yet (or first one planned). Closure by paperwork, not yet by re-exercise.
• Evidence: Programme document; 12-month calendar; 4+ AARs per year; corrective-action register.
• Audit outcome: Conformity at recertification if closure discipline is improving; minor nonconformity if no live failover by year 2.
• Typical loss exposure: RTO attainment uncertain; first real disruption will likely miss RTO but recover within 2–3×.
• Annual cost: ₹15–25 lakh.
• Priority actions: First live failover; closure-verification re-exercise; CERT-In-clock tabletop.

Level 3, Defined / Risk-based

• Characteristics: Risk-based programme with coverage matrix tracking every tier-1 activity; annual live failover for tier-1; bi-annual simulations; closure-verified by re-exercise for Critical findings; supplier exercises; programme reported to leadership.
• Evidence: Coverage matrix; failover records with RTO/RPO attainment; closure-verification records; supplier-exercise records; leadership dashboard.
• Audit outcome: Conformity with positive auditor commentary.
• Typical loss exposure: RTO attainment likely in real disruptions; regulatory exposure low.
• Annual cost: ₹25–40 lakh.
• Priority actions: Bi-annual failover; ecosystem drill; external facilitation; board-level exercise.

Level 4, Quantitatively Managed

• Characteristics: Programme measured against quantitative targets (RTO/RPO attainment ≥ 90%; closure-verification ≥ 70%; recurrence ≤ 10%); live failover for all tier-1 and tier-2; ecosystem drills with customers/regulators; independent programme review.
• Evidence: KPI dashboard with trend lines; multi-year progression evidence; independent review report.
• Audit outcome: Conformity with maturity commendation.
• Typical loss exposure: Low; incidents are contained within RTO; regulatory exposure minimal.
• Annual cost: ₹40–60 lakh.
• Priority actions: TLPT-readiness (if EU-exposed); cross-border joint exercises; continual-improvement of scenario realism.

Level 5, Optimising / Continually Improving

• Characteristics: Programme is a strategic asset; exercises drive BCMS and enterprise-risk improvements; live-failover and TLPT are business-as-usual; scenario library continuously refreshed from threat intel and real incidents; lessons feed back into BIA/strategy/plan redesign (Clause 10.2). The programme influences the sector (industry-wide drills, regulator collaboration).
• Evidence: Programme-improvement records; sector-drill participation; published lessons (anonymised); TLPT records.
• Audit outcome: Exemplary.
• Typical loss exposure: Minimal; the organisation is resilient by design and validation.
• Annual cost: ₹60 lakh–₹5 crore (scales with size and systemic importance).
• Priority actions: Sustain; mentor sector peers; contribute to industry resilience.

Maturity progression guidance

Most growing companies start at L1 and should target L2 within 6–9 months and L3 within 18–24 months. The leap from L2 to L3, the first live failover with closure verification, is the highest-use transition and the one that most reduces real-incident risk. L4 and L5 are appropriate for systemically-important or heavily-regulated entities; for most firms in the 250–2,000 band, a solid L3 is both achievable and sufficient to satisfy ISO 22301 and the Indian regulators.

Emerging Trends

Threat-led penetration testing (TLPT) going mainstream

DORA Article 26's TLPT-every-3-years requirement (aligned with TIBER-EU) is normalising live-production, adversary-emulation testing as a Tier-1 exercise expectation for the financial sector. For Indian firms serving EU financial clients, TLPT-readiness is becoming a customer-requirement even where DORA does not directly bind. Expect TLPT-style testing to extend beyond the EU (the UK FCA/PRA CB already use a similar operational-resilience testing model; APRA and MAS are moving in the same direction). The exercise continuum in Section 5.2 places TLPT at level 6, the deepest end, and growing companies with EU exposure should plan for it on a 3-year horizon.

Ecosystem and industry-wide exercises

The UPI ecosystem (around 20+ billion monthly transactions, the world's largest real-time retail rail) has been the site of repeated nationwide outages (the 12 April 2025 event was the longest in recent memory at around 5 hours; NPCI attributed it to participating banks over-polling "check transaction status" APIs). The lesson, increasingly internalised by NPCI and the RBI, is that systemic-critical-rail BC/DR extends beyond the operator to banks and PSPs, requiring joint failover drills, rate-limits, and circuit breakers exercised across the ecosystem. Expect more regulator-mandated ecosystem drills (SEBI MII drills, RBI payment-ecosystem drills, IRDAI insurer-reinsurer drills), and expect growing companies in the payments and capital-markets ecosystems to be required to participate.

Climate-amplified scenarios (ISO 22301 Amd 1:2024)

ISO 22301:2019/Amd 1:2024 added climate-change adaptation to Clauses 4.1/4.2 context. The exercise implications: climate-amplified hazards (heatwave-driven DC cooling failure, monsoon-intensity flooding, cyclone-driven multi-site disruption, sea-level-rise affecting coastal DCs over the long horizon) must enter the scenario library as plausible, not exotic. For Indian organisations, these are already the dominant natural-hazard scenarios, the amendment formalises what Indian BCM practice should already have incorporated. The BCI Horizon Scan 2025 ranks safety incidents (14.64 risk index) and extreme weather among the top disruptors.

AI and the exercise programme

Two directions. First, AI as exercise tool: generative AI can produce scenario injects, simulate regulator/customer/media interactions during tabletops, and draft AAR narratives from exercise logs, accelerating exercise design and conduct. Use with care: AI-generated scenarios can drift toward the generic; keep the severe-but-plausible and organisation-specific anchors. Second, AI as exercised capability: AI systems are increasingly critical-path dependencies (decision-support, fraud detection, customer service), and the exercise programme must include AI-failure scenarios (model degradation, data-poisoning, vendor-API outage) and AI-in-incident-response scenarios (AI-assisted detection failing, adversarial AI in social-engineering).

Operational resilience displacing continuity planning

The global trajectory, DORA, APRA CPS 230, HKMA OR-2, UK FCA/PRA/CB operational-resilience policy, is from "continuity of operations" (keep the system running) to "operational resilience" (remain within impact tolerance through severe disruption). The exercise implication: scenarios must test not just "can we recover?" but "did we stay within tolerance throughout?", which is a harder, outcome-oriented test. For growing companies, this means exercising against impact tolerances (MTPD/MBCO), not just against RTO/RPO, and designing scenarios that test the tolerance boundary, not the recovery moment.

People-resilience as a first-class exercise dimension

The Akasa pilot-exodus pattern (43 pilots resigning in a month; around 600–800+ flights cancelled; losses around ₹3 crore/day) and the pandemic-absenteeism experience have elevated people-resilience to a first-class exercise dimension. Expect exercises that test: key-person loss (the "bus factor" tabletop), mass-skill shortage, workforce displacement (a natural disaster that makes staff unable to reach site, the Chennai 2015 lesson), and cross-training adequacy. For asset-light growth firms (SaaS, services), people-resilience exercises may be more relevant than infrastructure failovers.

Continuous validation replacing periodic testing

The technology trend, DR orchestration with automated validation, continuous replication-health monitoring, automated restore-testing, is shifting the exercise programme from periodic (annual live failover) toward continuous (daily/weekly automated validation with periodic full exercise). The mature programme does both: continuous automated validation for the technical-recovery dimension, and periodic human exercises for the decision-and-coordination dimension. The former keeps the strategy honest between exercises; the latter keeps the people ready.

References and Further Reading

Standards and official guidance (Tier 1)

• ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements (ISO/TC 292). Including ISO 22301:2019/Amd 1:2024 (climate change adaptation).
• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301.
• ISO 22300:2021, Security and resilience, Vocabulary (3rd edition; a 4th edition is under development (ISO/DIS 22300, 4th ed.) and not yet published, verify current edition at iso.org).
• ISO/TS 22317:2021, Guidelines for business impact analysis (2nd ed.; supersedes 2015).
• ISO/TS 22318:2021, Guidelines for supply chain continuity (2nd ed.; supersedes 2015).
• ISO/TS 22331:2018, Guidelines for business continuity strategy.
• ISO/TS 22330, Guidelines for people aspects of business continuity.
• ISO 22316, Guidelines for organizational resilience.
• ISO/IEC 27001:2022, Information security management systems, Requirements (Annex A controls A.5.30, A.8.13, A.8.14).

Indian regulatory instruments (Tier 1)

• RBI Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024), RBI portal id 12562.
• RBI Cyber Security Framework in Banks (2 June 2016).
• RBI Master Direction on Outsourcing of Information Technology Services (10 April 2023).
• RBI Complete Cyber Security Framework for Primary (Urban) Cooperative Banks (31 December 2019).
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF), SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 (20 August 2024).
• SEBI Guidelines for BCP/DR of Market Infrastructure Institutions, SEBI/HO/MRD1/DTCS/CIR/P/2021/33 (22 March 2021).
• IRDAI Information and Cyber Security Guidelines, 2023 (24 April 2023).
• CERT-In 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) and the DPDP Rules, 2025.
• Disaster Management Act, 2005 (Act 53 of 2005); NDMA Guidelines, Chemical Disasters (Industrial), 2007; Guidelines for Preparation of Disaster Management Plans.
• Companies Act, 2013, Section 134(3)(n) and Section 177; SEBI LODR Regulation 21 (Risk Management Committee).
• Information Technology Act, 2000, Sections 43, 65, 66, 70, 70A, 70B, 72, 84A.

Global frameworks and regulations (Tier 1)

• DORA, Regulation (EU) 2022/2554 of 14 December 2022 on digital operational resilience for the financial sector; applies from 17 January 2025. Articles 11, 12, 25, 26 (TLPT), 30, 35.
• APRA Prudential Standard CPS 230, Operational Risk Management; effective 1 July 2025. Paragraphs 34–46 (business continuity), especially para 38 (tolerance levels) and para 43 (annual BC exercise).
• NIST SP 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems (May 2010). Seven-step process; Step 6 = testing, training, exercises.
• NIST SP 800-160 Vol 2 Rev 1, Developing Cyber-Resilient Systems (September 2021).
• NIST Cybersecurity Framework 2.0 (NIST.CSWP.29, 26 February 2024), Recover function (RC.RP, RC.CO, RC.IM).
• FFIEC IT Examination Handbook, Business Continuity Management Booklet (November 2019; OCC Bulletin 2019-57; FRB SR 19-13; FDIC FIL-19071-2019).
• FEMA Federal Continuity Directives FCD-1 (17 January 2017) and FCD-2 (13 June 2017) under PPD-40.
• MAS Technology Risk Management Guidelines (18 January 2021) and MAS Guidelines on Business Continuity Management.
• HKMA Supervisory Policy Manual, TM-G-2 (Business Continuity Planning, revised 31 May 2022) and OR-2 (Operational Resilience, 31 May 2022).

Practitioner bodies and datasets (Tier 2)

• BCI practitioner guidance (31 October 2023), six Professional Practices.
• DRI International, DRI professional-practice framework (living framework).
• BCI Horizon Scan 2025, "Complex and Interconnected Risk"; BCI Horizon Scan 2024 (IT/telecom outages most-disruptive; 69.5% productivity loss).
• ISO/IEC 17021-1:2015 and IAF Mandatory Documents, the rule-set governing ISO 22301 audits by accredited certification bodies (BSI Group, DNV, SGS, TÜV, Bureau Veritas, Intertek, TQCS, and others). Note: no BCMS-specific IAF MD exists.

Incident references (factual events cited for lessons)

• Tokyo Stock Exchange Arrowhead outage, 1 October 2020 (full-day trading halt; failover failed due to settings drift).
• British Airways IT outage, 27 May 2017 (uncontrolled return of power; redundant systems shared failure domain).
• Maersk NotPetya, 27 June 2017 (network rebuilt in 10 days from a single surviving domain controller).
• CrowdStrike global IT outage, 19 July 2024 (faulty Falcon sensor update; ~8.5M Windows devices disabled).
• Cognizant Maze ransomware, April 2020 (SEC-filed Q2 2020 impact USD 50–70 million).
• AIIMS Delhi ransomware, 23 November 2022 (e-Hospital down ~6–15 days; NIA cyberterrorism probe).
• HDFC Bank RBI action, 2 December 2020 (barred from new digital products and fresh credit cards after repeated outages).
• Jio nationwide outage, 17 September 2024 (data-centre fire; Cloudflare Radar measured traffic down up to 53%).
• Go First insolvency, filed 2 May 2023 (PW1100G engine failures; ₹597 crore refund liability).
• SpiceJet DGCA order, 27 July 2022 (50% of approved flights for 8 weeks).
• LG Polymers Vizag styrene leak, 7 May 2020 (NGT interim penalty ₹50 crore; LG Chem ₹730 crore relief package).
• Maruti Suzuki Manesar violence, 18 July 2012 (workplace-violence and fire scenario; ~₹1,400 crore lockout loss).
• Akasa Air pilot exodus, 2023 (43 pilots resigning in a month; ~₹3 crore/day losses at peak).
• Chennai floods, December 2015 (Cognizant BCP invocation; FY2015 revenue guidance ≥ USD 12.41 billion reaffirmed).
• UPI nationwide outages, including 12 April 2025 (around 5 hours; attributed to participating banks over-polling APIs).

This guide is published by Singahi for growing companies implementing ISO 22301:2019. It paraphrases the standard's clause text; it does not reproduce the official ISO wording. Frameworks, regulations, and certification bodies are cited by name as the subject matter of compliance; no competitor product or reference book is named. Scenarios are illustrative and fictionalised for instruction. For the ready-to-customize toolkit accompanying this clause, see the Singahi Control Pack.