ISO 22301 Clause 8.4: Business Continuity Plans and Procedures

Quick Reference (60 Seconds)

If you only read one thing: Clause 8.4 is where the BCMS stops being strategy and starts being muscle memory. The BIA (8.2) tells you how fast you must recover; Clause 8.3 tells you what you will recover to; Clause 8.4 is the clause where you write down who does what, in what order, with what authority, and how they talk to each other and to the outside world when a disruption hits. Get this clause right and a disruption becomes a managed event; get it wrong and a disruption becomes a series of improvised decisions made by whoever happens to be awake, with the regulator's clock already running.

What the Standard Actually Requires

Figure · Process

What Clause 8.4 asks you to do

The paraphrased requirement

ISO 22301 Clause 8.4 asks organizations to implement and maintain a response structure and documented plans and procedures to manage the organization through a disruption. In practical terms, this means an organisation has to be able to answer eight questions in writing:

1. Response structure, Who is in charge during a disruption? Who leads the incident response, who leads the crisis management, who leads the business continuity response, and who leads recovery? What are their authorities, and who deputies for them if they are unreachable? The response structure is the org chart for the disruption, it does not have to mirror the normal org chart, and often should not.
2. Plan hierarchy, What is the set of plans we will use, and how do they relate? At minimum, most organisations need a master Business Continuity Plan, an IT Disaster Recovery Plan, a Crisis Communications Plan, and departmental or team-level plans. The hierarchy matters: the master BC plan orchestrates; the subordinate plans execute.
3. Invocation, How and by whom are the plans invoked? What triggers invocation? What is the threshold between "an incident the operations team handles" and "a disruption that invokes the BC plan"? Who has the authority to invoke, and who has the authority to stand down? Invocation is the most under-specified element in immature BCMSs; Clause 8.4 requires it to be defined.
4. Warning and communication, How do we warn people that a disruption is happening, and how do we communicate through the disruption? This covers internal warning (employees, contractors, site occupants), external communication (customers, regulators, media, public), and the link between them. In India, this is where the CERT-In 6-hour clock, the RBI incident-reporting clocks, the SEBI CSCRF incident-notification clocks, the IRDAI breach-notification clock, and the DPDP breach-notification clock all attach.
5. Business continuity response, What do we actually do to keep prioritised activities running or bring them back? This is where the chosen continuity strategies from Clause 8.3 become step-by-step procedures: failover to the DRS, switch to manual workaround, relocate to work-area recovery, invoke alternate supplier, defer non-critical work.
6. Incident response, How do we manage the incident itself, the IT incident, the physical incident, the security incident, that caused the disruption? Incident response is distinct from but integrated with business continuity response: IR stops the bleeding; BC keeps the patient alive while IR works.
7. Manual workarounds, Where the continuity strategy depends on people doing things manually (paper-based transactions, manual check-in, manual order processing, manual clinical documentation), are those workarounds documented, trained, and resourced? A workaround that exists only in the head of a veteran employee is not a Clause 8.4 procedure.
8. Maintenance, How and when are the plans reviewed, updated, version-controlled, and re-approved? Plans decay, contact lists go stale within weeks, system architectures change monthly, regulator clocks shift. A plan that is not maintained is a plan that will fail when invoked.

The four sub-clauses of 8.4

ISO 22301:2019 structures Clause 8.4 into four sub-clauses. Paraphrased (not verbatim), they break down as follows:

• 8.4.1 General, The organisation must have documented plans and procedures to manage a disruption, derived from the BIA (8.2) and the chosen continuity strategies (8.3). The plans need to be appropriate to the organisation's scale, complexity, and the priorities identified in the BIA, and to cover warning, communication, response, and recovery.
• 8.4.2 Warning and communication, The organisation must have procedures to warn people (employees, contractors, visitors, relevant stakeholders) that a disruption is occurring or may occur, and to communicate with them through the disruption. This covers internal warning, external communication (customers, suppliers, regulators, media, public), and the means by which communication is carried out when normal channels are degraded.
• 8.4.3 Business continuity response, The organisation must have procedures to respond to the disruption and to continue or recover prioritised activities to the level and within the timescales defined in the BIA. This covers invocation, activation of continuity strategies, manual workarounds, and coordination across the response structure.
• 8.4.4 Incident response structure, The organisation must have a documented incident response structure defining the roles, responsibilities, and authorities for managing a disruption. The structure needs to be communicated to those who need to know it, and to be exercised (which links to Clause 8.5).

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

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

• It does not require the BIA. That is Clause 8.2. The BIA feeds plan authoring, it tells you which activities the plans must cover, what RTO/RPO/MBCO the plans must deliver, and what dependencies the plans must account for. A plan written without a BIA is a plan that cannot demonstrate it covers the right things at the right speed.
• It does not require selecting continuity strategies. That is Clause 8.3. The chosen strategy is the design the plans execute; the plans are the runbooks. A plan that references a strategy that was never selected under 8.3 is a plan built on an assumption.
• It does not require exercising the plans. That is Clause 8.5. Exercises validate that the plans work; if they do not, the plans are revised under 8.4 and re-tested under 8.5. But Clause 8.4 is where the plans themselves live.
• It does not mandate a specific plan structure. ISO 22301 does not require a 5-plan hierarchy or a 7-plan hierarchy or any particular template. It requires that the set of plans be appropriate to the organisation's scale and complexity, cover warning/comms/response/recovery, and be derived from the BIA and strategy. A 50-person SaaS firm and a 50,000-person bank will have very different plan sets.
• It does not require every plan to be tested in every exercise. Clause 8.5 governs the exercise programme; Clause 8.4 governs the plans. The link is that exercises must cover the plans (8.5) and that plan failures found in exercises trigger plan revision (8.4 + 10.1).
• It does not require the incident response structure to mirror the normal management structure. In fact, the incident response structure often deliberately diverges, the person who leads the BCM response may not be the person who leads the corresponding function in normal operations. What matters is that the structure is defined, communicated, and people know their role in it.
• It does not require a separate "incident response" plan distinct from BC. Many organisations operate an IT incident management process, a security incident response plan, and a BC plan as separate documents. ISO 22301 requires that the incident response structure (8.4.4) is defined and integrated with the BC response (8.4.3); how the documents are organised is the organisation's choice.

The companion guidance

The clause text is short; the method lives in companion documents:

• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301. The clause-by-clause companion. Use it as the authoritative explanation of what 8.4 evidence should look like and how the response structure links to the BIA and strategy.
• ISO 22300:2021, Security and resilience, Vocabulary. Third edition; supersedes the withdrawn 22300:2018. The normative source of the definitions of disruption, incident, invocation, response, recovery, prioritised activity, and the RTO/RPO/MBCO/MTPD terms the plans must deliver. A fourth edition (ISO/DIS 22300) is under development (enquiry stage) and will replace the 2021 edition when published; not yet published, re-confirm the year before quoting.
• ISO/TS 22331:2018, Guidelines for business continuity strategy. The strategy-selection methodology that feeds plan authoring; the chosen strategy is the design the plans execute.
• ISO/TS 22330, Guidelines for people aspects of business continuity. The method behind the people dimension of the response structure: succession, cross-training, welfare, and the human factors of crisis response.
• ISO/TS 22318:2021, Guidelines for supply chain continuity. Second edition; supersedes the withdrawn 2015 first edition. Extends plan authoring to the supplier dimension, the plans must include supplier-failover and supplier-notification procedures.

What auditors actually check

A certification auditor (from BSI Group, DNV, SGS, TÜV, Bureau Veritas, Intertek, TQCS, NQA, or another accredited body) will look for the following evidence, in roughly this order:

1. The plan set exists and is version-controlled. They will ask to see the master BC plan, the IT DR plan, the crisis comms plan, and a sample of departmental plans. They will check version numbers, last-reviewed dates, and approval signatures. A plan with no version control is a plan that cannot demonstrate it is current.
2. The response structure is documented and communicated. They will ask to see the incident response structure chart, the Incident Management Team, the Crisis Management Team, and their deputies. They will check whether the people named know they are named (they will sample-interview a few).
3. Invocation is defined. They will ask: "Who can invoke the BC plan, and on what criteria?" If the answer is "the BCM Lead decides," the follow-up is "what if the BCM Lead is on a plane?", and the audit fails if there is no deputy and no criteria.
4. The plans are derived from the BIA. They will cross-check: the BIA says activity X has an RTO of 4 hours; does the BC plan have a procedure that recovers activity X within 4 hours? Does the DR plan have a failover procedure for the systems that support activity X within a window that lets the BC procedure hit its RTO? A mismatch is a finding.
5. Warning and communication procedures exist and include regulator clocks. They will ask to see the crisis comms plan and check whether it addresses the regulatory notification clocks applicable to the organisation, CERT-In 6 hours, RBI 2–6 hours, SEBI CSCRF, IRDAI, DPDP 72 hours to the Board. Missing these is a finding under 8.4.2 because it is also a regulatory nonconformity.
6. Manual workarounds are documented where strategy depends on them. If the BIA or strategy says "manual workaround for the first 2 hours," the auditor will ask to see the workaround SOP, the training record, and the last time it was exercised. A workaround that exists only in the strategy document is not a procedure.
7. Plans have been reviewed on schedule. They will check the review log. A plan last reviewed 18 months ago, with a stated review cycle of 12 months, is a finding.
8. Plans have been exercised. This links to 8.5, but the auditor will ask whether the plans as written have ever been picked up and used in an exercise or a real invocation. A plan that has never been used is a plan whose usability is unproven.
9. Lessons from exercises and real incidents have been fed back into plan revisions. They will check the corrective-action log (Clause 10.1) for plan-related actions and verify the plans were updated. A post-incident review whose lessons were never incorporated into the plans is a finding under both 8.4 and 10.1.

Common paraphrase-pitfalls to avoid

When describing Clause 8.4 to your own stakeholders, avoid these common misstatements:

• "8.4 is the DR plan clause." It is not. The DR plan is one of several plans 8.4 requires; the clause is broader, it covers the response structure, the BC plan, crisis comms, departmental plans, invocation, and warning procedures. Calling 8.4 "the DR plan clause" understates it and is an audit red flag if it appears in your own BCMS documentation.
• "8.4 is about IT recovery." It is about business recovery, of which IT recovery is one component. An IT DR plan that recovers servers but does not address the business activities those servers support is not a Clause 8.4 plan.
• "8.4 requires a single consolidated BC plan." It does not. It requires a documented set of plans; whether that is one document or many is the organisation's choice, driven by scale and complexity.
• "8.4 requires the plans to be tested." Testing is Clause 8.5. Clause 8.4 requires the plans to exist, be maintained, and be derived from the BIA and strategy; the validation that they work is 8.5's job.

Why This Control Matters

The business risk of not having executable plans

The uncomfortable truth about business continuity is that analysis without execution is worthless. An organisation can have a flawless BIA, a beautifully engineered continuity strategy, and an expensive DRS, and still fail catastrophically during a real disruption because nobody knows who is in charge, the contact list is stale, the invocation criteria were never defined, or the manual workaround exists only as a bullet point in a strategy document that nobody has read. Clause 8.4 exists because the gap between having a strategy and being able to execute it under pressure is where most real-world continuity failures occur.

The cost of that gap is not theoretical. The 19 July 2024 CrowdStrike Falcon sensor content-configuration update triggered a Windows boot-loop that disabled roughly 8.5 million devices worldwide (Microsoft estimate); insurer Parametrix estimated direct Fortune 500 losses at approximately USD 5.4 billion, with only 10–20% insured. The same trigger produced radically different outcomes across airlines operating in India: IndiGo cancelled approximately 283 flights on the day, with long queues and manual check-ins at Mumbai, Delhi, Bengaluru, and Hyderabad, while Akasa Air reported zero cancellations by switching to manual booking and check-in. The difference was not the trigger, the technology, or the regulation, it was the maturity of the documented procedures, the response structure, and the manual-fallback playbook. That is precisely the territory Clause 8.4 governs.

The Indian regulatory context

In India, the cost of a missing or untested Clause 8.4 plan is amplified by a layered regulatory regime in which the clock starts the moment an incident is detected, not the moment the plan is invoked:

• CERT-In Directions (No. 20(3)/2022-CERT-In, 28 April 2022) require reporting of prescribed cyber incidents, including ransomware, unauthorised access, data breach, DoS, and cloud outages, within 6 hours of noticing. The 6-hour clock is unforgiving: it presupposes that the organisation has a documented incident response procedure, a named point of contact, and a tested notification path to CERT-In. These are Clause 8.4 artefacts. An organisation that detects an incident at 23:00 and has no invocation procedure will blow the 6-hour clock before it has even decided who is in charge.
• RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices (issued 7 November 2023, effective 1 April 2024) consolidates and supersedes earlier IT/cyber guidance for scheduled commercial banks, NBFCs (asset base ≥ ₹500 crore), and All-India Financial Institutions. Its IT Service Continuity / Business Continuity Management chapters require a board-approved BCP and DR policy, documented RTO/RPO for critical systems, a Disaster Recovery Site with defined failover, periodic BCP drills including live/parallel DR drills, third-party/outsourcing continuity controls, and incident management. The RBI Cyber Security Framework in Banks (2 June 2016) additionally mandates a Cyber Crisis Management Plan (CCMP), 24x7 SOC, and incident reporting to RBI within 2–6 hours of detection. The CCMP is a Clause 8.4 artefact: it is the cyber-incident-specific response structure and procedure layered on top of the general BC plan.
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) (circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024) replaces the 2015 MII cyber framework and is structured as 5 Cyber Resilience Goals × 6 Operational Functions (Identify, Protect, Detect, Respond, Recover, Learn). The Respond and Recover functions map directly to Clause 8.4. For Market Infrastructure Institutions specifically, SEBI BCP/DR Guidelines (SEBI/HO/MRD1/DTCS/CIR/P/2021/33, 22 March 2021) require Near Site + DRS architecture, defined RTO (≤ 2 hours for critical systems) and RPO, BCP drills including live failover, geographic separation, vendor/dependency BCP, document review cadence, and board approval, all of which require documented plans and procedures to evidence.
• IRDAI Information and Cyber Security Guidelines, 2023 (24 April 2023) require insurers to maintain a board-approved Information and Cyber Security Policy including BCP/DR, a CISO, 180-day log retention (aligned with CERT-In), vulnerability assessments and penetration testing, DR drills, data locality for policyholder data, incident reporting to IRDAI and CERT-In, ICT outsourcing continuity oversight, and annual compliance reporting. The DR drills and incident reporting are Clause 8.4 evidence.
• DPDP Act 2023 (Act 22 of 2023) and the DPDP Rules, 2025 reframe availability of personal data as a statutory obligation of the Data Fiduciary. Section 8(5) imposes a duty to protect the integrity, confidentiality and availability of personal data, an explicit continuity duty. Section 8(6) requires notification of a personal-data breach to the Data Protection Board of India and to affected Data Principals; the DPDP Rules prescribe notification to the Board within 72 hours of becoming aware. Schedule penalties reach up to ₹250 crore for failure to take adequate security safeguards and up to ₹200 crore for failure to notify a breach. The breach-notification procedure is a Clause 8.4 warning-and-communication procedure.
• Disaster Management Act, 2005 and NDMA guidelines (notably the Chemical Disaster Guidelines 2007 and the Disaster Management Plan template 2014) impose statutory duties on industrial operators, including on-site and off-site emergency plans, integration of industrial plans with District Disaster Management Plans, and penalties under Sections 51–60 for non-compliance with Disaster Management authority directions during a disaster. For chemical, manufacturing, and infrastructure operators, the Clause 8.4 response structure is also a statutory emergency-plan structure.
• Companies Act 2013, Section 134(3)(n) requires the Board's Report to include a statement on the development and implementation of a risk management policy, including elements of risk that may threaten the existence of the company. Section 177 and SEBI LODR Regulation 21 require a Board-level Risk Management Committee covering cyber, operational, and continuity risks. The plans and response structure are the operational artefacts the board is accountable for.

The cost of non-compliance, with numbers

Indian regulators have shown they will escalate repeated availability and continuity failures to formal enforcement, and the financial consequences dwarf the cost of building the plans:

• HDFC Bank RBI action (2 December 2020): after repeated digital outages (November 2018, December 2019, and 21–22 November 2020, a DC power failure taking net banking and cards dark for roughly half a day), the RBI barred HDFC from new digital products and fresh credit cards, pending an external IT audit. The credit-card ban was partially lifted only around August 2021 (~8 months) and the full digital-initiatives ban only around March 2022 (~15 months). The cost was not the ₹1 crore penalty from June 2019, it was the lost growth window in India's fastest-growing digital banking segment.
• DBS/POSB (Singapore, 2023): while not an Indian case, it is the clearest regulatory-escalation precedent for repeated digital outages in Asia. After DBS's worst disruptions in a decade (including a 6.5-hour outage in May 2023 and a November 2023 PayNow failure), the MAS imposed a 6-month pause on non-essential IT changes and applied approximately a 1.8× multiplier on operational-risk capital. Indian regulators watch this precedent.
• AIIMS Delhi ransomware (23 November 2022): ransomware (suspected LockBit) hit five physical servers hosting the NIC-built e-Hospital application; primary and backup servers were both encrypted; OPD, admissions, billing, and labs reverted to paper for approximately 6–15 days. The National Investigation Agency opened a cyberterrorism probe. Media-reported ransom figures reached approximately ₹200 crore (~USD 25 million), though AIIMS and Delhi Police did not confirm. The disruption was a patient-safety event, not an IT event, and the absence of tested manual clinical procedures and offline backups turned an IT incident into a multi-week hospital-wide continuity crisis.

Why growing companies are most exposed

Growing companies, the 50–2,000-staff firms that are Singahi's audience, face a structural disadvantage on Clause 8.4 that larger enterprises do not. Three factors compound:

1. The "founder knows everything" trap. In a 200-person firm, the institutional knowledge of what to do during a disruption often lives in two or three heads. Clause 8.4 requires that knowledge to be externalised into documented procedures and a communicated response structure. The founder who "just handles it" is a single point of failure, and is often the person least available during a real crisis because they are talking to the regulator, the customers, and the board simultaneously.
2. The "we have a DR vendor" trap. Many growing companies equate having a cloud DR arrangement with having a BC plan. They do not. A DR vendor fails over servers; it does not invoke the plan, brief the regulator, switch the call centre to manual scripts, or decide which customers get priority. Those are Clause 8.4 procedures that someone has to write, train, and exercise.
3. The "regulator doesn't notice us yet" trap. CERT-In directions apply horizontally, to every entity operating ICT in India, regardless of size. DPDP applies to every Data Fiduciary. SEBI CSCRF applies to every SEBI Regulated Entity, graded by category but with no small-entity exemption from the 6-hour incident-reporting clock. A growing company that detects a ransomware incident at 02:00 has the same 6-hour clock as a Tier-1 bank, and the same need for a documented invocation and notification procedure.

The good news is that the first version of a Clause 8.4 plan set, a master BC plan, an IT DR plan, a crisis comms plan, a response structure, an invocation matrix, and a manual-workaround SOP for the top three activities, can be drafted in 10–16 weeks for a 50–250-staff firm, at an internal-plus-external cost of roughly ₹8–25 lakh. That is a small fraction of the cost of a single blown CERT-In clock or a single day of digital-banking outage. The rest of this guide shows how.

Scope and Applicability

Who Clause 8.4 applies to

Clause 8.4 applies to every organisation in scope of the BCMS, there is no size, sector, or maturity exemption. Once an organisation has defined its BCMS scope under Clause 4.3, every prioritised activity within that scope must have plans and procedures under 8.4. The depth and formality of the plan set scales with the organisation, but the obligation to have one does not.

By organisation size

Growing companies (50–250 staff): A single master BC plan, an IT DR plan, and a one-page crisis comms plan are typically sufficient as the first-cycle deliverable. The response structure can be compact, an Incident Management Team of 3–5 people (CEO/COO, IT lead, Comms lead, Operations lead) with a single deputy each. Manual workarounds should be documented for the top 3–5 prioritised activities. The most common failure mode at this size is the "founder knows everything" trap: the plan exists but is not externalised, so it fails when the founder is unavailable.

Mid-market (250–2,000 staff): The plan set should expand to a tiered hierarchy: master BC plan, IT DR plan, crisis comms plan, and departmental plans for each major function (BFSI: branch ops, treasury, cards, lending; SaaS: engineering, customer success, billing; Manufacturing: plant ops, supply chain, quality). The response structure grows to an Incident Management Team (operational response) plus a Crisis Management Team (strategic decisions, board/regulator liaison). Manual workarounds should cover the top 10–15 prioritised activities. The most common failure mode at this size is plan fragmentation: each department writes its own plan, nobody owns the master, and invocation and escalation across plans are undefined.

Enterprise (2,000+ staff): Full plan hierarchy with site-specific plans (for multi-site organisations), business-unit plans, technology-domain DR plans (per critical system or platform), and a coordinated crisis communications plan with regulator-specific notification playbooks. The response structure typically includes a Strategic/Crisis Management Team (C-suite + board liaison), a Tactical/Incident Management Team (functional leads), and Operational/Response Teams (frontline). The most common failure mode at this size is plan ossification: the plans exist but are so large and bureaucratic that nobody uses them, and the exercise programme (8.5) does not surface the usability gap because the exercises are themselves bureaucratic.

By industry

BFSI (banks, NBFCs, insurers, payment system operators, MIIs): The most heavily regulated sector for Clause 8.4. The plan set must explicitly address the RBI Master Direction IT Governance (R1) IT Service Continuity chapter, the RBI Cyber Security Framework (R2) CCMP and 2–6 hour reporting clock, the SEBI CSCRF (S1) Respond/Recover functions, the SEBI MII BCP-DR (S2) Near Site + DRS and ≤ 2-hour RTO for critical systems, and the IRDAI (I1) DR drills and incident reporting. The crisis comms plan must include regulator-notification playbooks for RBI, SEBI, IRDAI, and CERT-In, each with its own clock and format. Invocation criteria must address the difference between a "reportable incident" (regulator clock starts) and a "BC-invoking disruption" (plan invokes); the two often co-occur but are distinct decisions.

Healthcare (hospitals, pharma, medical devices, health-tech): The plan set must address patient safety as the primary continuity objective, not data, not revenue. The AIIMS Delhi 2022 ransomware is the canonical Indian failure case: primary and backup servers encrypted, e-Hospital down 6–15 days, OPD/admissions/billing/labs reverted to paper. The Clause 8.4 lesson is that clinical manual-workaround SOPs (paper-based documentation, manual prescription workflows, manual vitals monitoring) must be documented, trained, and pre-positioned, not invented during the incident. The DPDP breach-notification clock applies to PHI; the plan must include it. For pharma manufacturing, the plan must address production-line continuity and regulated-disclosure obligations (Sun Pharmaceutical's 2023 ransomware disclosure is the precedent, rare regulator-grade disclosure warning of revenue hit and litigation risk).

IT/ITeS and SaaS: The plan set must address the customer-facing SLA dimension: a SaaS firm's BC plan is also its customer-committed availability story. The crisis comms plan must include customer-notification procedures (status page, direct customer comms) in addition to regulator comms. The DPDP breach-notification clock applies to customer data processed as a processor. For IT-services firms, the plan must address the customer's BC plan dependency on the vendor's BC plan, the Wipro 2019 phishing breach (where attackers pivoted through Wipro to target its outsourcing customers) is the lesson: the vendor's incident response procedure is part of the customer's BC response.

Manufacturing (automotive, pharma, chemicals, electronics): The plan set must address OT/IT segmentation and the production-line dimension. The Maruti Suzuki Manesar violence and fire (18 July 2012), where a wage dispute led to a mob smashing the assembly line and setting fire, killing a GM-HR, with direct damage of approximately ₹10 crore and production loss of approximately ₹70–75 crore per day, totalling approximately ₹1,400 crore in lockout losses across roughly 65,000 vehicles lost, is the lesson that workplace violence and industrial-relations crises are disruption scenarios, not just fire/flood/cyber. For chemical and Major Accident Hazard (MAH) units, the NDMA Chemical Disaster Guidelines 2007 require on-site and off-site emergency plans integrated with District DMPs, the Clause 8.4 response structure is also the statutory emergency-plan structure. The LG Polymers Vizag styrene gas leak (7 May 2020, 12–13 fatalities, NGT interim penalty ₹50 crore) is the lesson that a continuity failure in a chemical plant is a mass-casualty event.

Government and Public Sector: The plan set must align with the NDMA Disaster Management Plan template (Prevention / Mitigation / Preparedness / Response / Relief / Recovery & Reconstruction / Capacity Building) and the Disaster Management Act 2005 statutory duties. For Critical Information Infrastructure operators (designated under IT Act Section 70A by NCIIPC), the plan must address CII-specific threats and the NCIIPC reporting expectations. The response structure must integrate with district/state disaster management authorities for large-scale events.

Key Definitions and Terminology

Clause 8.4 uses a specific vocabulary that auditors will expect you to use correctly. The authoritative source is ISO 22300:2021 (vocabulary); the paraphrases below are in our own words to avoid reproducing the standard's definitions verbatim.

Disruption. An event, whether anticipated (a cyclone warning, a planned strike, a scheduled migration) or unanticipated (a ransomware attack, a fire, a vendor outage, a key-person resignation), that interrupts or could interrupt the organisation's ability to deliver its products and services at the expected level. The defining feature is impact on delivery, not cause. A server crash that operations handles in 15 minutes is an incident; the same crash that takes a prioritised activity below its MBCO for an hour is a disruption. Clause 8.4 is about managing disruptions, not all incidents.

Incident. An event that could lead to disruption, or has led to disruption, and that requires a response. The boundary between "incident" and "disruption" is itself a Clause 8.4 decision, the invocation criteria define when an incident becomes a disruption that invokes the BC plan.

Invocation. The formal act of activating the BC plan (or a component of it) in response to a disruption. Invocation is a decision with authority, criteria, and a recorded timestamp, not a feeling that "things are serious." Clause 8.4.3 requires invocation procedures to be defined: who invokes, on what criteria, with what authority, and how the invocation is communicated to the response structure.

Response structure. The documented set of roles, responsibilities, and authorities for managing a disruption. Per Clause 8.4.4, the response structure must be defined, communicated, and integrated with the incident response structure. It typically includes an Incident Management Team (operational/tactical response), a Crisis Management Team (strategic decisions and external liaison), and Operational Response Teams (frontline execution). It does not have to mirror the normal management hierarchy.

Incident Management Team (IMT). The team that manages the operational response to a disruption, convening, assessing, invoking continuity strategies, coordinating recovery, and reporting to the Crisis Management Team. Typically chaired by the BCM Lead, COO, or a designated Incident Commander. The IMT is the tactical layer of the response structure.

Crisis Management Team (CMT). The team that manages the strategic dimension of a disruption, board and regulator liaison, major resource decisions, public communications authority, and the decision to invoke/stand-down the BC plan at the enterprise level. Typically chaired by the CEO or a designated Crisis Manager. The CMT is the strategic layer; it does not run the operational response.

Incident Commander (IC). The single individual with authority to direct the response to a specific incident, making operational decisions, allocating resources, and directing the IMT. The IC role is distinct from the CMT chair: the IC runs the incident; the CMT runs the organisation's strategic posture during the incident. Many organisations rotate the IC role by shift during a prolonged disruption.

Business Continuity Plan (BCP). The master plan that orchestrates the organisation's response to a disruption. It defines invocation, the response structure, communication procedures, and the procedures to continue or recover prioritised activities. The BCP is the parent document; subordinate plans (DR, crisis comms, departmental) execute its intent in their domains.

Disaster Recovery Plan (DRP). The plan that governs recovery of IT systems, networks, and data after a disruption. The DRP is the technology-domain subordinate of the BCP. It includes failover procedures, restoration procedures, and the technical runbooks for recovering specific systems to their RTO/RPO.

Crisis Communications Plan. The plan that governs communication during a disruption, internal warning, external communication (customers, regulators, media, public), and the link between them. It includes the regulator-notification playbooks (CERT-In, RBI, SEBI, IRDAI, DPDP clocks), the customer-notification procedures, and the media-holding-statement templates.

Departmental Plan. A plan owned by a department or team that executes the continuity strategy for its prioritised activities. Departmental plans are the operational layer of the plan hierarchy, they contain the specific procedures, contact lists, and workarounds that frontline teams use.

Manual workaround. A documented procedure for continuing a prioritised activity manually (on paper, by phone, by alternative system) when the normal technology-dependent process is unavailable. Manual workarounds are a Clause 8.4.3 procedure where the continuity strategy (8.3) depends on them. A workaround that is not documented, trained, and resourced is not a workaround, it is a hope.

Warning. The act of alerting people that a disruption is occurring or may occur, so they can take protective or preparatory action. Warning is distinct from communication: warning is the alert (the siren, the SMS, the page); communication is the ongoing information flow through the disruption. Clause 8.4.2 requires both.

Stand-down. The formal act of deactivating the BC response and transitioning to normal operations or to a recovery/reconstitution phase. Stand-down is a decision with authority and criteria, mirroring invocation. It is often under-documented; Clause 8.4 expects it to be defined.

RTO (Recovery Time Objective). The maximum acceptable time between the disruption of an activity and its resumption at MBCO. The BIA (8.2) sets the RTO; the plans (8.4) must deliver it. If the BIA says 4 hours and the plan's procedures take 6, the plan does not fit.

RPO (Recovery Point Objective). The maximum acceptable data loss, measured in time. The BIA sets the RPO; the DR plan's backup and failover procedures must deliver it.

MBCO (Minimum Business Continuity Objective). The minimum acceptable level of delivery for a prioritised activity during a disruption, below which the organisation cannot achieve its business continuity objectives. The BIA sets the MBCO; the plans must specify how the activity is delivered at that level, including by manual workaround if necessary.

MTPD (Maximum Tolerable Period of Disruption). The maximum time the organisation can tolerate a prioritised activity being disrupted before the consequences become unacceptable. MTPD is the ceiling; RTO must be ≤ MTPD. The terms MTPD (current ISO preference) and MAO (Maximum Acceptable Outage, BCI legacy / ISO 22301:2012) refer to the same concept; present both neutrally.

Single Point of Contact (SPOC) for CERT-In. The individual designated under CERT-In Directions as the organisation's liaison for incident reporting and coordination. The SPOC is a Clause 8.4 role, the person who carries the 6-hour clock. The plan must name the SPOC and a deputy.

Relationship to Other Clauses and Frameworks

Relationship to other ISO 22301 clauses

Clause 8.4 does not stand alone. It is the execution core of Clause 8, sitting between the strategy (8.3) and the exercises (8.5):

• Clause 4.1 / 4.2 (Context, Interested Parties): The context and stakeholder analysis shapes the plan set, which regulators, customers, suppliers, and communities the plans must address, and which disruption scenarios are plausible for this organisation.
• Clause 5.1 / 5.3 (Leadership, Roles, Authorities): Top management assigns the roles, responsibilities, and authorities that populate the response structure. The BCM Lead, the Incident Commander, the CMT chair, these are 5.3 appointments operationalised in 8.4.
• Clause 6.1 / 6.2 (Risk, Objectives): The risk register and BC objectives shape plan priorities, which scenarios the plans must cover first, and what measurable objectives (RTO/RPO/MBCO) the plans must deliver.
• Clause 7.1 (Resources): The resources (budget, people, DRS contracts, work-area recovery, mass-notification tooling) that the plans depend on must be funded under 7.1. A plan that references unfunded resources is aspirational.
• Clause 7.2 (Competence): The people named in the response structure must be competent for their roles. The BCM Lead, the Incident Commander, the DR failover team, their competence is a 7.2 obligation that 8.4 relies on.
• Clause 7.3 (Awareness): The broader workforce must be aware of the BCMS, their role in a disruption, and what happens if they don't follow BCMS requirements. Awareness is what makes the plan usable by people who are not on the IMT.
• Clause 7.4 (Communication): The communication clause, what to communicate, when, to whom, how, is the parent of the 8.4.2 warning-and-communication procedures. 7.4 sets the policy; 8.4.2 writes the playbooks.
• Clause 7.5 (Documented Information): The plans are documented information, they must be created, updated, and controlled under 7.5. Version control, approval, distribution, and retention are 7.5 obligations that apply to every plan document.
• Clause 8.1 (Operational Planning and Control): The plans are the operational artefact of 8.1, they are how the organisation plans, runs, and controls the processes needed to meet BC requirements during a disruption.
• Clause 8.2 (BIA): The BIA feeds the plans, it tells the plans which activities to cover, what RTO/RPO/MBCO to deliver, and what dependencies to account for. A plan not derived from the BIA is a plan that cannot demonstrate coverage.
• Clause 8.3 (Strategy): The chosen continuity strategy is the design the plans execute. The plans are the runbooks that operationalise the strategy, failover procedures for the chosen DRS, manual workarounds where the strategy depends on them, supplier-failover procedures where the strategy uses alternate suppliers.
• Clause 8.5 (Exercise Programme): Exercises validate that the plans work. If an exercise reveals that a plan is unusable (stale contacts, unclear procedures, missing deputy), the plan is revised under 8.4 and the corrective action logged under 10.1.
• Clause 8.6 (Evaluation of Documentation and Capabilities): Post-disruption and post-change evaluation of whether the documentation and capabilities remain suitable, adequate, and effective. The plans are the documentation being evaluated.
• Clause 9.1 (Monitoring, Measurement, Analysis, Evaluation): Plan KPIs, invocation time, RTO achievement, contact-list freshness, exercise pass rate, are monitored under 9.1.
• Clause 9.2 / 9.3 (Internal Audit, Management Review): The internal audit checks plan conformance; the management review evaluates whether the plan set remains adequate. Both feed plan revisions under 8.4.
• Clause 10.1 / 10.2 (Nonconformity, Corrective Action, Continual Improvement): Plan failures found in audits, exercises, or real incidents trigger corrective action under 10.1 and continual improvement under 10.2, which revises the plans under 8.4.

Cross-framework mapping, the headline anchors

Clause 8.4 maps cleanly to the BCM/response/recover provisions of every major framework. The detailed mapping is in Section 16; the headline anchors are:

• NIST SP 800-34 Rev 1 (May 2010): Step 5 (Develop the ISCP) ≈ Clause 8.4 plan authoring; Step 6 (Plan testing, training, exercises) ≈ 8.5; Step 7 (Plan maintenance) ≈ 8.4 + 8.6. NIST SP 800-34 is system-centric (per information system); ISO 22301 is organisation-centric (per prioritised activity), bridge both when mapping.
• NIST CSF 2.0 (26 February 2024): The Recover function, RC.RP (Incident Recovery Plan Execution), RC.CO (Recovery Communication), RC.IM (Recovery Improvement), maps to 8.4 (plans), 8.4.2 (comms), and 10.1 (improvement) respectively. The Respond function (RS) covers the incident-response dimension of 8.4.4.
• FFIEC BCM Booklet (November 2019): Structured almost as a US-banking restatement of ISO 22301 Clauses 5–8. The "plan development & implementation" and "communication/crisis management" themes map directly to 8.4.
• DORA (Regulation (EU) 2022/2554, applies 17 January 2025): Article 11 (Response and recovery), Art 11(3) requires ICT response and recovery plans; Art 11(4) requires testing; Art 11(6) requires yearly BCP testing; Art 11(7) requires a crisis management function. Article 14 requires crisis communication plans. Article 19 requires major ICT incident reporting. All map to 8.4 sub-clauses.
• APRA CPS 230 (effective 1 July 2025): Paragraph 33 requires notification to APRA within 72 hours of a material operational-risk incident. Paragraph 40 specifies BCP content (critical-ops register, triggers, actions, resources, comms). Paragraph 42 requires notification within 24 hours of any critical-operation disruption outside tolerance. These are 8.4.2 warning-and-communication obligations in regulatory form.
• MAS TRM Guidelines (18 January 2021): The Business Continuity & Disaster Recovery section governs DR drills, RTO/RPO, and incident response, all 8.4 artefacts.
• HKMA OR-2 (31 May 2022): The operational-resilience module's expectations for response, communication, and recovery map to 8.4.
• ISO/IEC 27001:2022: Annex A.5.29 (Information security during disruption), A.5.30 (ICT readiness for business continuity), A.8.13 (Information backup), A.8.14 (Redundancy of information processing facilities), the ISMS-side controls that the BCMS plans must integrate with.
• SOC 2 (TSC 2017, with 2022 Points of Focus): The Availability category, CC7.3 (security event detection), CC7.4 (security event response), CC7.5 (recovery from disruptions), maps to 8.4. SOC 2 Type II auditors will examine the BC plan and DR plan as evidence for Availability.

Detailed Implementation Guidance, The Response Structure and Plan Hierarchy

This section is the practitioner core of the guide. It walks through how to build each of the Clause 8.4 artefacts, tiered by organisation size, with worked examples in INR. The structure mirrors the order in which a growing company should build them: response structure first (because plans name people), plan hierarchy second (because the structure populates the plans), invocation third (because plans without invocation are unread books), warning and communication fourth (because the regulator clock is unforgiving), business continuity response fifth, incident response integration sixth, and maintenance last.

The response structure (Clause 8.4.4)

The response structure is the org chart for the disruption. It defines who is in charge, who does what, and who deputies for whom. It must be documented, communicated to those who need to know it, and exercised (Clause 8.5). Three design principles:

Principle 1, Separation of strategic and tactical layers. The Crisis Management Team (CMT) handles the strategic dimension: board and regulator liaison, major resource decisions, public communications authority, and the decision to invoke or stand down at the enterprise level. The Incident Management Team (IMT) handles the tactical/operational dimension: convening, assessing, invoking continuity strategies, coordinating recovery, and directing Operational Response Teams. The same person should not chair both, the CMT chair is thinking about the regulator and the share price; the IMT chair is thinking about whether to fail over the database. In a small organisation these may be the same person out of necessity, but the roles should still be documented as distinct so that a deputy can take one when the person is overloaded.

Principle 2, Named individuals with deputies and 24x7 reachability. Every role in the response structure must be held by a named individual (not a position title) with at least one named deputy. The BCM Lead is Priya Sharma; the deputy is Rahul Verma. The Incident Commander (shift 1) is Anjali Iyer; (shift 2) is Sanjay Nair. Reachability must be defined: mobile, backup mobile, home landline, and a fallback (the "if you cannot reach anyone in 15 minutes, call X" rule). The 24x7 dimension matters because disruptions do not respect business hours, the Mumbai October 2020 grid blackout hit in the morning, but the CrowdStrike outage hit Indian systems early enough that many Indian firms' first responders were not yet in the office.

Principle 3, The response structure does not have to mirror the normal org chart. In fact, it often should not. The head of Engineering may be the wrong Incident Commander for a customer-facing outage because they will instinctively focus on the technical fix rather than the customer experience. The head of Operations may be the right IMT chair for a logistics disruption even if they are not the senior person on the org chart. What matters is competence for the role, authority to decide, and clarity about who holds it.

Tiered response structures by organisation size:

For a growing company (50–250 staff), a compact structure is sufficient:

• CMT (3–4 people): CEO (chair), COO or Head of Operations, Head of Communications/Marketing, and the BCM Lead (who may be the CIO or COO in a small firm). The CMT convenes for strategic-impact disruptions, regulator-reportable incidents, customer-visible outages exceeding an agreed threshold, safety events.
• IMT (3–5 people): BCM Lead (chair) or a designated Incident Commander, IT DR Lead, Operations Lead, Communications Lead. The IMT convenes for any BC-plan invocation.
• Operational Response Teams: the frontline people who execute the procedures, the IT failover team, the customer-support manual-mode team, the facilities team. In a small firm these may be 1–2 people each.

For a growing firm (250–2,000 staff), the structure expands:

• CMT (5–8 people): CEO or designated Crisis Manager (chair), CFO, COO, CIO/CTO, CISO, Head of Communications, Head of Legal/Compliance, Head of HR. The CMT includes a board liaison (often the Company Secretary for listed firms). The CMT convenes for strategic-impact disruptions and for any disruption likely to trigger a regulator clock.
• IMT (6–10 people): BCM Lead (chair) or designated Incident Commander (rotating by shift for prolonged disruptions), IT DR Lead, Network/Infrastructure Lead, Application/Service Lead, Operations Lead, Customer-Facing Lead, Communications Lead, Facilities Lead, HR Lead. The IMT runs the operational response and reports to the CMT at agreed intervals (typically hourly during the active phase).
• Operational Response Teams: per-function teams, Database Recovery, Network Recovery, Application Recovery, Customer Support Manual-Mode, Facilities Response, Physical Security, Medical Response (for manufacturing/chemical sites).

For an enterprise (2,000+ staff), the structure adds a strategic layer above the CMT (a Board/Crisis Sub-Committee for listed firms) and operational layers below the IMT (site-specific response teams, business-unit response teams, technology-domain recovery teams). Multi-site enterprises need a clear protocol for which site's IMT leads when multiple sites are affected.

The Incident Commander role. The IC is the single individual with authority to direct the response to a specific incident. The IC role is rotated by shift for prolonged disruptions to avoid fatigue, a 36-hour incident should not have the same IC throughout. The IC's authority must be explicit: the IC can invoke continuity strategies within the pre-authorised thresholds, allocate resources, and direct the IMT. Decisions that exceed the pre-authorised thresholds (e.g., paying a ransom, publicly disclosing before the regulator clock, shutting down a revenue-generating system) escalate to the CMT. The IC does not run the strategic dimension, the CMT does. The IC runs the incident.

The BCM Lead vs the Incident Commander. These are often conflated. The BCM Lead is the role responsible for the BCMS overall, maintaining the plans, running the exercise programme, reporting to top management. The Incident Commander is the function exercised during a disruption, directing the operational response. The BCM Lead often serves as IC, but not always: in a cyber incident, the CISO or a designated Cyber Incident Commander may be the right IC, with the BCM Lead serving as coordination lead. The plan should specify who ICs which scenario class.

The plan hierarchy (Clause 8.4.1)

The plan hierarchy is the set of documented plans and how they relate. The hierarchy matters because the master plan orchestrates and the subordinate plans execute; without a clear hierarchy, plans drift into inconsistency. A typical mid-market hierarchy:

Tier 1, Master Business Continuity Plan. The parent document. It defines:

• Scope and purpose (what the plan covers, derived from the BCMS scope under 4.3)
• The response structure (the IMT, CMT, and IC roles from 8.4.4)
• Invocation and stand-down procedures (the decision matrix, authority, and communication)
• The plan hierarchy (the subordinate plans and how they relate)
• Communication procedures (high-level; the detail is in the Crisis Comms Plan)
• Recovery priorities (derived from the BIA, which activities recover in what order)
• Plan maintenance (review cadence, change-impact, version control)
• Reference annexes (contact lists, regulator clocks, system inventory)

Tier 2, Domain plans. The specialist plans that execute the master plan's intent in their domains:

• IT Disaster Recovery Plan: failover, restoration, and technical runbooks for recovering critical systems to their RTO/RPO. Includes per-system runbooks, DRS invocation procedures, data restoration procedures, and the technical contact tree.
• Crisis Communications Plan: internal warning, external communication (customers, regulators, media, public), regulator-notification playbooks (CERT-In 6 hours, RBI 2–6 hours, SEBI CSCRF, IRDAI, DPDP 72 hours), media-holding-statement templates, social-media procedures, and the communications contact tree.
• Cyber Crisis Management Plan (CCMP): for BFSI (mandated by RBI Cyber Security Framework) and recommended for any organisation with significant cyber exposure, the cyber-incident-specific response structure and procedures layered on top of the general BC plan. Includes ransomware-specific playbooks, isolation procedures, forensic-preservation procedures, and the law-enforcement liaison.
• Workplace / Site Emergency Plan: evacuation, fire, medical, violence, natural-disaster procedures for each site. For chemical/MAH sites, this is the statutory on-site emergency plan under NDMA Chemical Disaster Guidelines 2007.

Tier 3, Departmental / Team plans. The operational-layer plans that frontline teams use:

• Per-department plans for each function with prioritised activities (e.g., Branch Operations Plan, Treasury Plan, Cards Plan, Lending Plan for a bank; Engineering Plan, Customer Success Plan, Billing Plan for a SaaS firm; Plant Ops Plan, Supply Chain Plan, Quality Plan for a manufacturer).
• Each departmental plan contains: the department's prioritised activities (from the BIA), the procedures to continue or recover each, the manual workarounds, the departmental contact list, and the link to the parent plan's invocation structure.

Tier 4, System/runbook level (for IT DR). Per-system technical runbooks that the DR team executes, database failover, network failover, application restart, data restoration from backup. These are the most granular layer and the most prone to staleness because system architectures change frequently.

A worked plan-hierarchy for a 400-staff Indian SaaS firm (illustrative):

A SaaS firm with 400 staff, a single product, two data centres (Mumbai primary, Pune DRS), and ~500 enterprise customers might have:

• 1 Master BC Plan (Tier 1)
• 1 IT DR Plan (Tier 2) with 6 per-system runbooks (Tier 4): the core application, the customer database, the billing system, the analytics platform, the authentication service, the customer-support platform
• 1 Crisis Comms Plan (Tier 2) with regulator playbooks for CERT-In and DPDP
• 1 Workplace Emergency Plan (Tier 2) for the Mumbai and Pune offices
• 5 Departmental Plans (Tier 3): Engineering, Customer Success, Sales/Revenue Operations, Finance/Billing, People/HR

Total: ~14 documents. At a typical 15–25 pages for the master and domain plans and 5–10 pages for departmental plans and runbooks, that is roughly 150–250 pages of plan content, manageable for a 400-person firm, and the right scope for the first certification cycle.

The relationship between plans. The master plan must specify how the subordinate plans relate, which plan invokes which, how escalation flows between tiers, and how conflicts are resolved. The most common failure mode is "each plan is fine on its own but they don't fit together", the DR plan fails over the database, but the departmental plan's manual workaround assumes the old database is still running, and the crisis comms plan tells customers a different recovery time than the DR plan targets. The master plan's job is to reconcile these.

Invocation (Clause 8.4.3)

Invocation is the formal act of activating the BC plan. It is the most under-specified element in immature BCMSs and the most heavily scrutinised element in audits. A defensible invocation procedure has five components:

Component 1, Invocation criteria. The plan must define what triggers invocation. The cleanest approach is a tiered criteria matrix:

The criteria must be measurable, "the system is down" is not a criterion; "the core application has been unresponsive to customer requests for more than 15 minutes" is. The thresholds should derive from the BIA: a 15-minute outage matters for a payments system with a 1-hour RTO; it does not matter for an internal HR portal with a 24-hour RTO.

Component 2, Invocation authority. Who can invoke? The plan must name the roles (and ideally the individuals) authorised to invoke at each level. For Class A (life safety), any IC should be able to invoke, you do not want a 30-minute delay because the BCM Lead is in a meeting. For Class C (departmental), the department head should be able to invoke their own plan. For full BC plan invocation, the BCM Lead or a designated IC should be able to invoke, with CMT notification. The authority must include deputies for every role, with a "if you cannot reach the primary or deputy within X minutes, invoke anyway" rule.

Component 3, Invocation communication. How is the invocation communicated to the response structure? The plan must specify the channels (mass-notification platform, phone tree, SMS, email, in that order of preference for speed), the message format (the "invocation message" template, what the IC says when they convene the IMT), and the acknowledgment requirement (everyone in the response structure must acknowledge receipt within a defined window, typically 15–30 minutes). The communication must also reach people who are not in the response structure but need to know, all-hands warning for site evacuations, customer-facing notification for customer-visible outages, regulator notification for reportable incidents.

Component 4, Invocation timestamp and log. Every invocation must be timestamped and logged, the date, time, time zone, invoking authority, trigger class, and initial assessment. This is not bureaucracy; it is evidence. The CERT-In 6-hour clock starts at "notice," not at "invocation," but the invocation timestamp is what the auditor will use to reconstruct the timeline. The log is also what the post-incident review (8.6) uses to evaluate whether invocation was timely.

Component 5, Stand-down. The plan must define stand-down criteria and authority, mirroring invocation. Stand-down is not "things seem fine", it is a deliberate decision that the disruption is over and the organisation is transitioning to normal operations or to a recovery/reconstitution phase. Stand-down authority should be at the same level as invocation authority or higher. The stand-down must be communicated to the response structure (so people stop responding) and to stakeholders (so customers, regulators, and employees know the incident is closed).

The invocation decision in practice, a worked example (illustrative):

A 600-staff Indian fintech detects at 02:17 IST that its core payments platform is unresponsive. The on-call SRE acknowledges within 4 minutes; by 02:35 the on-call determines the platform is down and not auto-recovering. The on-call pages the BCM Lead (Priya Sharma) at 02:37. Priya assesses: core payments platform down, customers cannot transact, this is a Class B trigger (critical-system outage, customer-visible > 30 min likely). Priya invokes the BC plan at 02:41 IST, specifically the DR component (failover to the Pune DRS) and the comms component (customer status-page update, CERT-In assessment). She convenes the IMT for 03:00 IST. By 03:00 the IMT is on a bridge; the DR team begins failover; the comms lead posts the status-page update; the legal lead begins the CERT-In 6-hour clock assessment (is this a "cloud outage" reportable under CERT-In Directions? Yes, cloud outages are on the Annexure I list). The DRS failover completes at 04:12 IST, within the 2-hour RTO. The CERT-In notification is filed by 08:41 IST, within the 6-hour clock. The BC plan is stood down at 06:30 IST after stabilisation; the post-incident review is scheduled under 8.6.

This is what a working Clause 8.4 invocation looks like. Every timestamp, every role, every decision is documented. The plan made it possible; without the plan, the same incident would have been improvised chaos with a blown CERT-In clock.

Warning and communication (Clause 8.4.2)

Warning and communication are the procedures that keep people informed through a disruption. Warning is the alert, the act of telling people that a disruption is occurring or may occur, so they can take protective or preparatory action. Communication is the ongoing information flow, the situation reports, the status updates, the stakeholder notifications, and the stand-down announcements. Clause 8.4.2 requires both.

Internal warning. The plan must specify how employees, contractors, and site occupants are warned. Channels (in order of speed and reliability): mass-notification platform (SMS + push + email simultaneously), phone tree (manual fallback), public-address system (for site evacuations), and intranet/status page (for non-urgent updates). The warning must reach people wherever they are, office, remote, travelling, off-shift. The plan must address the "people are not at their desks" reality of hybrid work: a 2024 SaaS firm may have 40% of staff remote on any given day, and a warning that only reaches office desks misses them.

The warning message must be actionable: what is happening, what to do, where to get more information, when to expect the next update. "System down, please stand by" is not a warning; "The core payments platform is down. Customer-facing teams should switch to manual-mode scripts. Next update in 30 minutes. Status page: status." is.

External communication. The plan must specify how customers, regulators, suppliers, media, and the public are communicated with. Each audience has different needs, different clocks, and different authorised spokespeople:

• Customers: status page (for SaaS/B2B), direct customer comms (for enterprise/BFSI), in-app notifications. The comms lead must be authorised to post status-page updates within an agreed SLA (typically 15–30 minutes from detection). The holding-statement template must be pre-approved so the comms lead is not waiting for legal review while customers are in the dark.
• Regulators: the regulator-notification playbooks (see below). Each regulator has its own clock, format, and channel. The plan must specify who notifies, how, and within what window.
• Suppliers: notification of critical suppliers whose services may be affected (e.g., the cloud provider, the payment gateway, the logistics partner) and invocation of supplier-side BC arrangements.
• Media: the spokesperson (typically the CEO or Head of Communications) and the holding-statement template. Media inquiries should be routed to a single point; ad-hoc employee responses to media create legal and reputational risk.
• Public: social-media procedures, who posts, what they post, and the approval chain. The Jio 17 September 2024 incident, where Cloudflare Radar measured Jio (AS55836) traffic down up to 53% for approximately 2–3 hours after a data-centre fire, is the lesson that crisis-comms framing matters: a "minor" characterisation that contradicts a 53% traffic drop damages credibility.

Regulator-notification playbooks (the Indian clocks). This is where Clause 8.4.2 intersects most directly with Indian regulatory obligations. The plan must include a regulator-notification matrix:

The matrix must be in the plan, with the clocks, the owners, and the deputies. It must be tested, the CERT-In 6-hour clock is meaningless if the SPOC cannot log into the CERT-In portal during an incident because the credentials are in an email the SPOC cannot access when the email server is down. Pre-position the credentials, the templates, and the access paths.

Communication during degraded-channel conditions. The plan must address what happens when normal communication channels are degraded. If the email server is down (because it is part of the disrupted system), how does the comms lead communicate? Options: out-of-band email (a separate tenant), mass-notification platform (independent of corporate email), personal mobiles, and a pre-agreed "out-of-band bridge" (a conference line hosted by a third party). The plan must specify the fallback chain.

Situation reports (SITREPs). During a prolonged disruption, the IMT should issue SITREPs at agreed intervals (typically hourly during the active phase, less frequently during stabilisation). A SITREP is a structured update: what is happening, what we have done, what we are doing next, what we need, when the next SITREP is. SITREPs go up (to the CMT and board), down (to operational teams), and out (to customers and regulators as appropriate). The SITREP template must be in the plan, during a crisis is not the time to design a template.

Business continuity response (Clause 8.4.3)

The business continuity response is the set of procedures that continue or recover prioritised activities to their MBCO within their RTO. These procedures operationalise the continuity strategies chosen under Clause 8.3. Four procedure types:

Type 1, Failover procedures. Where the strategy is active-active, active-passive, or warm DRS, the plan must specify the failover procedure for each critical system: who triggers failover, the technical steps, the validation steps (how we know the failover worked), the rollback procedure (if the failover fails), and the expected time. The Tokyo Stock Exchange 1 October 2020 failure, where a memory defect in the Arrowhead trading system's shared disk caused a failure, but failover to the backup failed due to a settings problem (invalid config state), causing a full-day trading halt, is the canonical lesson: failover that is assumed but not validated under realistic conditions is not failover. The plan must require validation, and the exercise programme (8.5) must test it.

Type 2, Manual workaround procedures. Where the strategy depends on manual workarounds (paper-based transactions, manual check-in, manual order processing, manual clinical documentation), the plan must specify the workaround SOP for each prioritised activity: the trigger (when to switch to manual), the procedure (step-by-step what people do), the resources (forms, printers, manual logs, alternate systems), the people (who does what, including cross-training), the data-capture mechanism (how manual transactions are reconciled when systems return), and the stand-down (when and how to switch back). The Akasa Air 19 July 2024 case, zero flight cancellations during the CrowdStrike outage by switching to manual booking and check-in, is the canonical success case: documented manual workarounds, trained staff, clear authority to switch. The IndiGo same-day case, 283 cancellations, is the canonical failure: manual fallback existed but was not scalable to the endpoint-fleet failure mode.

Type 3, Relocation procedures. Where the strategy involves work-area recovery (relocation to an alternate site), the plan must specify: the trigger, the alternate site, the transportation, the equipment at the alternate site, the people who relocate (and those who do not), the activation procedure for the alternate site, and the duration tolerance (how long can we operate from the alternate site before we must return). The Chennai December 2015 floods, where Cognizant disclosed 11 delivery/operations centres affected, invoked BCP, relocated staff cross-city, and reaffirmed FY2015 revenue guidance of at least USD 12.41 billion, is the canonical success: work-area recovery and cross-city relocation were pre-planned and executed.

Type 4, Supplier-failover procedures. Where the strategy involves alternate suppliers (dual-sourcing, backup vendors), the plan must specify: the trigger, the alternate supplier, the activation procedure, the data/system handover, the contractual invocation (does the backup vendor need a formal purchase order?), and the duration tolerance. The Go First insolvency (filed 2 May 2023), where Pratt & Whitney PW1100G engine failures grounded approximately half the fleet, leading to 100% flight cancellations from 3 May 2023 that never resumed, is the canonical failure: single-source supply-chain concentration with no tested alternate. The Sun Pharmaceutical 2023 ransomware disclosure is the pharma-side lesson: a ransomware containment decision is a production-stoppage decision, and the supplier-failover and regulated-disclosure playbook must be pre-documented.

Incident response integration (Clause 8.4.4)

The incident response structure must be integrated with the BC response. In practice, this means three things:

1. The IR plan and the BC plan must be linked, not separate. The IT incident response process (detect, contain, eradicate, recover) and the BC response (invoke, continue, recover, stand down) are two sides of the same coin. The IR team stops the bleeding (isolates the compromised segment, removes the malware, patches the vulnerability); the BC team keeps the patient alive (invokes manual workarounds, fails over to DRS, communicates with stakeholders). The two must operate in concert, the IR team's containment decision (e.g., "we must isolate the database server") has BC consequences (the customer-facing application goes down), and the BC team's response (failover to DRS) has IR consequences (the compromised server must be forensically preserved before failover).

2. The IR structure and the BC structure must share a command chain. The Incident Commander (8.4.4) directs both the IR and the BC response, or, in larger organisations, the Cyber Incident Commander directs IR while the BCM Incident Commander directs BC, with the two coordinating through the IMT. The two structures must not operate in silos. The Change Healthcare 21 February 2024 ransomware, ALPHV/BlackCat ransomware encrypted the largest US healthcare claims/payments/pharmacy clearinghouse, with initial access via a Citrix portal lacking MFA, ~USD 22 million ransom paid, ~USD 872 million Q1 2024 direct costs rising to >USD 3 billion full-year, ~100 million individuals' PHI exposed, is the lesson: IR and BC must coordinate, or containment decisions will cascade into business decisions made blindly.

3. The IR plan must address the regulator clocks that BC also addresses. CERT-In's 6-hour clock applies to cyber incidents, the same incidents that invoke the IR plan. The IR plan and the BC plan must share the regulator-notification procedure, or the organisation will have two teams independently trying to notify CERT-In, or neither team notifying because each assumed the other did.

Manual workarounds, the depth most plans miss

Manual workarounds are the most under-developed element in most Clause 8.4 plan sets. They are also the element that most directly determines whether a disruption becomes a managed event or a public crisis. The AIIMS Delhi 2022 ransomware, where OPD, admissions, billing, and labs reverted to paper for 6–15 days, is the lesson: paper-based clinical documentation was the de facto workaround, but it was not pre-documented, not trained, not pre-positioned (forms, printers, manual log books), and not reconciled when systems returned. The result was not just an IT outage; it was a multi-week hospital-wide continuity crisis with patient-safety consequences.

A defensible manual-workaround SOP for a prioritised activity must contain:

1. Trigger criteria, when to switch to manual (e.g., "core application down > 30 minutes with no estimated recovery").
2. Decision authority, who authorises the switch (typically the department head or the IC).
3. Procedure, step-by-step what people do manually. For a hospital admissions desk: "Use the green admissions form (stock of 500 held at each desk, backup stock at the security office). Capture patient name, age, gender, UHID (from the manual register), presenting complaint, and referring doctor. File the white copy in the manual admissions folder; give the yellow copy to the patient; send the pink copy to the ward."
4. Resources, the forms, printers, manual log books, alternate systems, and physical locations. Pre-positioned, with stock levels and replenishment.
5. People, who does what, including cross-training. At least two people per role must be trained, because the person who normally does it may be affected by the same disruption.
6. Data capture and reconciliation, how manual transactions are captured for later entry when systems return. The reconciliation procedure is what prevents revenue leakage and data loss.
7. Stand-down, when and how to switch back, including the data-entry backlog plan (who enters the manual transactions, in what priority, over what window).
8. Exercise, when the workaround was last exercised (links to 8.5). A workaround that has never been exercised is unvalidated.

The cost of building manual-workaround SOPs for the top 5 prioritised activities is modest, typically 2–4 weeks of internal effort per activity, or ₹2–6 lakh per activity at consulting rates. The cost of not having them is measured in days of disruption, lost revenue, and (in healthcare) patient harm.

Plan maintenance (Clause 8.4.1 + 7.5)

Plans decay. Contact lists go stale within weeks (people change roles, leave, change phone numbers). System architectures change monthly (new servers, new cloud services, new dependencies). Regulator clocks shift (CSCRF 2024 reset SEBI clocks; DPDP Rules 2025 reset the breach-notification clock). A plan that is not maintained is a plan that will fail when invoked.

A defensible plan-maintenance procedure has five components:

1. Review cadence. Define the review cycle, typically annual for the full plan set, with quarterly contact-list refreshes. The cadence must be in the plan and tracked. A plan last reviewed 18 months ago, with a stated 12-month cycle, is a finding.

2. Change-impact process. When a change occurs (new system, new site, new regulator, new supplier, org restructuring), the plan must be assessed for impact. The change-impact process is the link between Clause 6.3 (planning changes to the BCMS) and Clause 8.4, a change under 6.3 triggers a plan review under 8.4. The process must specify who assesses impact, how, and within what window.

3. Event-triggered review. After every exercise (8.5), every real invocation, every post-incident review (8.6), and every audit nonconformity (9.2/10.1), the plan must be reviewed and revised. Event-triggered reviews are where most plan improvements come from, the scheduled annual review catches decay; the event-triggered review catches defects.

4. Version control. Every plan document must be version-controlled: version number, last-reviewed date, next-review date, approver, and change history. The version control must be under Clause 7.5 (documented information), not ad hoc. The plan that an auditor sees must be demonstrably the current version.

5. Distribution and accessibility. The plan must be distributed to those who need it and accessible during a disruption. If the plan lives only on the corporate intranet, and the intranet is part of the disrupted system, the plan is inaccessible when it is most needed. Distribute via multiple channels: intranet, offline copies on responder laptops, printed copies at each site and at the homes of the IMT/CMT members. The "plan is on the intranet" single point of failure is a common finding.

The minimum viable Clause 8.4 plan set for a growing company

For a 50–250-staff growing company building its first Clause 8.4 plan set, the minimum viable deliverable is:

1. Master BC Plan (15–25 pages), scope, response structure (IMT + CMT + deputies), invocation matrix, plan hierarchy, comms overview, recovery priorities, maintenance, annexes.
2. IT DR Plan (15–25 pages), failover procedures for the top 5–8 critical systems, per-system runbooks, DRS invocation, data restoration, technical contact tree.
3. Crisis Comms Plan (8–15 pages), internal warning, external comms, regulator-notification matrix (CERT-In + DPDP at minimum; RBI/SEBI/IRDAI if sector-regulated), holding-statement templates, SITREP template, out-of-band channel fallback.
4. Departmental Plans (3–5 plans, 5–10 pages each), per-function, covering the department's prioritised activities, procedures, manual workarounds, and contact lists.
5. Manual Workaround SOPs (for the top 3–5 prioritised activities), trigger, authority, procedure, resources, people, reconciliation, stand-down, exercise record.
6. Contact List Annex, the response structure, with names, roles, mobiles, backup mobiles, home landlines, and the "if unreachable in 15 minutes, call X" fallback.
7. Regulator-Notification Matrix Annex, the clocks, owners, deputies, formats, and pre-positioned credentials.

This minimum viable set can be drafted in 10–16 weeks for a 50–250-staff firm, at an internal-plus-external cost of approximately ₹8–25 lakh. It is sufficient to pass a certification audit at the first attempt, provided the exercise programme (8.5) validates it.

Tools, Technologies, and Solutions

Clause 8.4 is the clause where tooling matters most, and where tooling is most often mistaken for the plan itself. The plans are documents and procedures; the tools support them. An organisation can have an excellent Clause 8.4 plan set with no specialist tooling (Word documents, a spreadsheet contact list, a shared mailbox, and a phone tree), and an organisation can have expensive specialist tooling and an unusable plan set. The tooling supports the plan; it does not replace it.

Tool categories for Clause 8.4

Category 1, BCM / IRM platforms (enterprise GRC suites and growing GRC SaaS). These are the integrated platforms that host the plan documents, the response structure, the contact lists, the exercise programme, and the BIA in a single repository. They typically include BIA modules, plan-authoring modules, exercise-management modules, and incident-response modules. The enterprise end of this market is dominated by full-suite IRM platforms (configuration-heavy, high TCO, suited to 5,000+ staff enterprises with dedicated GRC teams); the mid-market end is served by GRC SaaS platforms (lighter, faster to deploy, suited to 250–2,000-staff firms). For Clause 8.4 specifically, the value of these platforms is plan version control, plan distribution, contact-list freshness monitoring, and the audit trail of plan reviews and approvals. The risk is that the platform becomes the plan, organisations invest in the tool and under-invest in the procedures the tool is meant to host.

Category 2, BCM-specialist SaaS. A narrower category of platforms purpose-built for business continuity, plan authoring, BIA, exercise management, and incident response, without the broader IRM/audit/compliance scope. These are typically simpler to deploy than full IRM suites and better suited to organisations whose primary need is BCM rather than enterprise risk. Several have a meaningful India delivery footprint through partner ecosystems.

Category 3, Crisis-notification / mass-notification platforms. These are the platforms that send the warning, simultaneous SMS, push notification, voice call, and email to the response structure and (for site-wide events) all employees. The critical capability is two-way: the platform must capture acknowledgments (who got the message, who did not) and support conference-bridge instantiation. For Indian organisations, the platform must support Indian mobile numbering, Indian SMS gateways, and the DPDP-compliant handling of contact data. This is the single highest-ROI tooling investment for Clause 8.4, a mass-notification platform can compress invocation communication from hours to minutes, and it is the tool that most directly addresses the "stale contact list" failure mode.

Category 4, Collaboration platforms (for incident command). The bridge/IM/document-share environment where the IMT and CMT convene during a disruption. Most organisations already have a collaboration platform in normal operations; the Clause 8.4 question is whether the platform is available when normal operations are disrupted. If the corporate collaboration tenant is part of the disrupted system, the IMT cannot convene. The plan must specify an out-of-band collaboration channel, a separate tenant, a third-party bridge, or a pre-provisioned alternate.

Category 5, IT DR automation / orchestration. The tooling that automates failover, restoration, and runbook execution for IT disaster recovery. This includes DR orchestration platforms (automated failover of multi-tier applications), backup-and-restoration platforms (immutable, offline, and 3-2-1-compliant backups), and infrastructure-as-code for rapid environment rebuild. These tools support the DR plan (a Clause 8.4 document); they do not replace the plan. The Code Spaces 2014 case, where an attacker systematically deleted EC2/EBS/AMIs/snapshots including offsite backups in the same AWS account because backups were in the same auth domain as production, ceasing operations within ~24 hours, is the canonical lesson: tooling without an isolated-credential, out-of-band, immutable backup strategy is a single blast radius.

Category 6, Status-page / customer-communication platforms. For SaaS and B2B firms, the status page is the customer-facing dimension of the crisis comms plan. A hosted status page (independent of the firm's own infrastructure) is more reliable than a self-hosted one during a disruption. The plan must specify who can post, the approval chain, and the holding-statement templates.

A tiered tooling strategy for growing companies

For a growing company (50–250 staff), the recommended tooling is minimal:

• Plans as version-controlled documents in a document repository (with offline copies for responders).
• A spreadsheet contact list with a quarterly refresh discipline.
• A mass-notification platform (the single highest-ROI investment, Indian-market SaaS options exist at approximately ₹1,500–4,000 per user per year).
• The existing corporate collaboration platform for incident command, with a pre-provisioned out-of-band alternate (a separate free-tier tenant).
• A hosted status page (for SaaS/B2B) at approximately ₹1,000–3,000 per month.

Total annual tooling cost for a 150-staff firm: approximately ₹3–8 lakh. This is sufficient for Clause 8.4 conformance and for a credible first certification cycle.

For a growing firm (250–2,000 staff), add:

• A growing GRC SaaS or BCM-specialist SaaS for plan hosting, version control, and exercise management (approximately ₹4,000–10,000 per fulfiller per year; total annual cost ₹6–25 lakh depending on user count).
• Mass-notification platform with two-way acknowledgment and conference-bridge instantiation (scaled user count; ₹6–18 lakh annually).
• DR orchestration for the top critical systems (cost varies widely by architecture; ₹10–40 lakh for a mid-tier solution).

For an enterprise (2,000+ staff), add full-suite IRM, dedicated crisis-management tooling, and enterprise DR orchestration, but the tooling decision should follow the plan-architecture decision, not precede it.

Tooling pitfalls

Three pitfalls recur in Clause 8.4 tooling decisions:

1. Buying the tool before designing the plan. The plan architecture determines the tooling requirements, not the reverse. Organisations that buy a BCM platform and then try to fit their plans into the platform's template often end up with a plan that serves the platform rather than the organisation.
2. Assuming the tool will be available during the disruption. If the BCM platform is hosted in the same cloud region as the disrupted system, it is not available when invoked. The plan must specify out-of-band access to the plan documents and the notification platform.
3. Under-investing in the human dimension. Tooling does not train people, does not exercise the response structure, and does not write the manual-workaround SOPs. The highest-ROI Clause 8.4 investments are the ones that build human capability, the response structure, the training, the exercises, not the ones that build tooling.

Policy and Procedure Templates

Clause 8.4 requires documented plans and procedures. This section provides the skeleton structures that a growing company can adapt. The full ready-to-customise templates are in the toolkit (Section 19); this section gives the architecture and a sample of the content.

Master Business Continuity Plan, skeleton structure

1. Purpose and scope, what the plan covers, derived from the BCMS scope (Clause 4.3). Reference the BIA (8.2) and the continuity strategy (8.3) as the plan's foundation.
2. Plan hierarchy, the list of subordinate plans (DR, crisis comms, departmental, manual workaround SOPs) and how they relate.
3. Response structure, the IMT, CMT, and IC roles (Clause 8.4.4), with named individuals, deputies, and 24x7 reachability. Include the org chart for the disruption.
4. Invocation, the invocation criteria matrix (Class A/B/C/D), the invocation authority, the invocation communication procedure, the timestamp/log requirement, and the stand-down procedure.
5. Warning and communication, high-level; reference the Crisis Comms Plan for detail. Include the internal warning procedure, the external communication procedure, and the regulator-notification matrix.
6. Business continuity response, the recovery priorities (derived from the BIA), the procedure types (failover, manual workaround, relocation, supplier failover), and the link to the DR plan and departmental plans.
7. Incident response integration, the link between the IR plan and the BC plan; the shared command chain; the regulator-clock ownership.
8. Plan maintenance, review cadence, change-impact process, event-triggered review, version control, distribution.
9. Annexes, contact list, regulator-notification matrix, system inventory, site inventory, manual-workaround SOP index.

Crisis Communications Plan, skeleton structure

1. Purpose and scope.
2. Communication principles, accuracy, speed, single source of truth, authorised spokespeople.
3. Internal warning procedure, channels, message template, acknowledgment requirement, escalation.
4. External communication procedure, customer, regulator, supplier, media, public, with the spokesperson and approval chain for each.
5. Regulator-notification matrix, the Indian clocks (CERT-In 6 hours, RBI 2–6 hours, SEBI 6 hours, IRDAI, DPDP 72 hours) with owners, deputies, formats, and pre-positioned credentials.
6. Holding-statement templates, pre-approved for the top scenario classes (cyber incident, system outage, data breach, natural disaster, site emergency).
7. SITREP template, what is happening, what we have done, what we are doing next, what we need, next SITREP time.
8. Out-of-band channel fallback, the alternate email, bridge, and notification channel if the primary is down.
9. Social-media procedure, who posts, approval chain, monitoring for misinformation.
10. Stand-down communication, the closure message to each audience.

Sample manual-workaround SOP, admissions desk (healthcare, illustrative)

Activity: Hospital admissions (prioritised activity, RTO 1 hour, MBCO 100% of emergency admissions, 60% of elective).

Trigger: e-Hospital application down > 30 minutes with no estimated recovery, OR e-Hospital down and suspected cyber incident.

Decision authority: Duty Medical Officer (deputy: Matron).

Procedure:

1. DMO announces "manual admissions mode" over the PA and by SMS to all ward sisters and the registration desk.
2. Registration desk switches to the green admissions form (stock of 500 held at each desk; backup stock of 2,000 at the security office).
3. Capture: patient name, age, gender, UHID (from the manual register, the register is held at the registration desk and backed up at the medical records room), presenting complaint, referring doctor, admission ward.
4. File the white copy in the manual admissions folder (held at the registration desk); give the yellow copy to the patient; send the pink copy to the ward with the patient.
5. Ward sister enters the admission in the ward's manual log (stock of 100 log books per ward).
6. Billing is deferred; no patient is turned away for inability to pay during manual mode.
7. Pharmacy dispenses against the manual prescription (doctor's prescription pad, signed; pharmacy logs manually).

Resources: green admissions forms (5,000 stock, replenished quarterly), manual UHID register (2 copies), ward log books (100 per ward), prescription pads (stock at each nursing station), battery-powered printers (2 per registration desk, charged).

People: registration desk staff (4 per shift, cross-trained), ward sisters (cross-trained on manual log), DMO (authorises and oversees).

Data capture and reconciliation: all manual admissions are entered into e-Hospital by the data-entry team (5 people, dedicated during the reconciliation window) within 48 hours of system restoration, in priority order (emergency admissions first, then elective). The manual UHID register is the reconciliation source.

Stand-down: DMO announces "system restored, manual mode ending" over PA and SMS. Registration desk continues manual mode for 1 hour after restoration to allow e-Hospital stabilisation, then switches back. Data-entry team begins the reconciliation backlog.

Exercise record: last exercised 14 March 2026 (tabletop); next exercise scheduled September 2026 (simulation with live manual-mode for 2 hours).

Sample policy "shall" clauses (organisation-drafted, not standard text)

The following are sample policy clauses an organisation might draft for its own BC policy. They use "shall" language because they are the organisation's own policy commitments, not the standard's text:

• "The organisation shall maintain a documented Business Continuity Plan that defines the response structure, invocation procedures, and recovery priorities for all prioritised activities identified in the BIA."
• "The Incident Management Team shall be convened within 30 minutes of BC plan invocation, and the Crisis Management Team within 60 minutes, for all Class A and Class B disruptions."
• "The CERT-In Single Point of Contact shall report prescribed cyber incidents to CERT-In within 6 hours of noticing, in accordance with the CERT-In Directions dated 28 April 2022."
• "All plans shall be reviewed at least annually, and within 30 days of any significant change to the organisation's operations, systems, suppliers, or regulatory environment."
• "Manual workaround procedures shall be exercised at least annually for each prioritised activity where the continuity strategy depends on a manual workaround."

These are the organisation's own commitments; only the ISO 22301 clause text itself is paraphrased.

Risk Assessment and Treatment

Clause 8.4 does not require a separate risk assessment, that is Clause 6.1 and 8.2. But the plans must address the risks identified in those assessments, and the plans themselves introduce risks (plan-usability risk, contact-list-staleness risk, single-point-of-failure-in-the-response-structure risk) that must be treated.

Plan-related risk register entries

A Clause 8.4-aware risk register includes entries such as:

Treatment priorities

The highest-priority treatments for most growing companies are:

1. The contact-list and invocation-card drill (the quick win from Section 1), fix the stale-contact-list risk in 2 weeks for under ₹1 lakh.
2. Manual-workaround exercise for the top 3 prioritised activities, fix the untrained-workaround risk in 4–6 weeks for ₹2–6 lakh per activity.
3. Mass-notification platform deployment, fix the invocation-communication risk in 4–8 weeks for ₹3–8 lakh annual.
4. Regulator-notification drill, fix the missed-clock risk in 2–3 weeks for under ₹1 lakh.
5. Annual live DR failover test, fix the untested-failover risk in 8–12 weeks for ₹5–15 lakh (depending on architecture).

These five treatments, completed in the first 6 months, address the failure modes that cause most real-world Clause 8.4 failures.

Audit and Compliance Checklist

The following 28 questions cover what a certification auditor (from BSI Group, DNV, SGS, TÜV, Bureau Veritas, Intertek, TQCS, NQA, or another accredited body) will examine. Each question lists the expected evidence and the red flag that would trigger a finding.

Response structure (8.4.4)

1. Is the incident response structure documented? Expected: a response-structure chart (IMT, CMT, IC roles) with named individuals and deputies. Red flag: the structure is described in prose but no chart exists, or the chart shows positions but no names.
2. Do the people named in the response structure know they are named? Expected: signed acknowledgement or training records. Red flag: a sampled role-holder says "I did not know I was the deputy IC", an immediate finding.
3. Is 24x7 reachability defined for every role? Expected: mobile, backup mobile, home landline, and a fallback "if unreachable in 15 minutes, call X" rule. Red flag: only a desk phone and an email are listed.
4. Are deputies designated for every role, including the BCM Lead? Expected: named deputy for every primary. Red flag: the BCM Lead has no deputy, or the deputy is the same person for multiple primaries (creating a new single point of failure).
5. Is the response structure communicated to those who need to know it? Expected: distribution list, awareness training, intranet posting. Red flag: the structure exists in the BCM Lead's laptop but has not been shared.

Plan hierarchy (8.4.1)

6. Does a documented Business Continuity Plan exist? Expected: the master BC plan, version-controlled, approved. Red flag: no master plan, or a plan that is a collection of fragments with no parent document.
7. Does the plan set cover the prioritised activities from the BIA? Expected: cross-reference matrix (BIA activity → plan that covers it). Red flag: the BIA lists 20 prioritised activities; the plans cover 8.
8. Does an IT Disaster Recovery Plan exist for critical systems? Expected: DR plan with per-system runbooks for critical systems. Red flag: a "DR plan" that is a 2-page overview with no per-system procedures.
9. Does a Crisis Communications Plan exist? Expected: comms plan with regulator-notification matrix, holding-statement templates, SITREP template. Red flag: no comms plan, or a comms plan with no regulator clocks.
10. Do departmental plans exist for departments with prioritised activities? Expected: per-department plans linked to the master. Red flag: a single monolithic plan with no departmental layer, or departmental plans that are not linked to the master.
11. Are the plans derived from the BIA and continuity strategy? Expected: traceability (BIA RTO → plan procedure that delivers it; strategy → plan that executes it). Red flag: the BIA says 2-hour RTO; the plan's procedure takes 6 hours; nobody noticed.

Invocation (8.4.3)

12. Are invocation criteria defined? Expected: invocation matrix (trigger class, level, authority). Red flag: "the BCM Lead decides" with no criteria.
13. Is invocation authority defined with deputies? Expected: named authorities per invocation level. Red flag: only one person can invoke, with no deputy.
14. Is the invocation communication procedure defined? Expected: channels, message template, acknowledgment requirement. Red flag: "we will call people" with no list, no template, no acknowledgment.
15. Is invocation timestamped and logged? Expected: invocation log (date, time, time zone, authority, trigger). Red flag: no log exists, or the log is reconstructed after the fact.
16. Are stand-down criteria and authority defined? Expected: stand-down procedure mirroring invocation. Red flag: stand-down is ad hoc; people "drift away" from the response.

Warning and communication (8.4.2)

17. Is the internal warning procedure defined? Expected: channels (mass-notification, phone tree, PA), message template, acknowledgment. Red flag: "we will send an email", email is not a warning channel for off-hours disruptions.
18. Is the external communication procedure defined for each audience? Expected: customer, regulator, supplier, media, public, with spokesperson and approval chain. Red flag: no spokesperson designated; any employee can talk to media.
19. Does the regulator-notification matrix include the applicable Indian clocks? Expected: CERT-In 6 hours, RBI 2–6 hours (if BFSI), SEBI 6 hours (if MII/RE), IRDAI (if insurer), DPDP 72 hours (if personal-data breach). Red flag: missing clocks, or clocks with the wrong timeframes.
20. Is the CERT-In SPOC designated with a deputy? Expected: named SPOC and deputy, with pre-positioned portal credentials. Red flag: SPOC is a position title, not a named person; or the credentials are in an email the SPOC cannot access when email is down.
21. Are out-of-band communication channels defined? Expected: alternate email tenant, third-party bridge, mass-notification platform independent of corporate IT. Red flag: all channels depend on the corporate email server.
22. Are holding-statement templates pre-approved? Expected: templates for the top scenario classes, pre-approved by Legal. Red flag: the comms lead must wait for legal review during the incident.

Business continuity response (8.4.3)

23. Are manual workarounds documented where the strategy depends on them? Expected: workaround SOPs with trigger, authority, procedure, resources, people, reconciliation, stand-down, exercise record. Red flag: the strategy says "manual workaround for 2 hours" but no SOP exists.
24. Have manual workarounds been exercised? Expected: exercise records (links to 8.5). Red flag: a workaround that has never been exercised is treated as a procedure.
25. Are failover procedures documented for critical systems? Expected: per-system failover runbooks with validation steps. Red flag: "fail over to DRS" with no procedure, no validation, no rollback.

Maintenance (8.4.1 + 7.5)

26. Is the plan review cadence defined and tracked? Expected: review schedule (annual full review, quarterly contact-list refresh) with last-reviewed and next-review dates. Red flag: plan last reviewed 18 months ago.
27. Is there a change-impact process linking changes to plan review? Expected: change-impact assessment within 30 days of significant changes. Red flag: system architecture changed but the plan still references the old architecture.
28. Are plans version-controlled and distributed? Expected: version numbers, change history, distribution list, offline copies. Red flag: no version control, or the plan exists only on the intranet.

Metrics and KPIs

Clause 8.4 effectiveness is measured by both process KPIs (is the plan being maintained?) and outcome KPIs (does the plan work when invoked?). The following 14 KPIs cover both dimensions. Targets are illustrative for a growing firm; adjust to your BIA-derived tolerances.

Process KPIs

Outcome KPIs

Leading indicators vs lagging indicators

The process KPIs (1–8) are leading indicators, they predict whether the plan will work when invoked. The outcome KPIs (9–14) are lagging indicators, they measure whether the plan worked. A mature BCMS monitors both: leading indicators catch decay before it causes a failure; lagging indicators catch failures and feed corrective action (10.1). An organisation that monitors only lagging indicators is managing by hindsight.

Dashboard sample

A Clause 8.4 dashboard for the BCM steering committee might display:

• A traffic-light view of the 8 leading indicators (green/amber/red against target).
• The last quarter's invocation/exercise outcomes (RTO/RPO achievement, convene times, clock adherence).
• The top 5 plan-related risks (from the risk register) and their treatment status.
• The next 3 planned exercises and the plans they will validate.
• The corrective-action log (10.1) items open against Clause 8.4, with ageing.

Common Pitfalls and Audit Failures

The following anti-patterns are the most common Clause 8.4 failure modes encountered in audits and real invocations. Each is named for memorability.

"The PDF nobody opened since the last audit"

The plan exists, is version-controlled, and was approved, but it has not been opened, reviewed, or exercised since the last audit. The contact list is 14 months stale. The system architecture section references servers that were decommissioned 8 months ago. The manual-workaround SOP references forms that are no longer stocked. The plan is a document; it is not a capability. Auditors find this by checking the version history and the review log, and by sampling the contact list (phoning 5 names). Treatment: the quarterly contact-list refresh and the change-impact process (Section 7.8).

"The BCM Lead decides"

The invocation section says "the BCM Lead will decide whether to invoke", with no criteria, no thresholds, no deputy, and no test of whether the BCM Lead is reachable at 02:00 on a Sunday. This is the most common invocation finding. Treatment: the invocation criteria matrix (Section 7.3) with named authorities, deputies, and the "if unreachable in 15 minutes, invoke anyway" rule.

"We have a DR vendor"

The organisation equates having a cloud DR arrangement with having a BC plan. The DR vendor fails over servers; nobody invokes the plan, briefs the regulator, switches the call centre to manual scripts, or decides which customers get priority. The DR vendor is a technology component of the strategy (8.3); it is not a Clause 8.4 plan. Treatment: build the plan around the DR vendor's failover, not in place of it.

"The plan is on the intranet"

The plan exists only on the corporate intranet. During a disruption that takes the intranet down (a ransomware attack, a network outage), the plan is inaccessible. The responders cannot find the contact list, the invocation matrix, or the manual-workaround SOPs. Treatment: offline copies on responder laptops, printed copies at sites and responder homes, out-of-band access to the plan repository.

"Manual workaround: see strategy document"

The continuity strategy (8.3) says "manual workaround for the first 2 hours," but no SOP exists. When the disruption hits, the operations team invents the workaround on the fly, paper forms are improvised, the reconciliation procedure does not exist, and the data-entry backlog after restoration takes weeks. Treatment: the manual-workaround SOP (Section 7.7) with all 8 components, exercised annually.

"The failover we never tested"

The DR plan describes a failover to the DRS. The DRS exists, the contract is paid, the runbook is documented, but the failover has never been exercised. During a real disruption, the failover fails because of config drift (the TSE 2020 lesson), stale DNS, un-synchronised data, or a dependency the runbook does not account for. Treatment: annual live failover test (Clause 8.5), with config-drift monitoring between tests.

"Two plans, two recovery times"

The DR plan says the database will fail over in 1 hour. The crisis comms plan tells customers the system will be back in 4 hours. The departmental plan's manual workaround assumes the old database is still running. The three plans were written by three teams who never reconciled. During the disruption, the comms lead tells customers 4 hours, the DR team delivers in 1, and the operations team is still running manual workarounds at hour 3 because nobody told them the database was back. Treatment: the master plan's job is to reconcile (Section 7.2); the cross-plan consistency review is a mandatory part of plan maintenance.

"The regulator clock we did not know about"

The plan addresses CERT-In but not DPDP. Or it addresses RBI but not SEBI (for a firm that is both a bank and an MII participant). Or it addresses the Indian clocks but not the DORA clock (for a firm serving EU financial clients). The regulator clock is missed; the penalty follows. Treatment: the regulator-notification matrix (Section 7.4) must list every applicable clock, with the owner and deputy for each.

"The exercise that validated the plan we already knew was fine"

The exercise programme (8.5) tests the easy scenarios, a planned DRS failover during business hours, a tabletop of a familiar scenario. The hard scenarios, a ransomware attack at 02:00 on a Sunday, a key-person unavailability, a simultaneous primary and DRS failure, a supplier cascading failure, are never exercised. The plan "passes" the exercise but fails when a hard scenario hits. Treatment: the exercise programme must include severe-but-plausible scenarios (Clause 8.5), not just the convenient ones.

"The IC who is also the CIO who is also the spokesperson who is also the BCM Lead"

In a small organisation, one person holds every response-structure role. When a disruption hits, that person is simultaneously running the incident, briefing the regulator, talking to the media, and deciding the strategic posture, and cannot do any of them well. Treatment: separate the roles even in a small organisation (Section 7.1); the IC runs the incident, the CMT chair runs the strategy, the spokesperson talks to media, and the BCM Lead coordinates.

"The post-incident review whose lessons were never incorporated"

The disruption is handled (more or less). The post-incident review (8.6) identifies 12 lessons. None of them are incorporated into the plan. The next disruption hits; the same 12 lessons are relearned. Treatment: the corrective-action log (10.1) must track every post-incident lesson to plan revision, with an owner and a due date.

"The plan that serves the auditor, not the organisation"

The plan is written to pass the audit, it uses ISO 22301 vocabulary, it has all the right section headings, it cross-references every clause. But it is unusable during a disruption, the procedures are abstract, the contact list is buried in an annex, the invocation matrix is a 2-page table that nobody can read under pressure. The plan passes the audit and fails the real world. Treatment: write the plan for the responder first and the auditor second. The responder needs a clear, scannable, actionable document; the auditor needs the traceability and the version control. Both can be served, but the responder comes first.

Illustrative Scenario 1: Failure, IndiGo and the CrowdStrike Endpoint Cascade

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

ISO 22301:2019 Clause 8.4 asks organizations to implement and maintain a response structure and documented plans and procedures to manage the organization through a disruption.

The trigger

On 19 July 2024, a faulty content-configuration update to a widely deployed endpoint security agent (CrowdStrike Falcon) triggered a logic error that crashed Windows hosts globally, a blue-screen-of-death boot loop affecting approximately 8.5 million Windows devices worldwide (Microsoft estimate). The update window was approximately 78 minutes; recovery took days because remediation required per-host manual or PXE-based intervention (booting into Windows Safe Mode and deleting the offending driver file). This was not a cyberattack; it was a defective content update from a trusted vendor whose agent operated at kernel level. Parametrix estimated direct Fortune 500 losses at approximately USD 5.4 billion, with only 10–20% insured.

The Indian aviation impact

The outage hit Indian aviation systems in the early-morning IST window. IndiGo, India's largest airline by domestic market share, saw its check-in, booking, and airport systems, heavily dependent on Windows endpoints, go down across major airports. The Hindu reported that IndiGo cancelled approximately 283 flights on 19 July 2024. Long queues formed at Mumbai, Delhi, Bengaluru, and Hyderabad airports; passengers faced manual check-in attempts that could not scale to the volume; social media filled with complaints about lack of information. The disruption cascaded into the next day as crews and aircraft were out of position.

The Clause 8.4 failure modes

The publicly observable outcome, 283 cancellations against a competitor's zero, points to several Clause 8.4 failure modes that are common across Indian growing companies:

Failure mode 1, Manual fallback not scalable to the failure mode. IndiGo had manual check-in procedures (every airline does, they are used during system glitches). But those procedures were designed for short-duration, partial-system glitches: a handful of counters go manual for 30 minutes while IT reboots. They were not designed for a complete, sustained, fleet-wide endpoint failure where every check-in counter is down simultaneously for hours. The manual workaround SOP (8.4.3) either did not contemplate this failure mode, or did not have the staffing, the forms, or the airport-side coordination to scale. The result was that the manual workaround existed but could not absorb the load, and cancellations became the only option.

Failure mode 2, Endpoint-fleet recovery not in the DR plan. The DR plan (8.4.1) presumably covered data-centre failures, network failures, and application failures. But the CrowdStrike incident was an endpoint failure, the servers were fine, the network was fine, the applications were fine; the Windows endpoints that staff used to access the systems were bricked. DR plans that focus on the data centre and ignore the endpoint fleet are common, because endpoint recovery is operationally harder (thousands of devices, distributed locations, per-host remediation) and less glamorous than a DRS failover. The lesson is that the BIA (8.2) must identify endpoints as a dependency for prioritised activities, and the DR plan (8.4) must include endpoint-fleet recovery procedures, including pre-staged PXE boot images, a tested batch-remediation script, and the staffing to execute it across airports.

Failure mode 3, Vendor update channel not validated. The endpoint agent that caused the outage was a trusted vendor whose updates were auto-deployed. The BIA and risk assessment (8.2) should have identified this auto-update channel as a dependency and a risk; the continuity strategy (8.3) should have included a canary-deployment or staged-rollout control (so a defective update hits a small fraction of endpoints first, not the whole fleet); and the DR plan (8.4) should have included a rapid-rollback procedure for endpoint agent updates. None of these are exotic controls, they are standard in mature endpoint-management programmes, but they require the BIA to treat the endpoint agent as a tier-1 dependency, which most aviation (and most Indian SaaS) BIAs do not.

Failure mode 4, Crisis comms under volume. The public reporting suggests the customer-communication dimension was overwhelmed, passengers reported lack of information at airports and on social media. The crisis comms plan (8.4.2) must contemplate high-volume customer-communication scenarios: the status page must handle traffic spikes, the social-media team must have pre-approved holding statements for a "complete system outage" scenario, and the airport staff must have scripted talking points. A comms plan designed for a "minor glitch" tone cannot scale to a "283-cancellation day" reality.

The cost

IndiGo did not publicly disclose the financial impact of the 19 July 2024 outage specifically. For context, the Akasa Air pilot-exodus crisis of 2023 was reported at approximately ₹3 crore per day in losses at peak; a 283-cancellation day for IndiGo (a larger carrier) would plausibly be in the ₹5–15 crore range in direct and indirect costs, plus reputational impact that is harder to quantify. The CrowdStrike outage's global Fortune 500 impact was estimated at approximately USD 44 million per firm on average (Parametrix), a figure that, while not directly transferable to IndiGo, indicates the order of magnitude.

Lessons for Clause 8.4

1. Manual workarounds must be designed for the failure mode, not just for "system down." A workaround that works for a 30-minute glitch will not work for a 6-hour fleet-wide endpoint failure. The workaround SOP (8.4.3) must specify the scale at which it can operate and the trigger for switching to a degraded-service mode (reduced schedule, manual boarding, deferred billing) rather than full manual operation.
2. The DR plan must cover the endpoint fleet, not just the data centre. Endpoint-fleet recovery, PXE boot images, batch-remediation scripts, per-host recovery staffing, is a DR plan component that the BIA must drive.
3. Vendor auto-update channels are BC dependencies. The BIA must identify them; the strategy (8.3) must include staged-rollout controls; the DR plan (8.4) must include rapid-rollback procedures.
4. Crisis comms must scale to high-volume scenarios. The comms plan (8.4.2) must contemplate a "complete system outage" scenario, not just minor glitches, with pre-approved holding statements and a status page that can handle traffic spikes.
5. The contrast with Akasa (next section) proves this was not about the trigger. The same CrowdStrike update hit both airlines. The difference was the maturity of the documented procedures, the response structure, and the manual-fallback playbook, precisely the territory Clause 8.4 governs.

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

Illustrative scenario. This narrative is reconstructed from publicly reported facts (Reuters, LiveMint, and other Tier-1 sources) for instructive purposes. It is labelled illustrative because the internal BC decisions of the organisation are not publicly documented; the analysis reflects what is publicly known plus reasonable practitioner inference.

The same trigger, the opposite outcome

Akasa Air, a newer and smaller Indian airline, was hit by the same CrowdStrike Falcon content-configuration update on 19 July 2024. Its Windows endpoints, used for check-in, booking, and airport operations, were affected by the same boot-loop. Yet Akasa reported zero flight cancellations on the day, switching to manual booking and check-in. The contrast with IndiGo's 283 cancellations is the sharpest possible illustration of Clause 8.4 maturity: same trigger, same industry, same country, same day, opposite outcomes, determined entirely by the documented procedures and the response structure.

What the success looks like under the hood

The publicly observable outcome, zero cancellations, points to a Clause 8.4 plan set that had several attributes mature organisations build deliberately:

Attribute 1, A documented manual-fallback playbook that was scalable. Akasa's manual booking and check-in procedures were able to absorb the full load of the day's flights, not just a subset. This implies that the manual-workaround SOP (8.4.3) was designed for sustained full-load manual operation, with the forms, the staffing, and the airport-side coordination to match. A workaround that scales to full load is a different artefact from a workaround that covers a short glitch; it requires more pre-positioned forms, more trained staff, and a longer tolerance for deferred data entry.

Attribute 2, A response structure that could invoke and execute quickly. Switching an entire airline to manual operations on the morning of a disruption requires a fast invocation decision, a clear authority, and a response structure that can execute. This implies the invocation matrix (8.4.3) had a clear trigger for "complete endpoint failure," a designated authority who could invoke the manual-fallback playbook without escalation delays, and an IMT that could convene and direct the switchover.

Attribute 3, Staff trained on the manual workaround. Manual booking and check-in is a skill, it requires staff to know the forms, the manual boarding process, the manual baggage reconciliation, and the deferred-billing procedure. Akasa's ability to execute on the day implies that staff had been trained on the manual workaround (Clause 7.2 competence) and ideally exercised it (Clause 8.5). A workaround that staff have never practised is not a workaround; it is a procedure that will fail when invoked.

Attribute 4, A crisis comms dimension that did not become the story. Akasa did not generate the social-media volume that IndiGo did, partly because it was not cancelling flights and partly because its communications were presumably proportionate to the actual customer impact. The comms plan (8.4.2) supported the operational response rather than becoming a separate crisis.

Why a smaller airline outperformed a larger one

The counterintuitive element of this contrast is that Akasa, a smaller, newer airline, outperformed IndiGo, a larger and more established carrier. This is instructive for growing companies specifically. Three factors likely contributed:

1. Less legacy complexity. Akasa's newer systems may have had a smaller endpoint fleet, fewer legacy applications, and a simpler airport-systems footprint, making the manual workaround more tractable. Growing companies often have an advantage here: less legacy means less to manually work around.
2. A plan set built recently. As a newer airline, Akasa's BC plans were likely built recently, with current regulator expectations (CSCRF, DPDP) and current threat scenarios (endpoint-fleet failure, ransomware, vendor outage) in mind. Older plan sets often reflect the threats of the era they were written in, physical disaster, data-centre failure, mainframe outage, and have not been refreshed for the endpoint-and-vendor-dependency threats of the 2020s.
3. A culture of executing the plan. The decision to switch to manual and continue operations, rather than to cancel and wait for IT, is a cultural decision as much as a procedural one. It requires a leadership that has internalised "the plan exists; we will use it" rather than "the plan exists; let us see if IT fixes it first." This cultural attribute is what the exercise programme (8.5) builds: organisations that exercise their plans develop the confidence to invoke them.

The ROI

Akasa did not publicly disclose the financial impact of avoiding cancellations on 19 July 2024. The ROI can be estimated by contrast:

• Avoided direct losses: if Akasa would otherwise have cancelled a comparable proportion of its schedule (it operates fewer flights than IndiGo, so the absolute number would be lower, but the per-flight economics are similar), the avoided direct losses for the day are plausibly in the ₹1–5 crore range, depending on load factors and route mix.
• Avoided reputational damage: the contrast coverage ("Akasa zero cancellations vs IndiGo 283") generated positive brand exposure that would be expensive to buy through marketing. For a newer airline building market share, this reputational lift is material.
• Avoided customer-acquisition cost: passengers who were rebooked or delayed on IndiGo and who chose Akasa for their next trip represent a customer-acquisition windfall. Even a small shift in repeat-purchase behaviour, say, 0.5% of affected IndiGo passengers trying Akasa next time, translates to revenue that dwarfs the cost of the plan set.

The cost of the Clause 8.4 plan set that enabled this outcome, the manual-fallback playbook, the response structure, the training, the exercises, is modest. For an airline of Akasa's size, a credible estimate is ₹50 lakh–₹2 crore annually for the BCM programme (people, tooling, exercises, consulting) that produced the plans. The avoided losses on a single day, 19 July 2024, plausibly exceeded the annual BCM programme cost. That is the ROI of Clause 8.4 done well: it pays for itself in the first disruption it manages.

Lessons for Clause 8.4

1. The manual workaround is the single highest-ROI Clause 8.4 artefact. It is what separates "managed event" from "public crisis" for the most common disruption classes (system outage, endpoint failure, vendor outage). Investing in scalable, trained, exercised manual workarounds for the top prioritised activities is the most cost-effective Clause 8.4 work a growing company can do.
2. Plan recency matters. A plan set built for 2020s threats (endpoint failure, vendor outage, ransomware, cloud outage) outperforms a plan set built for 2010s threats (data-centre failure, natural disaster). The plan refresh cadence (8.4.1 maintenance) must include scenario refresh, not just contact-list refresh.
3. Culture is built by exercise. The confidence to invoke the plan and switch to manual, rather than wait for IT, is built in the exercise programme (8.5). Organisations that do not exercise their plans do not develop this confidence; they improvise, and improvisation under pressure produces 283-cancellation days.
4. Smaller can be more resilient. Growing companies often assume they are more vulnerable to disruption than larger firms. The Akasa-IndiGo contrast shows the opposite can be true: less legacy, recent plans, and a culture of execution can make a smaller organisation more resilient than a larger one. Clause 8.4 is where growing companies can build a genuine resilience advantage.
5. The trigger does not determine the outcome; the plan does. The same CrowdStrike update hit both airlines. The trigger was identical; the outcomes were opposite. The difference was the Clause 8.4 plan set, the documented procedures, the response structure, the manual workarounds, and the exercise programme that built the confidence to use them. This is the central lesson of Clause 8.4: the disruption is not the determinant of the outcome; the plan is.

Multi-Framework Mapping

Clause 8.4 maps cleanly to the BCM/response/recover provisions of every major framework. This section provides the detailed cross-reference with real control numbers. Use it to satisfy auditors mapping your BCMS to multiple frameworks (common for Indian firms that hold ISO 27001 + ISO 22301 + SOC 2 + sector-specific certifications simultaneously).

ISO 22301:2019 Clause 8.4 ↔ ISO/IEC 27001:2022

ISO 22301:2019 Clause 8.4 ↔ NIST SP 800-34 Rev 1

NIST SP 800-34 is system-centric (per information system); ISO 22301 is organisation-centric (per prioritised activity). The bridge is that the per-system ISCPs (NIST) roll up into the IT DR plan, which is a component of the 8.4 plan hierarchy.

ISO 22301:2019 Clause 8.4 ↔ NIST CSF 2.0

ISO 22301:2019 Clause 8.4 ↔ SOC 2 (TSC 2017, with 2022 Points of Focus)

ISO 22301:2019 Clause 8.4 ↔ DORA (Regulation (EU) 2022/2554, applies 17 January 2025)

ISO 22301:2019 Clause 8.4 ↔ APRA CPS 230 (effective 1 July 2025)

ISO 22301:2019 Clause 8.4 ↔ Indian regulators

ISO 22301:2019 Clause 8.4 ↔ FFIEC BCM Booklet (November 2019)

The FFIEC BCM Booklet is structured almost as a US-banking restatement of ISO 22301 Clauses 5–8. The booklet's themes map directly:

• Governance & accountability ≈ Clause 5 → the response structure's accountable roles (8.4.4).
• Risk & impact understanding ≈ Clause 8.2 → feeds the plans (8.4).
• Continuity strategies & solutions ≈ Clause 8.3 → the plans execute the strategy.
• Plan development & implementation ≈ Clause 8.4 → direct equivalent.
• Testing (incl. severe but plausible scenarios) ≈ Clause 8.5 → validates the plans.
• Third-party risk in continuity ≈ Clause 8.1/8.2 → the supplier-failover procedures (8.4.3).
• Communication/crisis management ≈ Clause 8.4.2 → the crisis comms plan.

Implementation Roadmap

A phased implementation roadmap for Clause 8.4, tiered by organisation maturity. The roadmap assumes the BIA (8.2) and strategy (8.3) are already in place; if they are not, the plan set cannot be properly derived and the roadmap must be extended to front-load them.

First 30 days, Foundation

Week 1–2: Response structure design.

• Identify the IMT and CMT roles for your organisation's scale.
• Name the individuals and deputies for each role (including the BCM Lead, the Incident Commander, the CERT-In SPOC).
• Define 24x7 reachability (mobile, backup mobile, home landline, fallback rule).
• Output: Response Structure Charter (1–2 pages).

Week 2–3: Contact-list and invocation-card drill (the quick win).

• Compile the response-structure contact list.
• Phone the top 20 names at a random off-hours time; record reachability and role-awareness.
• Identify the unreachable/unaware contacts; fix them (update numbers, brief role-holders).
• Output: validated contact list + drill report with findings.

Week 3–4: BIA-strategy cross-reference.

• List the prioritised activities from the BIA (8.2).
• For each, identify the chosen continuity strategy (8.3) and whether the strategy depends on a manual workaround.
• Identify the gap: which activities have no plan, no manual workaround, or a plan that does not fit the BIA-derived RTO/RPO.
• Output: Plan Coverage Matrix (BIA activity → strategy → plan → gap).

First 90 days, Core plan set

Month 2: Master BC Plan + Crisis Comms Plan.

• Draft the Master BC Plan (skeleton from Section 9.1).
• Draft the Crisis Comms Plan, including the regulator-notification matrix (Section 9.2).
• Draft the invocation criteria matrix (Section 7.3).
• Review with the IMT and CMT; incorporate feedback.
• Output: Master BC Plan v1.0 (draft), Crisis Comms Plan v1.0 (draft).

Month 3: IT DR Plan + first manual-workaround SOPs.

• Draft the IT DR Plan for the top 5–8 critical systems, with per-system runbooks.
• Draft manual-workaround SOPs for the top 3 prioritised activities (Section 7.7).
• Identify the DRS failover procedures and the backup/restoration procedures.
• Output: IT DR Plan v1.0 (draft), 3 manual-workaround SOPs.

First 180 days, Validation

Month 4–5: Departmental plans + training.

• Draft departmental plans for each department with prioritised activities.
• Train the response structure (IMT, CMT, deputies) on their roles.
• Train the operational teams on the manual workarounds.
• Output: departmental plans v1.0; training records.

Month 6: First exercise (tabletop).

• Conduct a tabletop exercise of a plausible scenario (e.g., ransomware at 02:00 on a Sunday; complete endpoint failure; vendor outage).
• Use the exercise to validate the plans, the response structure, and the manual workarounds.
• Capture findings; log corrective actions (10.1).
• Output: Exercise report; corrective-action log.

First 365 days, Certification readiness

Month 7–9: Plan revisions + simulation exercise.

• Revise the plans based on the tabletop findings.
• Conduct a simulation exercise (more demanding than a tabletop, e.g., live manual-mode for 2 hours).
• Validate the regulator-notification drill (CERT-In 6-hour clock).
• Output: revised plans; simulation exercise report.

Month 10–12: Live DR failover + audit readiness.

• Conduct a live DR failover test for the top critical systems (Clause 8.5).
• Conduct the internal audit (Clause 9.2) of the Clause 8.4 artefacts.
• Conduct the management review (Clause 9.3).
• Address findings; finalise plans v2.0.
• Output: live failover report; internal audit report; management review minutes; plans v2.0.

Ongoing, Maintenance

• Quarterly: contact-list refresh; plan-accessibility test; regulator-notification drill.
• Semi-annual: tabletop or simulation exercise.
• Annual: full plan review; live DR failover test; internal audit; management review.
• Event-triggered: plan review within 30 days of any significant change, exercise, invocation, or audit finding.

FAQ

Q1. Is Clause 8.4 the "DR plan" clause? No. The DR plan is one of several plans Clause 8.4 requires. The clause covers the response structure, the master BC plan, the crisis comms plan, departmental plans, invocation, warning procedures, manual workarounds, and incident response integration. Calling 8.4 "the DR plan clause" understates it and is an audit red flag if it appears in your own BCMS documentation.

Q2. Do we need a separate BC plan and DR plan, or can they be one document? For a small organisation, a single integrated document covering both BC and DR may be acceptable. For a growing or enterprise organisation, separate documents are strongly recommended because the audiences differ (the BC plan is for the IMT/CMT and operations; the DR plan is for the IT recovery team) and the update cadences differ (the DR plan changes with system architecture; the BC plan changes with organisational structure). ISO 22301 does not mandate separate documents; it mandates that the set of plans be appropriate to scale and complexity.

Q3. How often must the plans be exercised? Clause 8.5 governs the exercise programme, not 8.4. ISO 22301 does not mandate a specific exercise frequency; it requires that the exercise programme validate the plans. Sector regulators are more prescriptive: SEBI MII BCP-DR (2021) requires live/parallel drills; RBI Master Direction IT Governance (2023) requires periodic BCP drills including live DR drills; IRDAI (2023) requires DR drills; APRA CPS 230 para 43 requires an annual business-continuity exercise; DORA Art 11(6) requires yearly BCP testing. For most regulated Indian organisations, the practical minimum is one tabletop and one simulation/live failover per year.

Q4. Who should be the Incident Commander, the CIO, the CISO, or the BCM Lead? It depends on the scenario class. For a cyber incident, the CISO or a designated Cyber Incident Commander is often the right IC. For a facilities or natural-disaster disruption, the Operations or Facilities Lead may be the right IC. For a general business disruption, the BCM Lead often serves as IC. The plan should specify who ICs which scenario class, with deputies for each. The same person should not IC every scenario.

Q5. What is the CERT-In 6-hour clock, and when does it start? The CERT-In Directions (28 April 2022) require reporting of prescribed cyber incidents (Annexure I list: unauthorised access, data breach, ransomware, DoS, cloud outage, etc.) to CERT-In within 6 hours of "noticing." The clock starts at noticing, when the organisation becomes aware that a reportable incident has occurred, not at confirmation, not at invocation, and not at containment. The 6-hour clock presupposes a documented incident response procedure, a named SPOC, and a tested notification path. These are Clause 8.4 artefacts.

Q6. How does DPDP affect Clause 8.4? DPDP Act 2023 Section 8(5) imposes a duty on Data Fiduciaries to protect the availability of personal data, an explicit continuity duty. Section 8(6) requires notification of a personal-data breach to the Data Protection Board and to affected Data Principals. The DPDP Rules 2025 prescribe notification to the Board within 72 hours of becoming aware. The breach-notification procedure is a Clause 8.4.2 warning-and-communication procedure. Schedule penalties reach up to ₹250 crore for failure to take adequate security safeguards and up to ₹200 crore for failure to notify a breach.

Q7. Our DR vendor says we do not need a BC plan because they handle failover. Is that true? No. A DR vendor fails over servers; it does not invoke the plan, brief the regulator, switch the call centre to manual scripts, decide which customers get priority, or execute the manual workarounds. The DR vendor is a technology component of the continuity strategy (8.3); it is not a Clause 8.4 plan. The plan must exist and must orchestrate the DR vendor's failover within the broader response.

Q8. How detailed should a manual-workaround SOP be? Detailed enough that a trained person who has not done the task recently can execute it under pressure. The SOP should specify the trigger, the authority, the step-by-step procedure, the resources (forms, printers, alternate systems), the people (with cross-training), the data-capture mechanism for reconciliation, the stand-down procedure, and the exercise record. The AIIMS Delhi 2022 case, where OPD, admissions, billing, and labs reverted to paper for 6–15 days without a pre-documented SOP, is the lesson.

Q9. Can we use our existing IT incident management process instead of a separate incident response structure? You can integrate them, but you cannot substitute one for the other. IT incident management handles the technology incident; the BC response structure manages the business disruption. The two must be linked, the IT incident has BC consequences, and the BC response depends on IT recovery, but they are distinct functions with distinct scopes. The IT incident management process is the IR dimension of the 8.4.4 response structure.

Q10. What if our organisation is too small to have a dedicated BCM Lead? For a 50–250-staff firm, the BCM Lead role is often held by the CIO, the COO, or the Head of Operations as a secondary responsibility. This is acceptable provided the role is named, the deputy is designated, and the time commitment is realistic. The most common failure mode at this size is the "founder knows everything" trap, the BCM Lead is the founder, who is unavailable during a real crisis because they are talking to the regulator, the customers, and the board simultaneously. Externalise the plans; name a deputy; train the response structure.

Q11. Do the plans need to be in English? ISO 22301 does not mandate a language. The plans must be in a language the responders understand. For most Indian organisations, English is the operational language and is appropriate. For frontline teams (manufacturing floor, hospital admissions, branch operations), bilingual plans (English + the local language) may improve usability. The plan's accessibility to the people who must execute it is the test.

Q12. How do we handle multi-site invocation? For multi-site organisations, the plan must specify which site's IMT leads when multiple sites are affected. Typically, the site where the disruption originated leads, with the corporate CMT coordinating across sites. For disruptions affecting all sites (a cyber incident, a vendor outage), the corporate IMT leads and site IMTs execute locally. The protocol must be in the master BC plan and exercised in multi-site scenarios.

Q13. What is the difference between invocation and activation? The terms are often used interchangeably, but "invocation" typically refers to activating the BC plan (the formal decision), while "activation" refers to assembling the response structure (convening the IMT/CMT). Invocation is the decision; activation is the assembly. The plan must define both: who invokes, on what criteria, and how the response structure is activated after invocation.

Q14. Should we pay a ransom? ISO 22301 does not address ransom payment. This is a strategic decision for the CMT, with legal, regulatory, and ethical dimensions. CERT-In and the RBI discourage ransom payment. The plan should include a ransomware playbook that addresses the decision framework (who decides, on what criteria, with what legal and regulatory consultation), not a predetermined answer. The Change Healthcare 2024 case (USD 22 million ransom paid, data still leaked) illustrates that paying does not guarantee recovery.

Industry-Specific Requirements

BFSI (banks, NBFCs, insurers, payment system operators, MIIs)

The most heavily regulated sector for Clause 8.4. The plan set must explicitly address:

• RBI Master Direction IT Governance (R1), the IT Service Continuity chapter requires board-approved BCP/DR policy, documented RTO/RPO, DRS with defined failover, periodic BCP drills including live/parallel DR drills, third-party continuity controls, and incident management. The plan set is the evidence.
• RBI Cyber Security Framework (R2), the CCMP (Cyber Crisis Management Plan) is a Clause 8.4 plan, layered on top of the general BC plan. The 2–6 hour RBI incident-reporting clock is an 8.4.2 regulator-notification clock. The 24x7 SOC and the CCMP are 8.4.4 response-structure components.
• SEBI CSCRF (S1), the Respond and Recover functions map to 8.4.3 and 8.4.1. The 6-hour incident-notification clock (aligned with CERT-In) is 8.4.2.
• SEBI MII BCP-DR (S2), for MIIs specifically: Near Site + DRS, RTO ≤ 2 hours for critical systems, RPO, BCP drills including live failover, geographic separation, vendor BCP, document review cadence, board approval. The plan set is the evidence.
• IRDAI Guidelines 2023 (I1), for insurers: board-approved BCP/DR, DR drills, incident reporting to IRDAI and CERT-In, 180-day logs, ICT outsourcing continuity. The plan set is the evidence.

The crisis comms plan must include regulator-notification playbooks for RBI, SEBI, IRDAI, and CERT-In, each with its own clock and format. The HDFC Bank 2020 RBI action (digital-initiatives ban for ~15 months after repeated outages) is the regulatory-escalation precedent. The Yes Bank 2020 moratorium (RBI capped withdrawals at ₹50,000 per account, lifted 18 March 2020) is the systemic-stress precedent, the plan must address depositor-communication continuity during a moratorium.

Healthcare (hospitals, pharma, medical devices, health-tech)

The plan set must address patient safety as the primary continuity objective. Key requirements:

• Clinical manual-workaround SOPs, paper-based documentation, manual prescription workflows, manual vitals monitoring, manual admissions. Pre-positioned (forms, printers, log books), trained, and exercised. The AIIMS Delhi 2022 ransomware (e-Hospital down 6–15 days, OPD/admissions/billing/labs reverted to paper) is the failure precedent.
• Offline immutable backups, the AIIMS case (primary and backup servers both encrypted) is the lesson. Clinical systems must have offline, immutable, separated-credential backups (the Code Spaces 2014 lesson applied to healthcare).
• DPDP breach-notification, PHI is personal data; the 72-hour DPDP clock applies. The plan must include the breach-notification procedure for patient data.
• Patient-safety-first invocation criteria, the invocation matrix must prioritise patient safety over data and revenue. A clinical-system outage is a Class A (life safety) trigger, not a Class B (critical-system outage).
• Pharma manufacturing disclosure, for pharma, the Sun Pharmaceutical 2023 ransomware disclosure (warning of revenue hit and litigation risk) is the precedent. The plan must address regulated-disclosure obligations during a cyber incident.

IT/ITeS and SaaS

The plan set must address the customer-facing SLA dimension:

• Customer-notification procedures, status page, direct customer comms, in-app notifications. The comms lead must be authorised to post status-page updates within an agreed SLA (15–30 minutes from detection).
• Customer SLA commitments, the BC plan must align with the customer-committed availability (e.g., 99.9% uptime). The RTO/RPO in the BIA must be consistent with the SLA commitments.
• Processor obligations under DPDP, for SaaS firms processing customer personal data as a processor, the plan must address the customer's breach-notification obligations (the processor must notify the controller within an agreed window).
• Vendor-side BC dependency, for IT-services firms, the customer's BC plan depends on the vendor's BC plan. The Wipro 2019 phishing breach (attackers pivoted through Wipro to target its outsourcing customers) is the lesson: the vendor's incident response procedure is part of the customer's BC response. The plan must include customer-notification procedures when the vendor's incident affects the customer.
• The Cognizant Maze 2020 precedent, Cognizant (a major IT-services firm with substantial India operations) disclosed approximately USD 50–70 million in Q2 2020 impact from the Maze ransomware (SEC-filed 10-Q/10-K). The lesson for IT/ITeS firms: a ransomware containment decision is a customer-facing decision, and the plan must address customer communication, service restoration, and contractual obligations.

Manufacturing (automotive, pharma, chemicals, electronics)

The plan set must address OT/IT segmentation and the production-line dimension:

• OT/IT segmentation in the DR plan, the plan must address recovery of operational technology (PLCs, SCADA, MES) separately from IT, because OT recovery has different procedures, different expertise, and different safety implications.
• Workplace violence and industrial-relations scenarios, the Maruti Suzuki Manesar 2012 case (violence and fire, ~₹1,400 crore lockout loss) is the lesson that workplace violence and industrial-relations crises are disruption scenarios. The plan must include a workplace-violence playbook.
• Chemical and MAH unit obligations, for chemical and Major Accident Hazard units, the NDMA Chemical Disaster Guidelines 2007 require on-site and off-site emergency plans integrated with District DMPs. The Clause 8.4 response structure is the statutory emergency-plan structure. The LG Polymers Vizag 2020 case (12–13 fatalities, NGT ₹50 crore penalty) is the failure precedent.
• Supply-chain continuity, the Go First 2023 insolvency (Pratt & Whitney PW1100G engine failures, 100% cancellations) is the lesson: single-source supply-chain concentration with no tested alternate is a continuity failure. The plan must include supplier-failover procedures for critical single-source inputs.

Government and Public Sector

The plan set must align with the NDMA Disaster Management Plan template (Prevention / Mitigation / Preparedness / Response / Relief / Recovery & Reconstruction / Capacity Building) and the Disaster Management Act 2005 statutory duties:

• Statutory emergency-plan structure, the Clause 8.4 response structure is also the statutory emergency-plan structure under the DM Act 2005. Section 40 requires every State department to prepare a Disaster Management Plan; the corporate BCP aligns with this.
• CII operator obligations, for Critical Information Infrastructure operators (designated under IT Act Section 70A by NCIIPC), the plan must address CII-specific threats and NCIIPC reporting expectations.
• Multi-agency coordination, the response structure must integrate with district and state disaster management authorities for large-scale events. The Mumbai 2020 grid blackout (contested cyber link, Maharashtra cited possible cyber sabotage; Union Power Ministry cited human error) is the lesson that infrastructure-dependent industries must plan for both cyber and non-cyber disruption of upstream infrastructure.
• Mumbai blackout (12 Oct 2020), contested attribution. The Mumbai blackout affected approximately 6.5 million consumers, with restoration in approximately 15–18 hours. The cyber link is contested: Maharashtra state authorities cited State Cyber Cell findings of possible cyber sabotage linked to RedEcho (a Chinese state-linked group), while the Union Power Ministry attributed the outage to human error and load issues. Present both positions; do not assert either. The Clause 8.4 lesson is that infrastructure-dependent industries must plan for grid-power continuity (UPS, genset, alternate-grid feeds) regardless of whether the trigger is cyber or non-cyber, power is upstream of every other BC plan.

Maturity Model

A five-level maturity model for ISO 22301 Clause 8.4, with INR investment estimates for a 250-staff growing firm (scale proportionally for other sizes). The maturity model is a self-assessment tool, score yourself honestly against each level's attributes.

Level 1, Initial / Ad hoc

Attributes:

• A BC plan document exists but is a single static PDF, last reviewed over 12 months ago.
• No formal response structure; the BCM Lead (whoever that is) "handles it."
• No invocation criteria; invocation is an ad-hoc decision.
• Contact list is stale; reachability untested.
• No manual-workaround SOPs; workarounds are improvised.
• No regulator-notification matrix; the 6-hour CERT-In clock is not mapped.
• No exercise programme (8.5 is also L1).
• DR plan exists for core systems but failover is untested.

Typical cost to reach L1: ₹3–8 lakh (internal effort + light external facilitation). Most Indian growing companies are at L1 by default, they have "a BC plan" because a customer or a tender asked for one.

Audit outcome: Will not pass ISO 22301 certification at L1. Will likely fail sector regulator inspections (RBI, SEBI, IRDAI) if examined.

Level 2, Developing / Repeatable

Attributes:

• BC plan is version-controlled and reviewed annually.
• Response structure documented (IMT + CMT) with named individuals and deputies.
• Invocation criteria matrix exists (Class A/B/C/D).
• Contact list refreshed annually.
• Crisis comms plan exists with regulator-notification matrix (CERT-In at minimum).
• DR plan includes per-system runbooks for critical systems; failover tested at least annually.
• 1–2 manual-workaround SOPs exist for top activities.
• One tabletop exercise per year.

Typical cost to reach L2 from L1: ₹8–20 lakh (external BCM consulting + internal effort over 12–16 weeks). This is the minimum viable certification-ready state.

Audit outcome: Can pass ISO 22301 certification at L2 with minor nonconformities. Will satisfy most sector regulator baselines.

Level 3, Defined / Managed

Attributes:

• Full plan hierarchy (master BC + DR + crisis comms + departmental plans + manual-workaround SOPs).
• Response structure includes IC role with shift rotation for prolonged disruptions.
• Invocation criteria matrix with measurable thresholds; invocation logged and timestamped.
• Contact list refreshed quarterly; reachability tested quarterly.
• Regulator-notification matrix covers all applicable clocks (CERT-In, RBI/SEBI/IRDAI, DPDP); drills quarterly.
• Manual-workaround SOPs for top 5–10 prioritised activities; exercised annually.
• Mass-notification platform deployed.
• Two exercises per year (tabletop + simulation).
• Live DR failover test annually for critical systems.
• Change-impact process linking changes to plan review.

Typical cost to reach L3 from L2: ₹15–40 lakh (people, tooling, exercise programme over 12 months). This is the target for most growing firms.

Audit outcome: Passes ISO 22301 certification cleanly. Satisfies RBI Master Direction, SEBI CSCRF, IRDAI Guidelines expectations.

Level 4, Quantitatively Managed

Attributes:

• Plan KPIs (leading and lagging) measured and reported to a BCM steering committee quarterly.
• RTO/RPO achievement tracked per exercise and per real invocation; >95% achievement.
• Invocation-to-IMT-convene time ≤ 30 minutes; invocation-to-CMT ≤ 60 minutes.
• Manual-workaround exercise coverage 100% for activities where strategy depends on them.
• Regulator-clock adherence 100%.
• Severe-but-plausible scenario exercises (ransomware at 02:00, simultaneous primary and DRS failure, supplier cascade).
• Plan-accessibility tested quarterly from out-of-band channels.
• Post-incident review (8.6) lessons tracked to plan revision in the corrective-action log (10.1).
• DR orchestration automation for top critical systems.

Typical cost to reach L4 from L3: ₹25–60 lakh annually (people, tooling, exercise programme, automation). This is the target for BFSI, healthcare, and large enterprise.

Audit outcome: Passes ISO 22301 certification with zero nonconformities. Satisfies DORA TLPT expectations (Art 26) and APRA CPS 230 testing expectations (para 43).

Level 5, Optimising / Continually Improving

Attributes:

• Continuous plan improvement driven by predictive analytics (configuration drift detection, contact-list decay prediction, exercise-failure pattern analysis).
• Plans integrated with real-time situational awareness (threat intelligence, weather, infrastructure status) for proactive invocation.
• Cross-organisational exercises with critical suppliers, regulators, and peer organisations.
• Plans benchmarked against industry peers and external incident lessons (CrowdStrike 2024, Change Healthcare 2024, AIIMS 2022) and updated within 30 days of each major external incident.
• Culture of plan use, employees at all levels know their role and have exercised it; invocation is a muscle memory, not a surprise.
• The BCMS contributes to competitive advantage (tender differentiation, customer trust, regulator relationship).

Typical cost to sustain L5: ₹40–100 lakh annually (dedicated BCM team, advanced tooling, continuous exercise programme, benchmarking). This is the target for systemically important institutions (large banks, MIIs, critical infrastructure operators).

Audit outcome: Exemplary. The organisation is a reference site for its certification body.

Maturity advancement, the path of least resistance

For most Indian growing companies, the highest-use advancement is from L1 to L2 (the certification-ready floor) and then from L2 to L3 (the regulator-satisfying target). The L3-to-L4 advancement is driven by sector, BFSI and healthcare should target L4; others can sustain L3. L5 is for systemically important institutions.

The single most common maturity ceiling is L2, organisations reach L2 (certification-ready) and stop, because the certification does not require L3. This is a strategic mistake: L2 plans pass audits but fail real disruptions, because the manual workarounds are not exercised, the contact lists are not fresh, and the severe scenarios are not rehearsed. The ROI of advancing from L2 to L3 is measured in disruptions managed rather than disruptions suffered, as the Akasa-IndiGo contrast (Section 15) illustrates.

Emerging Trends

Operational resilience replacing continuity as the framing

The global regulatory trajectory is from "business continuity" (plan for disruption, recover) to "operational resilience" (design for disruption, continue within tolerance). APRA CPS 230 (effective 1 July 2025), HKMA OR-2 (May 2022), the UK FCA/PRA/CB operational-resilience policy, and DORA all embody this shift. The implication for Clause 8.4 is that the plans must demonstrate not just recovery but tolerance-based continuity, the organisation can continue to deliver critical operations within set tolerances through a severe disruption, not just recover afterwards. The plan set must address impact tolerances (the maximum disruption the organisation can tolerate for each critical operation), not just RTO/RPO.

Climate-change adaptation in BC scenarios

ISO 22301:2019 Amendment 1:2024 (climate change adaptation) added climate-related considerations to Clauses 4.1 and 4.2, the context and stakeholder analysis. The downstream effect on Clause 8.4 is that the plan set must address climate-related disruption scenarios (extreme heat, flooding, cyclone intensification, sea-level rise for coastal sites) that are increasing in frequency and severity in India. The Chennai 2015 floods and Kerala 2018 floods are the Indian precedents; the plan set must include scenarios for the climate-driven disruptions that are now plausible rather than rare.

AI-assisted plan authoring and exercise generation

Generative AI is beginning to support BC plan authoring (drafting plan structures, generating scenario variations for exercises, summarising post-incident review notes). The technology is supplementary, not substitutive, AI can draft a plan skeleton, but the plan's usability depends on human validation, exercise, and the organisational context that AI cannot capture. The risk is that AI-generated plans read plausibly but lack the specifics (named individuals, actual system architectures, real regulator clocks) that make a plan executable. Use AI for scaffolding; use humans for substance.

Supply-chain continuity as a first-class plan component

The SolarWinds SUNBURST (December 2020), Kaseya VSA (July 2021), Change Healthcare (February 2024), and CDK Global (June 2024) incidents have established that software-supply-chain compromise is a standard disruption scenario, not an exotic one. The Clause 8.4 plan set must include procedures for responding to supplier-side incidents, isolation of vendor-administered tooling, rollback of vendor updates, supplier-incident notification procedures, and the assumption that "trusted vendor" systems may be compromised. ISO/TS 22318:2021 (supply chain continuity) is the companion standard.

Concentration risk and single-vendor failure scenarios

The CrowdStrike 2024 outage (a single vendor's defective update disabling ~8.5 million devices globally) and the Change Healthcare 2024 ransomware (a single vendor's near-monopoly creating systemic risk) have established that concentration risk is a first-class BC scenario. The Clause 8.4 plan set must include procedures for responding to single-vendor failures, including vendors whose failure mode is "host won't boot" (CrowdStrike) or "service unavailable for weeks" (Change Healthcare). The plan must address vendor-failure scenarios that are not cyber incidents but are continuity events.

Integration of BC and cyber-incident response

The convergence of BC and cyber-incident response is accelerating, driven by the recognition that most modern disruptions are cyber-origin (ransomware, supply-chain compromise, vendor outage) and that the BC and IR responses must operate in concert. DORA Art 11 (response and recovery) and Art 11(7) (crisis management function) embody this integration. The Clause 8.4 plan set must integrate the CCMP (cyber crisis management plan) with the general BC plan, with a shared command chain and shared regulator-notification procedures.

Regulator clocks tightening and multiplying

The regulatory trajectory is toward more clocks, shorter windows, and broader scope. CERT-In's 6-hour clock (2022), DPDP's 72-hour clock (2025), SEBI CSCRF's 6-hour clock (2024), APRA CPS 230's 24-hour clock (2025), and DORA's incident-reporting regime (2025) all converge on the same implication: the Clause 8.4.2 regulator-notification matrix must be a living document, reviewed whenever a regulator updates its clock. The plan must include a regulator-clock monitoring process, not just a static matrix.

Exercise scenario realism increasing

The TSE 2020 failure (failover assumed but never validated), the BA 2017 failure (untested failover), and the CrowdStrike 2024 outage (untested endpoint-fleet recovery) have driven a regulatory expectation that exercises must include severe-but-plausible scenarios, not convenient ones. DORA Art 26 (TLPT every 3 years for systemic entities) and APRA CPS 230 para 43 (annual exercise) embody this. The Clause 8.4 plan set must be validated by exercises that include the scenarios the organisation would prefer not to face, ransomware at 02:00 on a Sunday, simultaneous primary and DRS failure, key-person unavailability, supplier cascade, not just the scenarios that are easy to rehearse.

References and Further Reading

Standards and companion guidance

• ISO 22301:2019 + Amendment 1:2024, Security and resilience, Business continuity management systems, Requirements. ISO/TC 292.
• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301.
• ISO 22300:2021, Security and resilience, Vocabulary (third edition; supersedes withdrawn 22300:2018; ISO/DIS 22300 (4th ed.) is under development on iso.org and not yet published).
• ISO/TS 22331:2018, Security and resilience, Guidelines for business continuity strategy.
• ISO/TS 22318:2021, Business continuity management systems, Guidelines for supply chain continuity (second edition; supersedes withdrawn 2015 first edition).
• ISO/TS 22330, Security and resilience, Guidelines for people aspects of business continuity.
• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements (Annex A.5.29, A.5.30, A.8.13, A.8.14).
• ISO/IEC 17021-1:2015 + IAF Mandatory Documents, the rule-set governing all ISO 22301 audits (note: no BCMS-specific IAF MD exists).

Indian regulators (primary instruments)

• RBI Master Direction, IT 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, Outsourcing of Information Technology Services (10 April 2023).
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 (20 August 2024).
• SEBI Guidelines for BCP/DR of MIIs, 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) + DPDP Rules, 2025.
• Disaster Management Act, 2005 (Act 53 of 2005) + NDMA Chemical Disaster Guidelines 2007 + NDMA DMP template 2014.
• Companies Act, 2013, Section 134(3)(n), Section 177; SEBI LODR Regulation 21.
• Information Technology Act, 2000, Sections 43, 65, 66, 70, 70A, 70B, 72, 84A.

Global frameworks (primary instruments)

• NIST SP 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems (May 2010).
• NIST SP 800-160 Vol 1 + Vol 2 Rev 1, Systems Security Engineering / Developing Cyber-Resilient Systems (2016 / September 2021).
• NIST CSF 2.0, Cybersecurity Framework (26 February 2024, NIST.CSWP.29). Recover function: RC.RP, RC.CO, RC.IM.
• FFIEC IT Examination Handbook, Business Continuity Management Booklet (November 2019; OCC 2019-57, FRB SR 19-13, FDIC FIL-19071-2019).
• DORA, Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector. OJ L 333, 27.12.2022, p. 1. Applies 17 January 2025 (Art 64).
• APRA CPS 230, Operational Risk Management (effective 1 July 2025). Para 33 (72-hour notification), para 38 (tolerance levels), para 40 (BCP content), para 42 (24-hour notification), para 43 (annual exercise).
• MAS Technology Risk Management Guidelines (18 January 2021) + MAS Guidelines on Business Continuity Management.
• HKMA Supervisory Policy Manual TM-G-2 (Business Continuity Planning, 31 May 2022) + OR-2 (Operational Resilience, 31 May 2022) + SA-2 (Outsourcing).
• FEMA FCD-1 (17 January 2017) + FCD-2 (13 June 2017) under PPD-40.

Practitioner datasets

• BCI Horizon Scan 2025 ("Complex and Interconnected Risk"), the most-citable BCM industry dataset (safety incidents 14.64 top risk index; cyber the #1 organisational risk for 2026; approximately half of respondents reported thwarting a cyber-attack).
• BCI Horizon Scan 2024 (IT/telecom outages the most-disruptive risk category; 69.5% reported productivity loss).

Certification bodies operating in India

BSI Group, DNV, SGS, TÜV, Bureau Veritas, Intertek, TQCS, NQA. (Note: "BSI" refers to two distinct organisations, BSI Group the certification body, and the German BSI, bsi.bund.de, the federal cybersecurity authority. Do not conflate them.)

Incident anchors cited (primary-sourced)

• AIIMS Delhi ransomware (23 November 2022), peer-reviewed IJIM illustrative scenario; The Hindu (NIA takeover).
• HDFC Bank RBI action (2 December 2020), RBI order; Finextra; LiveMint.
• Yes Bank moratorium (5–18 March 2020), Yale Journal of Financial Compliance case.
• Cognizant Maze ransomware (April 2020), SEC 10-Q/10-K (ctsht-20201231); approximately USD 50–70 million disclosed Q2 2020 impact.
• Chennai floods (December 2015), Cognizant official statement (reaffirmed FY2015 guidance ≥ USD 12.41 billion).
• CrowdStrike global IT outage (19 July 2024), CrowdStrike preliminary post-incident report; Microsoft estimate (~8.5 million devices); Parametrix (~USD 5.4 billion Fortune 500 direct losses).
• IndiGo 19 July 2024 (~283 cancellations), The Hindu.
• Akasa Air 19 July 2024 (zero cancellations), Reuters; LiveMint.
• Jio 17 September 2024, Reuters; Cloudflare Radar (AS55836 traffic down up to 53%).
• Go First insolvency (filed 2 May 2023), NCLT; ₹597 crore refund liability (airline disclosure 31 July 2023).
• SpiceJet DGCA action (27 July 2022), DGCA 50% cap order; India Today; The Hindu.
• Air India / SITA breach (February 2021, disclosed May 2021), Reuters; BBC.
• LG Polymers Vizag (7 May 2020), NGT interim penalty ₹50 crore (OA 73/2020); The Hindu.
• Maruti Suzuki Manesar (18 July 2012), approximately ₹1,400 crore lockout loss.
• Mumbai blackout (12 October 2020), WRPC report; cyber link contested (Maharashtra vs Union Power Ministry).
• TSE 1 October 2020, Reuters; JPX.
• DBS/POSB (2023), MAS six-month IT-change pause; Reuters.
• Code Spaces (June 2014), Ars Technica; The Hacker News.
• Change Healthcare (21 February 2024), AHA; UnitedHealth Group Q3 2024.
• SolarWinds SUNBURST (December 2020), GAO-21-414; CISA joint statement; CERT-In CIAD-2020-0084 (protective alert, not a confirmed-victim list).
• Sun Pharmaceutical ransomware (2023), regulator-grade disclosure.

Paraphrase-validation note. The own-words paraphrase of ISO 22301 Clause 8.4 used throughout this guide ("ISO 22301 Clause 8.4 asks organizations to implement and maintain a response structure and documented plans and procedures to manage the organization through a disruption") is drawn from the standard's inputs/manifest.md and is the only sanctioned requirement statement. It should be verified against the official ISO 22301:2019 PDF before publication; the sub-clause descriptions in Section 2.2 are paraphrased, not verbatim, and must not be reproduced from the standard's text.