ISO 22301 Clause 7.4: Communication

Quick Reference (60 Seconds)

If you only read one thing: Clause 7.4 is where the BCMS is treated as a flowing information system rather than a document set. A 7.4-conformant BCMS is one in which the organisation has decided, in writing, what to communicate, when, to whom and how, internally and externally, for every audience that matters, for every disruption class the BIA identifies, for every regulator the organisation answers to, with tested channels, pre-approved holding statements, named and media-trained spokespersons, a clock-by-clock regulator workflow, a rumour-control design, a multilingual and accessibility design, and a two-way feedback loop that lets the organisation hear back. The certification auditor will examine this discipline ruthlessly, and so will a regulator after a disruption, when a BCMS fails, the second question after "what happened?" is always "who knew, when, what was said, to whom, by what channel, and was the answer right?". Get 7.4 wrong and however strong the policy, the BIA and the plans, the BCMS will fail on the day it is activated because the workforce the plans assume will be reachable will not be reachable, the customers the plans assume will be informed will be uninformed, the regulators the plans assume will be notified within the clock will be notified late, and the public the plans assume will be reassured will be alarmed. Get it right and the BCMS becomes a system whose information moves as fast as the disruption does, with the right content, the right authority, the right channel, and the right feedback loop to learn from what worked and what did not.

What the Standard Actually Requires

The paraphrased requirement

ISO 22301 Clause 7.4 asks organizations to decide what to communicate about the BCMS, when, to whom, and how, internally and externally. The clause sits inside Clause 7 (Support) and forms the information-flow spine of the BCMS. Four decisions flow from the paraphrase, each of which an auditor will test independently, plus a fifth element, the bidirectional principle, that an experienced auditor will probe for whether the organisation has consciously designed.

Decision 1, What to communicate (content). The organisation must decide, for each audience, what BCM content that audience needs. Content falls into two broad categories: the routine BCMS communication that builds and maintains the system (policy publication, objectives cascade, role assignment, awareness delivery, exercise calendar, lessons learned, improvement actions, board and steering-committee reporting), and the crisis communication that activates during a disruption (warning and alerting, invocation notices, situational-status updates, recovery progress, customer service messages, regulator notifications, public statements, rumour response, post-disruption all-clear and lessons-learned communication). The "what" decision must be specific to audience: a board director needs different content from a floor worker, a regulator needs different content from a journalist, a customer needs different content from a supplier. An auditor will look for a Communication Requirements Matrix that names the content per audience per phase; "we communicate what is needed" is not a decision, it is a deferred decision.

Decision 2, When to communicate (timing). The organisation must decide, for each piece of content, the timing. Timing falls into three regimes: cadence (the routine communication rhythm, annual policy, quarterly awareness, monthly KPI dashboard, weekly BCM team stand-up, daily during activation), trigger-driven (the event-driven communication, BIA-driven warning, plan invocation, incident detection at the SOC, regulator-clock deadline approaching, recovery milestone reached, public inquiry threshold crossed), and clock-bound (the regulator-imposed deadlines, CERT-In six hours from noticing for prescribed cyber incidents, RBI two to six hours for bank-incident reporting, SEBI six hours for MII cyber incidents, IRDAI per the 2023 guidelines, DPDP seventy-two hours for personal-data breach notification to the Data Protection Board, SEBI LODR Regulation 30 prompt disclosure for listed entities on material events). The "when" decision must be documented for every clock-bound communication because the regulator will measure the organisation against the clock, not against the organisation's intent.

Decision 3, With whom (audience). The organisation must identify, in writing, the audiences it communicates with about the BCMS. The eleven canonical audiences that an Indian growing company typically needs to communicate with are: (1) the workforce (employees, contractors, trainees, interns, supplier-staff on site); (2) the board and top management (CEO, MD, board, board committees, particularly the Risk Management Committee under SEBI LODR Reg 21 and the Audit Committee under Companies Act s 177); (3) the BCM team and Crisis Management Team (BCM Manager, CMT Chair, CMT members, BCM Coordinators, floor marshals); (4) the IT DR, SOC and incident-response team (DR engineers, SOC analysts, IR engineers, forensics partners); (5) regulators and statutory authorities (RBI, SEBI, IRDAI, CERT-In, NCIIPC, MCA, NDMA, state and district disaster-management authorities, sector-specific regulators); (6) customers and clients (B2B key accounts, retail customers, patients, depositors, policyholders, passengers, students, citizens for government work); (7) suppliers, vendors and outsourcing partners (cloud providers, MSPs, logistics, facilities, security services, critical raw-material suppliers); (8) media and the public (press, television, social media, the corporate website's incident page, the public enquiry line); (9) investors, analysts and rating agencies (for listed entities and entities with public debt); (10) insurers, brokers and reinsurers (cyber insurance, business-interruption insurance, D and O insurance, the loss-notification communication); and (11) emergency services, neighbours and mutual-aid partners (fire, police, ambulance, hospitals, NDRF, SDRF, district authorities, industrial-area mutual-aid associations, neighbours who may be affected by a hazardous release, families of the workforce). The audience list is not generic; it must reflect the organisation's own scope, sector, geography and stakeholder map (Clause 4.2).

Decision 4, How to communicate (channel). The organisation must decide, for each audience and each content type, the channel (or channels) used. Channels fall into seven families: in-person and meeting channels (CMT bridge, board call, town hall, floor briefing), asynchronous messaging channels (email, intranet, workforce app, customer portal, supplier portal), broadcast channels (mass-notification system, voice and SMS blast, IVR message, social media post, press release, regulatory portal submission, customer push notification, app banner), interactive channels (hotline, escalation line, two-way chat, Q&A town-hall, feedback form, social media response), out-of-band channels (satellite phone, hard-line, runner, printed notice, public-address system, neighbourhood megaphone, used when primary channels are degraded), secure channels (encrypted email, secure messenger, dedicated incident portal with MFA, board-portal secure upload), and accessibility and multilingual channels (sign-language interpreter at briefings, screen-reader-compliant content, multilingual IVR, regional-language SMS and printed material, easy-read versions for persons with cognitive disabilities). The "how" decision must specify the primary, secondary and out-of-band channels for each audience, because the channel that works on a normal day is often the channel that fails on a bad one, email is useless during a ransomware encryption event, the intranet is useless during a network outage, the public-address system is useless during a power failure, the customer call-centre is useless during a telephony outage. An auditor will look for a Channel Architecture document with redundancy and out-of-band paths designed, evidenced and tested.

Decision 5 (implied), The bidirectional principle. A communication that does not allow the receiver to respond, ask, confirm, flag or escalate is a broadcast, not a communication. The paraphrase "internally and externally" implies bidirectional flow because the BCMS, like every management system, depends on feedback to learn. The bidirectional principle means every audience has a verified inbound path: the workforce has a hotline and an escalation route, the customer has a complaint and enquiry route, the supplier has an escalation route, the regulator has a response channel, the public has an enquiry line. The auditor's test for the bidirectional principle is "show me the last time the workforce raised a concern through the BCM feedback channel and the organisation acted on it", and the answer cannot be "we have a suggestion box".

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

Clause 7.4 is often conflated with neighbouring clauses and with broader corporate-communication disciplines. It is helpful to be explicit about what is out of scope for 7.4 itself, because auditors test the boundary:

• It does not require role-specific competence for communicators. That is Clause 7.2. 7.2 builds the deep capability the spokesperson, the Crisis-Communication Lead, the regulator-PoC and the customer-communication lead need to do their work. 7.4 builds the flows they move information through. A Crisis-Communication Lead who is 7.2-competent (media-trained, regulator-savvy, message-disciplined) still needs the 7.4 channel architecture and the pre-approved holding statements to do their job on the day.
• It does not require workforce awareness. That is Clause 7.3. 7.3 builds the workforce's continuing understanding of the BC policy, their role in disruptions and the consequences of non-compliance. 7.4 builds the flows that move information during routine operations and during disruption. The two clauses overlap operationally (a policy-publication town-hall is a 7.4 communication event that builds 7.3 awareness) but the audit tests differ: 7.4 asks "do you have a communication plan, did you execute it, is it current, did the message reach"; 7.3 asks "is the workforce aware, can you prove it, when did you last measure it".
• It does not require the documented information system itself. That is Clause 7.5. 7.5 governs the creation, update and control of documented information. 7.4 governs the communication of that information. The two clauses interlock, communication evidence is documented information under Clause 7.5 control, but the disciplines are distinct: 7.5 asks "is the document controlled, version-current, access-managed, retrievable"; 7.4 asks "did the content reach the audience, on time, on channel, with the right authority".
• It does not require a specific channel or technology. The clause is outcome-based: information must flow. Email, intranet, town halls, mass notification, voice/SMS, social media, press releases, regulatory portals, customer portals, dedicated incident bridges, printed notices, public-address announcements, satellite phones, runners, all are valid channels. The organisation chooses channels matched to its audience, language mix, shift patterns, locations, regulatory obligations and digital maturity. An auditor who insists on a mass-notification system is over-specifying; the right test is "did the message reach, did the receiver understand, was the channel resilient, was the evidence captured".
• It does not require a public-relations agency or a crisis-communications consultancy on retainer. A PR partner is one tool that helps deliver public-facing communication during a major incident; it is not a requirement. At lower maturity, the in-house Corporate Communications function and the BCM Manager can deliver the public-facing communication for a small organisation. The decision to engage a PR partner is a Clause 7.1 resourcing decision.
• It does not require a single spokesperson. The clause requires the organisation to have decided who communicates, with what authority, on whose approval. Many organisations operate a tiered spokesperson model, the CEO for the most severe incidents, the Head of Corporate Communications for day-to-day media, the Head of Customer Experience for customer channels, the CISO for technical incident updates, the Company Secretary for regulatory communication, the BCM Manager for internal coordination. The tiered model is the right design for most growing companies; the requirement is that the model is documented, the authorities are clear, and the people in the roles are media-trained.
• It does not require 24x7 communication capability. The clause requires the organisation to have decided the level of communication availability appropriate to its risk profile, regulatory obligations and stakeholder expectations. CERT-In's 24x7 PoC contactability requirement (under the 28 April 2022 directions) is a sectoral rule that effectively mandates 24x7 communication capability for any ICT operator in India, but that is a CERT-In rule, not a 7.4 requirement. The 7.4 requirement is that the organisation has decided its communication-availability posture and can evidence the decision.
• It does not require the communication to be successful. The clause requires the organisation to have decided, designed, delivered and evidenced the communication. Whether the communication succeeds in reassuring a customer or in defusing a media storm is an effectiveness question measured under Clause 9.1 and reviewed under Clause 9.3. A BCMS can be 7.4-conformant and still face reputational damage from a poorly worded message; what it cannot be is 7.4-conformant without a communication system at all.

The companion guidance and adjacent standards

The clause text is short; the method lives in companion and adjacent standards. Both are paywalled; cite the current edition:

• 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 7.4 evidence should look like and how communication interlocks with the rest of the BCMS.
• ISO/TS 22330, Security and resilience, Guidelines for people resilience. Communication with, to and from people is a core people-resilience discipline: communication of role, communication during a disruption, welfare communication, communication with families.
• ISO/TS 22318:2021, Supply chain continuity. Communication with critical suppliers, communication of supplier-failure scenarios, contractual communication clauses under outsourcing and cloud arrangements.
• ISO/IEC 27001:2022 Clause 7.4, the Information Security Management System analogue, with the same Harmonized Structure. Useful for integrated audits and for evidencing communication across the ISO 27001 / 22301 stack. The control statements differ in detail (27001 emphasises information-security topics and consistent messages; 22301 emphasises BCMS-specific communication, internal/external, the four decisions); in an integrated programme both stances are taught together.
• ISO/IEC 27001:2022 Annex A control 5.29 (information security during disruption), 5.30 (ICT readiness for business continuity), 8.13 (information backup, relevant where communications evidence and templates must be backed up), 8.14 (redundancy of information processing, relevant for channel redundancy), 5.6 and 5.7 (threat intelligence and communication thereof), 5.24 to 5.28 (supplier communication and cloud-service communication), 6.8 (information security event management, the upstream of incident communication). The 27001 / 22301 overlap is densest here.
• ISO 9001:2015 Clause 7.4, "Communication" in the Quality Management System. Useful where the organisation has an integrated QMS/BCMS, especially for customer-communication discipline.
• ISO 45001:2018 Clause 7.4, occupational health and safety communication. Highly relevant for industrial and manufacturing contexts where worker-safety communication (hazard notification, evacuation, lockout-tagout, incident reporting) overlaps heavily with BCM communication.
• ISO 14001:2015 Clause 7.4, environmental communication. Relevant for chemical, pharma and manufacturing firms where environmental emergency communication is a BCM scenario (LG Polymers-class events).
• ISO 22300:2021, Security and resilience, Vocabulary. The normative source for definitions of communication, warning, alert, notification, invocation, interested party, disruption, stakeholder. 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/IEC 27031:2011, Guidelines for information and communication technology readiness for business continuity. Now somewhat dated but still the canonical reference for ICT readiness, including the communication infrastructure readiness angle.
• NIST SP 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems. The seven-step contingency planning process includes communication elements (notification, activation, operations, reconstitution).
• NIST SP 800-61 Rev 2, Computer Security Incident Handling Guide. The canonical reference for cyber-incident communication, including the coordination categories and the communication pitfalls during a major incident.
• NIST CSF 2.0, the Recover function's Communicate category (RC.CO): "Restoration activities are coordinated with internal and external parties (such as coordinating centres, Internet Service Providers, owners of attacking systems, victims, other CSIRTs, and vendors)." The cleanest single-line restatement of the bidirectional principle.

Recognised professional communication vehicles (citable, mapped TO)

Professional communication vehicles are one evidentially clean route to demonstrating communication competence under Decision 4. They are not mandated by the clause, but they are widely recognised by Indian regulators and global frameworks. The most relevant for an Indian growing-company BCMS:

• BCI practitioner guidance, the Crisis Communications professional practice (within the Design domain) and the Communication thread embedded in the Incident Response and Recovery practices. GPG 7.0 (launched 31 October 2023) is the current edition; cite as the practitioner reference.
• DRI International DRI professional-practice framework, the Crisis Communications practice and the Emergency Response practice. Free at drii.org; the ten-practice framework is living.
• ISC2 incident-communication modules within the CISSP and SSCP bodies of knowledge, useful for the cyber-incident communication overlap.
• ISACA crisis-communication guidance within the CISM and CRISC bodies of knowledge, useful for the risk-and-control framing of communication.
• NCFM / NISM capital-markets communication modules, useful for the SEBI-regulated workforce, particularly broker and MII customer communication.
• IRDAI-mandated insurance communication modules, for insurance-intermediary workforce and policyholder communication.
• CERT-In advisories and the CERT-In PoC network, the active communication channel between Indian ICT operators and the national incident-response authority; the PoC role itself is a communication vehicle.
• NDMA Do's-and-Don'ts public-communication material, freely reusable communication artefacts for natural-hazard scenarios (earthquake, flood, cyclone, chemical, industrial, fire, tsunami, landslide), available in Indian languages from ndma.gov.in; usable in the BCM communication portfolio for the workforce and the surrounding community.
• Sector-skilling council communication content, for example, SSC NASSCOM content for IT-ITeS workforce communication; Auto SSC content for manufacturing workforce communication.
• IIROC / ICAEW / PRCA crisis-communication codes, international public-relations and corporate-affairs codes useful as benchmarks for the spokesperson discipline charter.

These vehicles are routes to communication competence; they are not communication itself. An auditor will ask: "Did this module map to a role in your Audience and Stakeholder Map? Did the communicator complete it? Is it current? Did the competence transfer into the channel?" A lapsed or irrelevant module is weaker evidence than a current exercise-evaluator rating of communication in role.

What auditors actually check

Certification auditors (BSI, DNV, SGS, TÜV, Bureau Veritas, NQA, Intertek, plus Indian certification bodies such as TQCS, DQC and DNV India) test Clause 7.4 by triangulating three things:

• The communication documentation set, BCM Communication Policy, Procedure, Audience and Stakeholder Map, Communication Requirements Matrix, Channel Architecture, Regulator-Clock Matrix, Holding-Statement Library, Spokesperson Discipline Charter, Rumour-Control and Social-Listening Design, Two-Way Feedback Architecture, Multilingual and Accessibility Plan, Communication Evidence Records, Communication KPI Dashboard. An auditor will ask for the table of contents and a sample of each artefact, not just the apex policy.
• A traced communication event end-to-end, the auditor picks a real communication event from the last twelve months (invocation notice, regulator notification, customer message, board update, press statement, exercise debrief) and walks it from trigger to evidence: who triggered it, who approved it, who sent it, on which channel, at what time, to which audience, what content, what feedback, what evidence was retained under Clause 7.5, what corrective action followed. A clean walk is a strong signal; a broken walk, "we sent the email but didn't log it", "we notified the regulator but can't find the proof", "we issued the holding statement but the spokesperson had not been briefed", is a major non-conformity.
• The communication exercise evidence, the auditor asks for the last crisis-communication exercise (tabletop, drill, simulation) and walks through what was tested, what was learned, what corrective actions were opened, and which have been closed. A BCMS where the crisis communication has never been exercised is the second-most-common 7.4 non-conformity in the Indian growing-company segment.

The triangulation is deliberate. Documentation without a traced event is paper; a traced event without documentation is folklore; both without exercise evidence is a system that has never been stressed. The certification auditor wants all three.

Why This Control Matters

The business risk of communication failure

When a BCMS fails under stress, the failure rarely starts with the technology. It starts with a communication that did not happen, happened late, happened on the wrong channel, reached the wrong audience, carried the wrong content, was attributed to the wrong spokesperson, or did not allow the receiver to respond. The Mumbai-based payment processor that discovers ransomware at 02:00 and is still debating at 09:00 who calls CERT-In has a communication failure, not a technical one. The Chennai-based SaaS firm whose CEO tweets about "minor technical issues" while customers report four hours of total outage on Downdetector has a communication failure, not a technical one. The Pune-based auto-component manufacturer whose plant manager waits three hours for head-office clearance to call the fire brigade has a communication failure that may cost lives. The Bengaluru-based hospital whose clinical staff cannot reach the IT DR team because the only phone number is on a locked intranet page that the ransomware encrypted has a communication failure that may cost patients.

In each case, the technical response may be exemplary; the failure is in the flow of information. A growing body of post-incident review literature, across the CrowdStrike 19 July 2024 global outage, the Tokyo Stock Exchange 1 October 2020 full-day halt, the British Airways 27 May 2017 power cascade, the DBS Bank recurring 2018/2021/2023 digital-banking outages, the Colonial Pipeline 7 May 2021 shutdown, the Change Healthcare 21 February 2024 ransomware, points to the same pattern: the organisations that recovered fastest and reputational-damaged least were the ones whose communication discipline was designed, rehearsed, and executed, not improvised. The organisations that recovered slowest and reputational-damaged most were the ones whose communication was improvised on the day.

The business risk of communication failure decomposes into seven loss channels: regulatory-loss channel (late or wrong regulator notification → monetary penalty, restriction on business, personal liability for senior managers); customer-loss channel (late or wrong customer communication → customer churn, contract cancellation, class-action exposure, particularly severe in BFSI and SaaS where customer switching costs are low); reputational-loss channel (mishandled press or social-media response → brand damage, talent attrition, analyst downgrade); workforce-safety channel (failure to warn or instruct the workforce during a physical or industrial disruption → injury or death, regulatory investigation, criminal liability); operational-loss channel (failure of communication between CMT and DR team → wrong recovery decisions, longer RTO breach, larger impact); financial-loss channel (failure of communication with insurers → denied claims, sub-limits invoked; failure of communication with banks and creditors → covenant breach, liquidity crunch); legal-loss channel (inconsistent external statements → admission against interest, securities-fraud exposure for listed entities, weaker litigation position). The Clause 7.4 discipline is the single highest-use investment against all seven channels because every channel is gated by communication.

The Indian context

Indian growing companies face a particularly demanding communication environment for five reasons. First, the regulator-clock density is unusually high: CERT-In's six-hour clock under the 28 April 2022 directions, RBI's two-to-six-hour incident-reporting expectation under the 2016 cyber framework and the 2023 Master Direction, SEBI's six-hour clock for MII cyber incidents under the 2024 CSCRF, IRDAI's incident-reporting expectation under the 2023 guidelines, DPDP's seventy-two-hour clock for personal-data breaches under Section 8(6) and the 2025 Rules, SEBI LODR Regulation 30's prompt-disclosure expectation for listed entities, the Companies Act 2013 Section 134(3)(n) board-risk-statement expectation, and the NDMA Disaster Management Act 2005's coordination expectations. A mid-market Indian bank is on the hook for at least four overlapping clocks (RBI, CERT-In, DPDP if customer data is involved, and SEBI LODR if listed). Without a Regulator-Clock Matrix that maps every clock to a trigger, an owner, a form and a channel, the organisation will miss one.

Second, the language and literacy diversity of the Indian workforce and customer base is the most complex in any major economy. A manufacturing plant in Tamil Nadu may have floor workers whose first language is Tamil, supervisors whose working language is English, and contract labour from Hindi-speaking states. A hospital in Maharashtra may have nurses from Kerala, doctors from across India, and patients who speak only Marathi. A payment app's customer base spans every major Indian language. A communication design that assumes English fluency is a communication design that fails the majority of the workforce and the customer base. The multilingual design (Section 7.7) is not an optional accessibility feature; it is the core design constraint.

Third, the field-force footprint is large. Indian BFSI, FMCG, pharma, manufacturing and government firms maintain field forces, sales representatives, relationship officers, field engineers, ASHA workers, Anganwadi workers, meter readers, delivery riders, who do not sit at desks, do not read intranet emails, and do not have reliable access to corporate Wi-Fi. Communication design that ignores the field force is communication design that ignores a substantial fraction of the organisation's capability and a substantial fraction of its risk surface.

Fourth, the mobile-first and WhatsApp-default behaviour of the Indian workforce and customer base means that official communication competes with a firehose of unofficial communication on personal channels. A ransomware rumour on WhatsApp can reach the workforce's family chat groups before the official communication reaches the workforce. Rumour-control and social-listening design (Section 7.10) is not a nice-to-have; it is the only defence against the parallel communication network that the workforce and customer base already inhabit.

Fifth, the regulator focus on customer communication has hardened materially since 2023. RBI's 2 December 2020 action against HDFC Bank (barring new digital products and fresh credit cards pending external IT audit) was triggered in part by repeated digital outages that the bank did not communicate to customers in real time. SEBI's CSCRF (20 August 2024) requires REs to communicate cyber incidents to affected customers. IRDAI's 2023 guidelines require insurers to communicate claims-continuity arrangements to policyholders during disruption. DPDP's Section 8(6) requires breach notification to affected Data Principals "without delay". A growing company that treats customer communication as a marketing function rather than a regulated compliance discipline is a growing company one incident away from a regulator action.

The cost of non-compliance, illustrative numbers

The cost of getting 7.4 wrong is rarely a single line item; it is a cascade. Illustratively:

• A CERT-In late-notification penalty exposure: while the 28 April 2022 directions do not specify a per-day monetary penalty, Section 70B of the IT Act 2000 (under which the directions are issued) carries the IT Act's general penalty regime; the more material exposure is the regulator's escalation to investigation, audit, and public identification as a non-compliant entity.
• A DPDP breach-notification failure exposure: up to ₹250 crore for failure to take adequate security safeguards (Section 33) and up to ₹200 crore for failure to notify a breach (Section 33 read with the Schedule).
• An RBI enforcement exposure: monetary penalties under the Banking Regulation Act, restrictions on business (the HDFC 2020 model), and personal accountability actions against senior managers under the 2023 Master Direction's senior-manager accountability regime.
• A SEBI LODR exposure: Regulation 30 disclosure failure carries monetary penalty under Section 15A of the SEBI Act, with listed entities additionally exposed to investor class actions.
• A customer-churn exposure: in BFSI SaaS and payment services, post-incident customer churn of 2 to 8 percent is typical after a poorly communicated outage; on a customer base of one million with average revenue per user of ₹2,400 per year, a 5 percent churn event is ₹12 million of annualised revenue gone, before acquisition-cost-to-replace.
• A workforce-safety exposure: a single fatality in a manufacturing or industrial context can carry a ₹5 to ₹50 crore exposure under the Workmen's Compensation Act, criminal liability under Section 304A of the Indian Penal Code, and the plant closure cost; communication failure is frequently the proximate cause.
• A reputational exposure: brand-value impairment after a public communication failure is harder to quantify but routinely estimated in the high single-digit percentages of market capitalisation for listed entities.

The point is not the precision of any single number; the point is that communication failure is a multi-channel loss event, and the investment in a Clause 7.4-conformant communication system is almost always lower than the cost of even one of these channels firing.

Scope and Applicability

Who Clause 7.4 applies to

Clause 7.4 applies to every organisation that has claimed conformity to ISO 22301:2019, regardless of sector, size, geography or scope-of-certification statement. The clause is part of the management-system requirements (Clauses 4 to 10), which are mandatory for any certification claim. There is no "we are too small" exemption, no "we are a non-profit" exemption, no "we outsource our communications" exemption. The organisation's scope statement (Clause 4.3) determines which parts of the organisation are inside the BCMS, and Clause 7.4 applies to the communication of the BCMS in that scope.

For an integrated management system (for example, ISO 27001 + ISO 22301 + ISO 9001), Clause 7.4 can be evidenced once across the disciplines, a single Communication Policy, a single Procedure, a single Audience and Stakeholder Map, provided the integrated system demonstrably covers the discipline-specific requirements of each standard. The integrated approach is the right design for most growing companies because it avoids duplicate artefacts and forces alignment between the quality, information-security, and business-continuity communication programmes.

Scope by organisation size

Very small organisations (10 to 50 staff). The communication system is light: a one-page Communication Plan naming the eleven audiences (most of whom are reached by direct conversation), a single spokesperson (usually the founder or CEO), a single mass-notification channel (typically WhatsApp Business or a voice/SMS blast service), the regulator clocks the organisation is subject to (CERT-In for any ICT operation; DPDP for any personal-data processing), and a holding-statement library of one to three statements for the top scenarios. Evidence is a simple communication log. Time-to-implement: 4 to 6 weeks.

Growing companies (50 to 250 staff). The communication system extends to a written Communication Policy, a written Procedure, an Audience and Stakeholder Map with the eleven audiences named and owners assigned, a Communication Requirements Matrix, a Channel Architecture with redundancy, a Regulator-Clock Matrix, a holding-statement library of eight to twelve statements, a Spokesperson Discipline Charter, a multilingual plan covering the workforce language mix, and a quarterly crisis-communication tabletop. Evidence is a structured communication log plus exercise reports. Time-to-implement: 6 to 10 weeks.

Mid-market (250 to 2,000 staff). The communication system matures: a CRM-integrated customer-communication stack, a mass-notification system (typically an India-headquartered SaaS or a global provider with Indian data residency), a corporate-communications function, a media-trained spokesperson pool, a multilingual content build covering the top four to six languages at each work location, a regulator-engagement cycle, a documented two-way feedback architecture (workforce hotline, customer escalation, supplier escalation), an annual crisis-communication simulation, and integration with the BCM exercise programme (Clause 8.5). Evidence is a full Clause 7.5-controlled document set plus the KPI dashboard. Time-to-implement: 10 to 16 weeks.

Multi-entity enterprise (2,000+ staff). The communication system is enterprise-grade: group communications, group legal, group investor relations, multi-jurisdiction regulator engagement, multi-language multi-location multi-shift delivery, a dedicated crisis-communications consultancy on retainer (for major incidents only), a board-level crisis-communication protocol, integration with the corporate-affairs and government-affairs functions, integration with the corporate-incident-management workflow, integration with the cyber-insurance loss-notification workflow, and a half-yearly board-level crisis-communication simulation. Time-to-implement: 4 to 6 months.

Scope by industry

Each industry has a distinctive communication risk profile, regulatory footprint and stakeholder pattern. Section 21 (Industry-Specific Requirements) covers this in depth; the headline pattern is:

• BFSI (banks, NBFCs, payment systems, insurers, capital markets). The most regulator-dense communication environment. RBI for banks and NBFCs, SEBI for capital markets, IRDAI for insurers, CERT-In for all ICT, DPDP for customer personal data, SEBI LODR for listed entities. Customer communication is regulated content (RBI on mis-selling, SEBI on investor communication, IRDAI on policyholder communication). The six-hour and seventy-two-hour clocks bite hardest here.
• Healthcare (hospitals, pharma, medical devices, diagnostics). Patient communication is safety-critical. Clinical-staff communication during an EHR or PACS outage is the difference between continued care and patient harm. Regulator footprint: Clinical Establishments Act, state health departments, IRDAI for insured care, DPDP for health data (a Special Category under DPDP Rules 2025), NMC for medical practitioners.
• IT/ITeS and SaaS. Customer communication is contractually bound by SLAs and uptime guarantees; breach-notification clauses in customer contracts often impose shorter clocks than DPDP. Regulator footprint: CERT-In for ICT, DPDP for personal data, GST and STPI for tax and trade, customer-jurisdiction regulators for global SaaS (including the EU under GDPR and DORA if the customer is a financial entity).
• Manufacturing (auto, pharma, chemicals, electronics, textiles). Workforce-safety communication is life-safety. Plant-to-headquarters communication during an industrial incident is regulator-critical. Regulator footprint: Factory Inspectorate, Pollution Control Boards, NDMA for chemical and industrial hazards, PESO for petroleum and explosives, ESI for workforce welfare, DPDP for any HR or customer data.
• Government and Public Sector. Citizen communication is regulated content (Right to Information, Citizen's Charter). Coordination with NDMA, NDRF, state and district authorities during disaster. Regulator footprint: the parent ministry, CAG, CVC, and the parliamentary committee structure.

The Clause 7.4 implementation must reflect the organisation's industry-specific scope; a generic communication plan that does not address the industry-specific audiences, channels, clocks and risks is non-conformant.

In-scope and out-of-scope

In scope for Clause 7.4:

• All routine communication about the BCMS (policy publication, objectives, role assignment, awareness delivery, exercise calendar, lessons learned, improvement actions, board reporting).
• All crisis communication during a BCMS-relevant disruption (warning, alerting, invocation, status, recovery, customer, regulator, public, rumour control, post-disruption).
• All audiences with whom the organisation communicates about the BCMS, the eleven canonical audiences plus any organisation-specific additions.
• All channels through which BCMS communication flows, primary, secondary and out-of-band.
• All regulator clocks the organisation is subject to, with documented triggers, recipients, forms, channels and evidence.
• All two-way feedback paths the organisation relies on for the BCMS to learn.
• All evidence of communication events, retained under Clause 7.5 document control.

Out of scope for Clause 7.4 (handled by other clauses or by other disciplines):

• The competence of communicators (Clause 7.2).
• The awareness of the workforce (Clause 7.3), though communication builds awareness.
• The documented information system itself (Clause 7.5), though communication evidence is documented information.
• Marketing communication, brand communication, investor communication unrelated to BCMS, these are corporate disciplines, not 7.4 obligations, except when a BCMS-relevant disruption makes them so.
• The technical content of recovery procedures (Clause 8.4), though the communication of those procedures is in scope.
• The technical correctness of regulator reports (the substantive accuracy of a CERT-In report, for example), that is the substantive compliance discipline; 7.4 covers the communication discipline (timeliness, channel, evidence).

The boundary is clean in principle and tested in audit. When the boundary is blurred, for example, a customer outage communication that is both a 7.4 event and a marketing decision, the BCM Manager and the Head of Corporate Communications should agree in advance whose document controls the artefact, and the BCMS audit samples it under 7.4.

Key Definitions and Terminology

The vocabulary of BCM communication overlaps with general management-system vocabulary, with information-security communication, with corporate-communication vocabulary, and with the regulator-clock vocabulary of the Indian regime. The normative source is ISO 22300:2021 (with ISO/DIS 22300 (4th ed.) under development and due to replace the 2021 edition; not yet published); the working definitions below are paraphrased for this guide.

• Communication (in the BCMS context). The deliberate, decided, designed, delivered and evidenced flow of information between the organisation and a defined audience, on a defined channel, at a defined time, with a defined content, and with a defined feedback path. The defining word is decided, a communication is the result of a decision, not the result of an impulse.
• Routine BCMS communication. Communication about the BCMS during normal operations, policy publication, objectives cascade, role assignment, awareness delivery, exercise calendar, lessons learned, improvement actions, board reporting.
• Crisis communication. Communication during and immediately after a BCMS-relevant disruption, warning, alerting, invocation, status, recovery, customer, regulator, public, rumour control, post-disruption. Crisis communication has a different rhythm, authority and channel-mix from routine BCMS communication.
• Warning. Communication that a disruption may be approaching or has been detected, directed at audiences who need to prepare or act. A warning is the first communication of the crisis-communication lifecycle.
• Alert. Communication that a disruption is happening or is imminent, directed at audiences who need to act now. An alert is sharper and more urgent than a warning.
• Notification. Communication to a regulator or a statutory authority that an event has occurred, in the form, on the channel and within the clock that the regulator specifies. CERT-In notification, RBI notification, DPDP notification.
• Invocation. Communication that a BCMS plan (typically the IT DR plan, the work-area recovery plan, or the crisis-management plan) has been formally activated, with the named authorities, the named responders and the named escalation paths. Invocation is the formal decision-point of the response.
• Status update. Communication of the current state of the response, the current state of the recovery, and the current state of the audience's interests, typically on a defined cadence during an activation.
• Holding statement. A pre-approved, partially-templated statement issued in the first minutes or hours of a disruption, designed to acknowledge the event, set expectations, identify the spokesperson and the next-update time, without admitting facts that have not been verified. The holding statement is the single most useful artefact in the crisis-communication toolkit.
• Spokesperson. A named individual authorised to speak on the record on behalf of the organisation during a defined disruption class. The spokesperson is media-trained, message-disciplined, and operates within a defined authority band.
• Stakeholder (interested party). In our own words: anyone, person or organisation, who can influence the BCMS, who feels the effects of its performance, or who believes they feel those effects. ISO 22301 Clause 4.2 requires the organisation to identify its interested parties; Clause 7.4 requires the organisation to communicate with the ones that matter for the BCMS.
• Mass-notification system. A software platform that delivers messages to large numbers of recipients simultaneously across multiple channels (email, SMS, voice, app push, social), with delivery confirmation, response capture and audit logging. The mass-notification system is the workhorse of the broadcast channel family.
• Out-of-band channel. A communication channel that does not share the failure modes of the primary channel, satellite phone when mobile is down, hard-line when IP is down, runner when everything electronic is down, public-address when personal devices are down. Out-of-band channels are the resilience layer of the Channel Architecture.
• Regulator clock. The time bound within which a regulator requires notification of a defined event. CERT-In six hours from noticing for prescribed cyber incidents, RBI two-to-six hours for bank incident reporting, SEBI six hours for MII cyber incidents, DPDP seventy-two hours for personal-data breach notification.
• Two-way communication (bidirectional principle). Communication that allows the receiver to respond, ask, confirm, flag or escalate back to the sender. The bidirectional principle is the difference between a communication system and a broadcast system.
• Rumour control. The discipline of monitoring unofficial communication channels (social media, WhatsApp, online forums) for misinformation about the disruption, and responding with verified information through the official channel. Rumour control is increasingly central as the speed of unofficial communication outpaces the speed of official communication.
• Social listening. The systematic monitoring of social media and online channels for mentions of the organisation, the disruption, and the sentiment of the audience. Social listening feeds rumour control, reputation management, and the two-way feedback loop.
• Customer communication. Communication with the organisation's customers, retail, B2B, patient, depositor, policyholder, passenger, citizen, during normal operations and during disruption. In BFSI and SaaS, customer communication is regulated content.
• Family notification. Communication with the families of the workforce during a severe incident, typically a fatality, a serious injury, a hostage situation, or an extended site lock-down. Family notification is high-sensitivity, high-authority communication, usually owned by the Head of HR with executive approval.
• Pre-approved message. A message whose content has been approved in advance (typically by Legal, by Corporate Communications, and by the relevant executive) for use in a defined disruption class, with placeholder fields for event-specific details. Pre-approved messages are the speed gain in the first hour of a crisis.
• Single voice (single source of truth). The discipline that the organisation speaks with one voice across all channels and all audiences on a given disruption, with internal consistency between what the CEO tells the board, what the call-centre tells the customer, what the press release tells the media, and what the rumour-control response tells social media. Single-voice discipline is the antidote to the cascading inconsistency that destroys credibility.
• RTO and RPO for communication. The recovery-time objective and recovery-point objective for the communication system itself, how quickly must communication be restored after a primary-channel failure (RTO), and how much communication state can be lost (RPO). These metrics belong to the Channel Architecture design and are tested during the crisis-communication exercise.

Relationship to Other Clauses and Frameworks

Inside ISO 22301:2019

Clause 7.4 is one of five support sub-clauses and the only one whose output (information flow) touches every other clause. The relationship pattern:

The cross-framework map (summary)

Section 16 covers the multi-framework map in depth. The headline anchors:

• ISO/IEC 27001:2022 Clause 7.4 (Communication), the direct ISMS analogue. Useful for integrated audits.
• ISO/IEC 27001:2022 Annex A control 5.29 (information security during disruption), 5.30 (ICT readiness for business continuity), 8.13 (information backup), 8.14 (redundancy of information processing), the continuity controls whose communication angles 7.4 covers.
• NIST SP 800-34 Rev 1, the seven-step contingency planning process includes the communication elements (notification, activation, operations, reconstitution).
• NIST SP 800-61 Rev 2, the canonical incident-handling reference, including the incident-communication pitfalls.
• NIST CSF 2.0 Recover function Communicate category (RC.CO), the cleanest restatement of the bidirectional principle.
• FFIEC BCM Booklet (Nov 2019), the US banking-regulator reference for communication in BCM.
• DORA Regulation (EU) 2022/2554 (applies 17 January 2025), Articles 17 to 23 (incident reporting) and Article 26 (TLPT communication) cover the communication discipline for EU financial entities and their critical ICT service providers. Indian firms serving EU financial clients inherit DORA through contractual flow-down.
• APRA CPS 230 (effective 1 July 2025), paragraphs 41 to 43 (incident notification, business continuity, exercise) carry the communication expectations for APRA-regulated entities. Indian firms with Australian financial-sector exposure should align.
• MAS TRM Guidelines, the Singapore banking-regulator reference.
• HKMA TM-G-2 / SA-2, the Hong Kong banking-regulator reference.
• SOC 2 (Availability criterion), communication of availability incidents to affected customers is a SOC 2 control common to Indian SaaS firms.
• RBI Master Direction IT Governance (7 Nov 2023), the live BFSI instrument, with board and customer communication expectations.
• RBI Cyber Security Framework (2 Jun 2016), incident reporting to RBI within two to six hours; customer awareness communication.
• RBI MD Outsourcing of IT Services (10 Apr 2023), outsourcer communication and escalation must meet RE standards.
• SEBI CSCRF (20 Aug 2024), six-hour reporting clock for SEBI-RE cyber incidents, customer communication on incidents.
• SEBI MII BCP-DR (22 Mar 2021), mandatory MII communication to members and participants during disruption.
• IRDAI Information and Cyber Security Guidelines (24 Apr 2023), board-approved communication plan, policyholder communication.
• CERT-In Directions (28 Apr 2022), the six-hour clock; the PoC; the reportable categories; the 24x7 contactability.
• DPDP Act 2023 Section 8(6), the seventy-two-hour breach-notification clock.
• Companies Act 2013 Section 134(3)(n), board risk-statement communication.
• SEBI LODR Regulation 30, material-event disclosure for listed entities.
• NDMA DM Act 2005, public communication, Do's-and-Don'ts, coordination with district and state authorities.

Detailed Implementation Guidance, The Six-Phase Crisis-Communication Lifecycle

Figure · Process

What Clause 7.4 asks you to do

The implementation of Clause 7.4 is best organised around a six-phase lifecycle that spans the routine and the crisis regimes. The lifecycle is the operating model for the BCM Communication Procedure (toolkit document 02) and the structural backbone of the BCM Communication Programme.

The six phases are: (1) Design the communication portfolio; (2) Deliver the routine communication; (3) Activate the crisis-communication lifecycle on trigger; (4) Sustain the crisis communication through response, recovery and resume; (5) Close the crisis communication and transition back to routine; (6) Learn from the event and feed corrective action. The first two phases operate continuously; the last four operate during and after a BCMS-relevant disruption. The lifecycle is not a one-way pipeline, phase 6 (Learn) feeds phase 1 (Design), which is the continual-improvement loop of Clause 10.2 applied to communication.

Phase 1, Design the communication portfolio

The Design phase produces the artefacts that make the rest of the lifecycle possible. The minimum artefact set:

Artefact 1.1, BCM Communication Policy. The apex document, approved by top management, that commits the organisation to the four decisions (what, when, with whom, how), to the bidirectional principle, to the regulator clocks, to the spokesperson discipline, and to the continual improvement of communication. The policy is short, typically two to four pages, and references the Procedure, the Audience and Stakeholder Map, the Channel Architecture, the Regulator-Clock Matrix, the Holding-Statement Library, the Spokesperson Discipline Charter, and the Communication KPI Dashboard. The policy is reviewed at least annually and on trigger events (regulator change, sector change, post-disruption, post-exercise).

Artefact 1.2, BCM Communication Procedure. The operating procedure that defines the six-phase lifecycle, the roles, the channels, the evidence requirements, the escalation paths, the exercise cadence, the audit and review cycle, and the integration with the BCM Programme Procedure (Clause 8.1), the HR procedures, the corporate-communications procedures, the customer-communication procedures, the legal procedures, and the incident-response procedures. The Procedure is the working document the BCM Manager uses to run the communication programme; it should be detailed enough that a new BCM Manager can pick it up and operate.

Artefact 1.3, Audience and Stakeholder Map. The named, owner-attributed, channel-mapped, clock-bound list of the eleven canonical audiences (Section 2.1, Decision 3) plus any organisation-specific additions. For each audience, the Map records: a description; the named owner (the role responsible for the relationship with that audience); the named deputy; the channels used; the clocks that apply; the multilingual requirement; the accessibility requirement; the two-way feedback path; the evidence retention rule. The Map is the working artefact that turns the four decisions into per-audience action.

Artefact 1.4, Communication Requirements Matrix. The per-audience, per-phase, per-trigger translation of the four decisions into a deliverable plan. Rows are audiences (or audience sub-segments); columns are the routine-cadence triggers (policy publication, awareness cycle, exercise calendar, lessons-learned cycle) and the crisis triggers (warning, alert, invocation, status update, regulator clock, customer update, public update, rumour response, all-clear, post-disruption). Each cell records the content, the channel, the timing, the owner, the deputy, the evidence captured, and the two-way feedback expectation. The Matrix is the working artefact the BCM Manager and the communicators use day-to-day.

Artefact 1.5, Channel Architecture. The description of every channel the organisation uses for BCMS communication, with the channel family, the primary use case, the audience reach, the redundancy design (primary, secondary, out-of-band), the failure mode, the recovery objective (RTO and RPO for the channel itself), the access control, the evidence logging, the multilingual capability, the accessibility capability, and the cost. The Channel Architecture is the working artefact the IT DR, the SOC and the BCM team use to design the channel tests and the channel failover.

Artefact 1.6, Regulator-Clock Matrix. The single most important compliance artefact in the 7.4 portfolio. For each regulator the organisation is subject to (CERT-In, RBI, SEBI, IRDAI, DPDP via the Data Protection Board, NCIIPC, MCA, NDMA, sector-specific), the Matrix records: the trigger (what event starts the clock); the clock (the time bound); the recipient (the regulator's portal, email, fax, phone, the specific contact); the form (the prescribed format of the notification, many regulators publish a template); the channel (the prescribed channel, portal upload, email, fax); the owner (the role responsible for filing); the deputy; the evidence required (proof of filing, the regulator's acknowledgement); the dependencies (which other internal workflows must fire before the regulator notification can be filed, for example, the SOC detection, the CISO classification, the Legal review, the CEO sign-off); the rehearsal cadence (typically at least annually, integrated with the crisis-communication exercise). The Regulator-Clock Matrix is the artefact the auditor will spend most time on; a clean Matrix is the single strongest signal of 7.4 conformity.

Artefact 1.7, Holding-Statement Library. A library of pre-approved first-hour statements, one per disruption class the BIA identifies (typically: ransomware, data breach, fire, flood, cyclone, earthquake, supplier failure, key-person loss, payment outage, industrial accident, civil unrest, pandemic, power outage, telecommunication outage, regulatory investigation, product recall). Each statement is short (typically 100 to 250 words), acknowledges the event in non-committal language, identifies the spokesperson, identifies the next-update time, directs the audience to verified sources, and avoids admitting facts that have not been verified. Each statement has been pre-approved by Legal, by Corporate Communications, and by the relevant executive, so that the first hour of a crisis does not require a multi-party drafting meeting.

Artefact 1.8, Spokesperson Discipline Charter. The document that defines who may speak on the record, on what topics, on what authority, on which channels, with what message discipline, and how questions outside the spokesperson's brief are routed. The Charter names the primary spokesperson (usually the CEO for severe incidents), the secondary spokespersons (Head of Corporate Communications, Head of Customer Experience, CISO, Company Secretary, BCM Manager), the deputies, the media-training requirement, the message-discipline requirement (single voice, no speculation, no admission of fault pending investigation, no comment on rumour), the routing rule (any question outside the brief is taken off-line and answered in writing after Legal review), and the post-event review of spokesperson performance.

Artefact 1.9, Rumour-Control and Social-Listening Design. The document that defines the tools (commercial social-listening platforms, in-house monitoring, partner-provided monitoring), the sweeps (continuous for major incidents, daily for routine, weekly for the baseline), the sentiment analysis, the rumour-response escalation, the single-voice enforcement, the legal-action thresholds (for defamatory or market-manipulative content), and the post-event review of rumour-control performance. The Design is increasingly central as social and messaging platforms outpace official communication.

Artefact 1.10, Two-Way Feedback Architecture. The document that defines, per audience, the verified inbound path, the workforce hotline, the customer complaint and enquiry route, the supplier escalation route, the regulator response channel, the public enquiry line, the family-notification inbound route. The Architecture records the channel, the responder, the response-time target, the escalation path, the evidence capture, and the integration with the corrective-action workflow (Clause 10.1). The bidirectional principle is only as strong as the inbound path the organisation actually operates.

Artefact 1.11, Multilingual and Accessibility Plan. The document that defines, per work location and per audience, the languages used for BCMS communication, the translation and localisation workflow, the accessibility provisions (sign-language interpreters at briefings, screen-reader-compliant content, easy-read versions, multilingual IVR, regional-language SMS and printed material), and the production cadence. The Plan reflects the language diversity of the Indian workforce and customer base (Section 7.7).

Artefact 1.12, Communication KPI Dashboard. The dashboard that reports the communication KPIs (Section 12) to the BCM Steering Committee, the Board Risk Committee, and the regulators as required. The Dashboard is fed by the evidence captured per communication event and per exercise.

The Design phase is the longest of the six phases, typically four to eight weeks for a growing company, longer for a multi-entity enterprise, because the artefacts are interdependent and require cross-functional alignment. Skipping the Design phase and jumping to delivery is the most common implementation failure mode; the artefacts exist somewhere, in someone's drive, with no ownership, no integration, no rehearsal.

Phase 2, Deliver the routine communication

The Deliver phase operates continuously. Its cadence is the rhythm of the routine BCMS communication, the policy publication cycle, the awareness cycle, the exercise cycle, the lessons-learned cycle, the board and steering-committee cycle.

Routine deliverables. The communication events that fire on cadence: the annual (or triggered) BC policy publication; the quarterly awareness micro-learning drops; the monthly BCM team stand-up cascade; the monthly KPI dashboard to the Steering Committee; the quarterly crisis-communication tabletop; the annual crisis-communication simulation; the half-yearly board BCM briefing; the annual lessons-learned communication to the workforce; the supplier communication cycle (annual BCP-attestation requests, quarterly supplier check-ins); the customer communication cycle (annual BCP summary for key accounts, quarterly uptime report for SLA-bound customers); the regulator engagement cycle (the routine compliance filings, the routine regulator meetings).

Routine evidence. Every routine communication event is logged: the trigger, the audience, the channel, the content (or a reference to the content retained under Clause 7.5), the time, the sender, the delivery confirmation (where the channel supports it), the two-way feedback captured (where the channel supports it), the corrective action opened (where the feedback indicates a gap).

Routine integration. The routine communication is integrated with the broader corporate cadence, the all-hands, the customer newsletter, the supplier portal, the intranet. Integration avoids the "BCM communicates only when there's a crisis" pattern, which is the surest way to ensure the workforce tunes out BCM communication when a crisis does arrive.

Phase 3, Activate the crisis-communication lifecycle

The Activate phase fires on a trigger, typically a detection event at the SOC, a notification from a supplier, a physical incident at a site, a regulator inquiry, or a media report that requires a response. The activation sequence:

Step 3.1, Trigger identification. The trigger is identified and classified by the on-duty responder, typically the SOC analyst for cyber triggers, the site supervisor for physical triggers, the customer-service lead for customer-reported triggers, the corporate-affairs lead for media-reported triggers. The classification rule is conservative: when in doubt, trigger.

Step 3.2, Notification of the BCM Manager and the CMT Chair. The trigger is escalated immediately to the BCM Manager (the on-call BCM contact) and the CMT Chair. The escalation includes the trigger description, the time of detection (which starts several regulator clocks), the immediate assessment, and the recommended activation level.

Step 3.3, Activation decision. The CMT Chair makes the activation decision, typically a tiered model (Level 1 minor, Level 2 moderate, Level 3 major, Level 4 severe/catastrophic) with named authorities, named responders, and named escalation paths per level. The activation decision is the first formal communication of the crisis.

Step 3.4, First-hour communication. Within the first hour of activation, the organisation issues: (a) the internal alert to the workforce on the affected sites and the response teams; (b) the first regulator notification if a clock is running (CERT-In within six hours for prescribed cyber incidents, but the six-hour clock starts at notice, not at activation, so the first CERT-In notification may be due before the activation meeting ends); (c) the customer holding statement if customers are or may be affected; (d) the supplier notification if critical suppliers need to act; (e) the media holding statement if the event is or may become public; (f) the board notification if the activation level requires it. The first-hour communication is where pre-approved messages and rehearsed workflows earn their keep.

Step 3.5, Two-way feedback activation. The inbound channels, workforce hotline, customer escalation, supplier escalation, are activated or reinforced. The two-way feedback is logged and routed to the CMT.

The Activate phase is the most time-pressured phase and the phase where the Design phase's pre-work pays off. An organisation that has not pre-approved its holding statements, not rehearsed its regulator-clock workflow, not designated its spokespersons, and not tested its channels will spend the first hour improvising, and the first hour is what the regulator, the customer, the media and the workforce remember.

Phase 4, Sustain the crisis communication

The Sustain phase operates throughout the response, recovery and resume. Its cadence is the rhythm of the crisis communication, typically hourly updates internally during a Level 3 or Level 4 activation, every two-to-four hours externally, and at every regulator-clock deadline.

Sustain deliverables. Status updates on the defined cadence; regulator notifications at every clock deadline (CERT-In's six-hour clock for the initial notification; CERT-In's subsequent reporting expectations as the incident develops; RBI's two-to-six-hour incident reporting and the follow-up reporting; SEBI's six-hour clock for MII cyber incidents; DPDP's seventy-two-hour clock for personal-data breaches and the follow-up notifications to the Data Protection Board and the affected Data Principals); customer updates on the cadence the SLA or the customer-experience lead requires; supplier coordination throughout the response; media briefings at the cadence the spokesperson and the corporate-affairs lead determine; social-listening and rumour-control sweeps continuously; board updates at every significant change in the activation level; family-notification workflow if the event involves workforce safety.

Sustain evidence. Every communication event is logged in the evidence record, the trigger, the audience, the channel, the content, the time, the sender, the delivery confirmation, the two-way feedback, the corrective action opened. The evidence record is the source of truth for the post-disruption review and for the regulator and the auditor.

Sustain discipline. The single-voice discipline is enforced, the CEO, the call-centre, the press release, the social-media response and the rumour-control response all carry the same verified facts. The spokesperson discipline is enforced, no on-the-record comment outside the brief, no admission of fault pending investigation, no speculation. The clock discipline is enforced, every regulator deadline is tracked, every notification is filed within the clock, every late notification is documented with the reason and the corrective action.

Phase 5, Close the crisis communication

The Close phase fires when the disruption is resolved, the IT system is restored, the site is reopened, the supplier is back, the workforce is safe, the customer is whole. The close sequence:

Step 5.1, All-clear communication. The internal all-clear to the workforce and the response teams; the external all-clear to the customers, the public, and (where required) the regulator.

Step 5.2, Final regulator notifications. The final regulator report where required (CERT-In's incident-closure report, RBI's post-incident report, SEBI's post-incident report, IRDAI's post-incident report, DPDP's breach-closure report).

Step 5.3, Transition back to routine. The transition of the communication cadence from the crisis rhythm back to the routine rhythm. The two-way feedback channels remain open for the post-disruption enquiries.

Step 5.4, Communication-evidence close. The evidence record is closed, reviewed, and retained per Clause 7.5. The close is itself logged.

Phase 6, Learn

The Learn phase is the post-disruption review applied to communication. It feeds Clause 10.1 (corrective action) and Clause 10.2 (continual improvement).

Learn deliverables. A post-disruption communication review, what was sent, when, to whom, on what channel, with what content; what worked, what did not; what feedback was received and how it was actioned; what the regulator, the customer, the media, the workforce, the supplier, the board experienced; what the root causes of any communication failure were; what corrective actions are required; what the improvement opportunities are. The review feeds the corrective-action register and the next Design phase iteration.

Learn discipline. The post-disruption communication review is itself a communication event, the findings are communicated to the workforce (anonymised where appropriate), to the board, to the steering committee, and (where appropriate) to the customer, the regulator and the public. The learnings feed the next iteration of the Audience and Stakeholder Map, the Channel Architecture, the Regulator-Clock Matrix, the Holding-Statement Library, the Spokesperson Discipline Charter, and the KPI Dashboard.

The multilingual and field-force design (the Indian context)

The multilingual and field-force design is the single most under-served area of 7.4 implementation in the Indian growing-company segment. The default, English-language, intranet-based, email-centric communication, fails the majority of the Indian workforce and customer base, and fails absolutely the field force.

The multilingual workflow. A defensible multilingual workflow: (a) identify the working languages at each work location (typically English plus the state language, plus any migrant-workforce language); (b) translate the BC policy, the key awareness materials, the holding statements, the call-centre scripts and the customer-facing materials into the working languages; (c) verify the translations with native-speaker reviewers (machine translation is a starting point, not an ending point); (d) deliver the multilingual content through the channels the audience uses (regional-language SMS, regional-language IVR, regional-language printed material, regional-language signage, regional-language voice briefings); (e) measure comprehension (not just delivery), a regional-language workforce that received the message but did not understand it is a communication failure.

The field-force design. A defensible field-force design: (a) identify the field-force population and their access patterns (most field workers use personal smartphones on consumer mobile networks, not corporate devices on corporate networks); (b) deliver BCMS communication through the channels the field force uses (typically WhatsApp Business, SMS, voice calls, regional-language short videos); (c) verify reach through confirmation mechanisms (the WhatsApp Business read receipt, the SMS delivery report, the call-centre confirmation call); (d) design the field-force two-way feedback path (a toll-free number, a chatbot, a field-force escalation route through the reporting manager); (e) test the field-force communication in the exercise programme, the most common field-force communication failure is the assumption that "we sent it, so they got it".

The accessibility design. A defensible accessibility design: (a) sign-language interpreters at town halls and briefings (the RBI and SEBI cyber-awareness materials and the NDMA Do's-and-Don'ts materials include Indian Sign Language versions, usable as references); (b) screen-reader-compatible content for the visually impaired workforce (the corporate intranet and the mass-notification system should be WCAG 2.1 AA compliant); (c) captioning and transcripts for video content; (d) easy-read versions for the cognitively diverse workforce; (e) multilingual IVR for the customer base; (f) alternative-format printed material (large print, Braille where the workforce or customer base requires).

The channel-redundancy and out-of-band architecture

The Channel Architecture must specify primary, secondary and out-of-band channels for each audience, because the channel that works on a normal day is often the channel that fails on a bad one. The failure modes to design for:

• Email failure. Ransomware encrypts the email server or the endpoint; the cloud-email provider has an outage; the email security gateway misclassifies the crisis communication as phishing. Secondary: mass-notification system, secure messenger. Out-of-band: SMS blast, voice call.
• Intranet failure. The intranet is on the same network as the affected systems; the intranet authentication fails; the intranet CMS is down. Secondary: mass-notification system, mobile workforce app. Out-of-band: printed notice on noticeboards, public-address announcement.
• Mobile network failure. The mobile network is oversubscribed during a major event (the classic "network congestion" pattern during a disaster); the mobile network tower is itself affected by the disruption (fire, flood, power). Secondary: alternate mobile carrier (the organisation should not depend on a single carrier); satellite phone. Out-of-band: runner, hard-line phone, two-way radio.
• Telephony failure. The PBX is on the affected network; the call-centre provider has an outage; the IVR misroutes calls. Secondary: alternate call-centre (geographically diverse); voice over LTE on the alternate carrier. Out-of-band: chat, email, in-person at the site.
• Internet failure. The corporate internet circuit is on the affected network; the ISP has an outage; the DNS is misconfigured. Secondary: alternate ISP (the organisation should have at least two diverse ISP feeds at every critical site); cellular backup (4G/5G router with sufficient data allowance). Out-of-band: satellite, offline plans.
• Power failure. The site power is down; the UPS runtime is exceeded; the generator fails. Secondary: generator (with tested fuel supply and tested switchover); battery backup for the communication infrastructure specifically (the mass-notification system, the call-centre, the SOC). Out-of-band: evacuation to the alternate site with its own power.

The out-of-band channel design is the resilience layer. An organisation that has not tested the out-of-band paths in the exercise programme will discover at the worst possible moment that the satellite phone's battery is flat, the runner does not know the alternate site's address, and the two-way radio's frequency is not licensed.

The spokesperson and message-discipline design

The spokesperson discipline is the difference between a credible crisis response and a damaging one. The design:

The spokesperson tier. The primary spokesperson for severe incidents is typically the CEO or the Managing Director. The secondary spokesperson for moderate incidents is typically the Head of Corporate Communications or the Head of Customer Experience. The technical spokesperson for incident-update communication is typically the CISO, the CIO, or the BCM Manager. The regulatory spokesperson for regulator communication is typically the Company Secretary or the CISO. The deputy spokespersons are named and media-trained.

The message-discipline rule. Every spokesperson operates within the single-voice discipline: the organisation speaks with one voice; the facts are verified before they are communicated; the message is consistent across channels and audiences; the spokesperson does not speculate; the spokesperson does not admit fault pending investigation; the spokesperson does not comment on rumour; the spokesperson routes off-brief questions off-line and answers them in writing after Legal review. The discipline is reinforced by the holding-statement library, the pre-approved messages, and the spokesperson's media training.

The media-training requirement. Every spokesperson is media-trained, on-camera interview practice, message-discipline practice, hostile-question practice, social-media practice, rumour-response practice. The media training is refreshed at least annually and on role-change.

The spokesperson-evidence requirement. Every spokesperson appearance is logged, the outlet, the journalist, the topic, the time, the location, the message delivered, the questions asked, the off-brief questions routed, the next-step commitments. The log is retained under Clause 7.5.

The rumour-control and social-listening design

Rumour control is no longer a nice-to-have. The speed of unofficial communication on social and messaging platforms outpaces the speed of official communication, and the volume of misinformation during a major incident can drown the organisation's voice. The design:

The social-listening tools. Commercial social-listening platforms (typically SaaS, with Indian-data-residency options) provide continuous monitoring of mentions, sentiment, and emerging narratives across the major platforms (X, Facebook, Instagram, LinkedIn, YouTube, Reddit, the regional-language platforms). In-house monitoring (Google Alerts, platform-native alerts, manual sweeps) is the lower-cost option for smaller organisations. Partner-provided monitoring (the PR partner, the cyber-insurance's breach-response partner, the corporate-affairs consultancy) is the higher-cost option for major incidents.

The sweeps. Continuous monitoring during a major incident; daily monitoring during a moderate incident; weekly monitoring at the baseline. The sweep findings are routed to the CMT and to the rumour-response owner (typically the Head of Corporate Communications).

The rumour-response escalation. A confirmed rumour (verified false or misleading content that is gaining traction) triggers the rumour-response workflow: identify the source, assess the reach, draft the response (using the pre-approved rumour-response template), route through the single-voice discipline, publish on the official channel, monitor the response's effect, escalate to Legal if the content is defamatory or market-manipulative.

The single-voice enforcement. The rumour response is consistent with the spokesperson's on-record statements, the press release, the customer communication and the regulator notification. Inconsistency between the official channels and the rumour-response channel destroys credibility and creates new rumours.

The legal-action threshold. Defamatory content (false statements of fact that harm the organisation's reputation) and market-manipulative content (false statements intended to move the share price, for listed entities) may warrant legal action, typically a takedown request to the platform, a cease-and-desist letter to the originator, or a regulator referral (SEBI for market manipulation). The threshold and the action are defined in the Rumour-Control Design and pre-approved by Legal.

The bidirectional principle in practice

The bidirectional principle, that every audience has a verified inbound path, is the most often skipped design element and the most often cited audit failure. The inbound paths:

• Workforce inbound. A workforce hotline (toll-free, multilingual, 24x7 during activation, business-hours at baseline), an escalation route through the reporting manager, a "report-a-concern" channel (anonymous if the regulator or the culture requires), a town-hall Q&A, a post-incident survey.
• Customer inbound. The customer complaint and enquiry route (call-centre, email, chat, app, social-media DM, in-person at the branch or the site), the customer escalation route (the nodal officer under the RBI Integrated Ombudsman Scheme for BFSI; the IRDAI grievance redressal nodal officer for insurance; the consumer forum for general consumer protection), the post-incident customer survey.
• Supplier inbound. The supplier escalation route (the supplier-relationship manager, the procurement helpdesk, the supplier portal's escalation form), the joint-incident coordination call, the post-incident supplier review.
• Regulator inbound. The regulator's response channel (the regulator's portal, the regulator's email, the regulator's phone, used for the regulator's follow-up enquiries, requests for information, and on-site inspections).
• Public inbound. The public enquiry line, the corporate-website incident page's contact form, the social-media DM, the press enquiry route.
• Family inbound. The family-notification hotline (a dedicated number activated during a workforce-safety event), the family-liaison officer (a named HR contact for the affected family).

The inbound path is logged, the response time is measured, the resolution is tracked, and the corrective action is opened where the inbound indicates a systemic gap. A workforce that has flagged the same issue through the hotline three months in a row and has seen no action is a workforce that will stop using the hotline, and the organisation will lose its two-way feedback loop.

Integration with the broader BCM programme

The 7.4 lifecycle does not run in isolation. It integrates with:

• The BCM Programme Procedure (Clause 8.1), the operating model for the BCM programme as a whole.
• The HR procedures, for the workforce communication channels, the family-notification workflow, the disciplinary communication following a BCMS breach.
• The corporate-communications procedures, for the public-facing channels, the media relationships, the press release process.
• The customer-communication procedures, for the customer channels, the SLA-bound uptime reporting, the customer-incident communication.
• The legal procedures, for the regulator-clock workflow, the disclosure obligations, the litigation hold, the contract communication with critical suppliers and customers.
• The incident-response procedures, for the cyber-incident communication flow, the SOC-to-CMT escalation, the regulator notification workflow.
• The exercise programme (Clause 8.5), the crisis-communication exercise is part of the BCM exercise programme.
• The internal-audit programme (Clause 9.2), the communication discipline is sampled annually.
• The management-review cycle (Clause 9.3), the communication portfolio is reviewed at every management review.

The integration is the difference between a 7.4 system that operates and a 7.4 system that is documented.

Tools, Technologies, and Solutions

The 7.4 toolset falls into seven categories. The selection should be driven by the Audience and Stakeholder Map and the Channel Architecture, not by vendor marketing. Illustrative cost ranges are third-party list-price or India-market estimates as of mid-2026; they are not Singahi pricing and should be re-verified at the time of purchase.

Mass-notification systems

Mass-notification systems deliver messages to large numbers of recipients simultaneously across multiple channels (email, SMS, voice, app push, social), with delivery confirmation, response capture and audit logging. They are the workhorse of the broadcast channel family.

• Global enterprise platforms, typically SaaS, with global infrastructure and Indian-data-residency options via partners. Feature set: multi-channel delivery, two-way response, conference-bridge launch, evidence logging, scenario templates, multilingual message support. Indicative cost: USD 8 to USD 30 per user per year for the enterprise tier; lower-tier plans from USD 3 per user per year. The India-cross-border data-residency question should be confirmed for each vendor under DPDP.
• India-headquartered SaaS platforms, feature set typically matches the global mid-tier, with Indian data residency by default, regional-language message support, and integrations with Indian telecom carriers. Indicative cost: INR 200 to INR 1,500 per user per year depending on feature tier and message volume.
• Carrier-provided solutions, the Indian mobile carriers offer enterprise-SMS, enterprise-voice, and RCS (Rich Communication Services) platforms; these are useful for high-volume, low-cost broadcast but typically lack the scenario-template and evidence-logging features of a dedicated mass-notification system.
• WhatsApp Business API-based solutions, increasingly the channel of choice for the Indian workforce and customer base; the WhatsApp Business API supports template messages, session messages, interactive messages, and two-way communication, with delivery and read receipts. The platform is suitable for both routine and crisis communication; the design should address the WhatsApp message-template approval cadence (templates must be pre-approved by Meta, which is a constraint on holding-statement deployment speed).

Crisis-communication and incident-management platforms

The crisis-communication platform category overlaps with the incident-management platform category; many vendors offer both. Feature set: incident logging, severity classification, role-based activation, secure incident bridge, task management, evidence capture, regulator-notification templates, post-incident review workflow. The platforms integrate with the mass-notification system and with the ITSM and SOAR platforms.

• Global enterprise platforms, feature-rich, with the deepest regulator-template libraries for global financial regulators (DORA, FFIEC, FCA, MAS, HKMA); the Indian regulator templates (CERT-In, RBI, SEBI, IRDAI) are typically less well-covered and require customisation. Indicative cost: USD 50 to USD 200 per user per year for the enterprise tier.
• India-headquartered platforms, feature set matches the global mid-tier, with Indian regulator templates pre-built; particularly strong in the BFSI vertical.
• BCM-suite-embedded communication, the BCM/IRM platforms (a category that includes the global GRC platforms with BCM modules) embed crisis communication within the BCM workflow, with the strength of single-source-of-truth evidence and the weakness of higher total cost and slower deployment.

Social-listening and rumour-control platforms

Social-listening platforms monitor mentions, sentiment, and emerging narratives across the major platforms; they feed rumour control and reputation management.

• Global platforms, broadest platform coverage (including the global platforms with significant Indian audience, X, Facebook, Instagram, LinkedIn, YouTube, Reddit); Indian regional-language sentiment analysis is typically weaker.
• India-focused platforms, stronger coverage of the Indian regional platforms and the regional-language sentiment; the global platform coverage is typically via partnership rather than direct.
• In-house monitoring, for smaller organisations, a combination of Google Alerts, platform-native alerts, and manual sweeps may be sufficient; the discipline is the response workflow, not the tool.

Customer-communication platforms (CCM and CXM)

Customer-communication management (CCM) and customer-experience management (CXM) platforms deliver the routine and crisis communication to customers across email, SMS, voice, app push, web banner, chat, social-media, and printed channels. They are the customer-channel workhorses.

• Global CXM platforms, feature-rich, with the deepest integration with the major CRMs and the deepest personalisation; the India-data-residency and DPDP-compliance question should be confirmed for each vendor.
• India-headquartered CXM platforms, feature set matches the global mid-tier, with Indian data residency, regional-language support, and Indian-telecom-carrier integration.
• In-house customer-communication stacks, many BFSI and SaaS firms have built in-house customer-communication stacks on top of their CRM; the BCMS question is whether the stack has a crisis-communication mode (template override, channel-priority override, evidence-logging override).

Workforce-communication platforms (intranet, ECP, mobile workforce apps)

The workforce-communication platform category includes the intranet, the employee-communication platform (ECP), the mobile workforce app, and the workforce-collaboration platform (typically enterprise collaboration suite or collaboration platform for the desk workforce, and WhatsApp Business for the field workforce).

• Intranet and ECP, the primary channels for routine workforce communication; the BCMS question is whether the intranet has a crisis-communication mode (banner override, message-priority override, evidence-logging override) and whether the intranet is itself resilient (hosted away from the corporate network, accessible from outside the corporate firewall).
• Mobile workforce app, increasingly the channel of choice for the deskless workforce; the BCMS question is whether the app has push-notification capability, offline content caching, two-way feedback, and multilingual support.
• Workforce-collaboration platform, the day-to-day collaboration channel; the BCMS question is whether the platform is available during a corporate-network outage (typically yes for cloud-hosted platforms, with the caveat that the corporate authentication may itself be the failure point, design for alternative authentication).

Regulator-notification platforms

The regulator-notification platform category includes the regulator-operated portals and the third-party platforms that facilitate regulator notification.

• CERT-In, the CERT-In portal and the CERT-In PoC email are the primary channels; the BCP-DR and incident-response practice should be familiar with both. Some categories of incident require telephone follow-up with the CERT-In 24x7 helpdesk.
• RBI, the RBI's supervisory portal (the COSMOS platform, the XBRL/COSMOS reporting platform, the supervisory-data-management platform depending on the entity type); the BFSI BCMS should map the regulator-notification channels for each reportable event.
• SEBI, the SEBI complaint-and-reporting portals (the SEBI Intermediary Portal, the SCORES platform for investor complaints, the SEBI CSCRF reporting portal for cyber incidents); the SEBI-regulated BCMS should map the regulator-notification channels for each reportable event.
• IRDAI, the IRDAI portal (the BAP system, the IRDAI Integrated Portal); the insurance BCMS should map the regulator-notification channels.
• DPDP / Data Protection Board, the Data Protection Board's notification portal (prescribed under the DPDP Rules 2025); the Data Fiduciary BCMS should map the breach-notification channel.
• NCIIPC, for Critical Information Infrastructure operators, the NCIIPC reporting channel.
• NDMA / State / District disaster-management authorities, for industrial and physical-disaster scenarios, the coordination channels with the district and state disaster-management authorities.

Spokesperson and media-training services

The spokesperson and media-training service category includes the PR consultancies, the corporate-affairs consultancies, the media-training firms, and the crisis-communications specialists.

• Global crisis-communications consultancies, the deepest bench of senior practitioners and the deepest global media relationships; the highest retainer cost; typically engaged on retainer for major-incident response only.
• India-headquartered corporate-affairs consultancies, strong Indian media relationships, strong regulator-engagement relationships, regional-language capability; the typical choice for an Indian growing company.
• Media-training firms, the on-camera practice, the message-discipline practice, the hostile-question practice; the training is typically a one-to-three-day intensive per spokesperson, refreshed annually.
• Cyber-insurance breach-response partners, many cyber-insurance policies include a breach-response partner (a PR consultancy, a law firm, a forensics firm) on standby; the partner is engaged at the insurer's discretion on report of an incident.

Selection criteria

The tool-selection criteria should be driven by the Audience and Stakeholder Map and the Channel Architecture, not by vendor feature parity. Useful criteria: Indian data residency and DPDP compliance; multilingual capability (the languages of the workforce and the customer base); accessibility capability; integration with the existing corporate stack (CRM, ITSM, SOAR, BCM, GRC); regulator-template library (the Indian regulators); evidence logging depth; deployment model (SaaS, on-premises, hybrid); total cost of ownership (licence, implementation, integration, training, support); vendor viability (financial stability, India presence, support hours, language coverage of the support team); audit-friendliness (does the tool's evidence log satisfy a Clause 9.2 internal-audit sample and a Clause 7.5 document-control review).

Policy and Procedure Templates

This section presents a sketch of the apex policy and the operating procedure. The full ready-to-customise templates are in the toolkit (documents 01 and 02).

BCM Communication Policy, sketch

Purpose. This Policy commits [Organisation] to a deliberate, decided, designed, delivered and evidenced approach to BCM communication, internally and externally, on the routine cadence and during disruption, that meets the requirements of ISO 22301:2019 Clause 7.4, the Indian regulatory instruments the organisation is subject to (including the RBI Master Direction on IT Governance, the RBI Cyber Security Framework in Banks where applicable, the SEBI Cybersecurity and Cyber Resilience Framework where applicable, the SEBI MII BCP-DR circular where applicable, the IRDAI Information and Cyber Security Guidelines where applicable, the CERT-In Directions of 28 April 2022, the Digital Personal Data Protection Act 2023 and the DPDP Rules 2025, the Companies Act 2013, the NDMA Disaster Management Act 2005, and the IT Act 2000), and the organisation's contractual and stakeholder obligations.

Scope. This Policy applies to all BCMS-relevant communication of [Organisation], routine and crisis, to all audiences, internal and external, through all channels, primary, secondary and out-of-band. This Policy is owned by the BCM Manager and approved by the Chief Executive Officer.

The four decisions. [Organisation] shall decide, for each BCMS-relevant audience and each BCMS-relevant content type: (a) what to communicate, the content set defined in the Communication Requirements Matrix; (b) when to communicate, the routine cadence and the crisis triggers defined in the Communication Requirements Matrix and the Regulator-Clock Matrix; (c) with whom to communicate, the audiences defined in the Audience and Stakeholder Map; (d) how to communicate, the channels defined in the Channel Architecture.

The bidirectional principle. [Organisation] shall maintain, for each BCMS-relevant audience, a verified inbound path through which the audience can respond, ask, confirm, flag or escalate. The bidirectional paths are defined in the Two-Way Feedback Architecture.

The regulator clocks. [Organisation] shall meet every regulator-clock obligation under the Regulator-Clock Matrix, CERT-In six hours from noticing for prescribed cyber incidents; RBI incident reporting per the 2016 cyber framework and the 2023 Master Direction; SEBI cyber-incident reporting per the 2024 CSCRF; IRDAI incident reporting per the 2023 guidelines; DPDP breach notification within seventy-two hours to the Data Protection Board and without delay to the affected Data Principals; and any sector-specific or jurisdiction-specific clock that applies to the organisation.

The spokesperson discipline. [Organisation] shall maintain a Spokesperson Discipline Charter naming the primary, secondary, technical and regulatory spokespersons, their authorities, and their message-discipline obligations. The Charter is approved by the Chief Executive Officer.

The holding-statement library. [Organisation] shall maintain a Holding-Statement Library covering each disruption class identified in the BIA, with statements pre-approved by Legal, Corporate Communications and the relevant executive, refreshed at least annually and after every activation.

The channel architecture. [Organisation] shall maintain a Channel Architecture with primary, secondary and out-of-band channels for each audience, with redundancy, accessibility, multilingual support, evidence logging, and tested failover.

The exercise programme. [Organisation] shall exercise the crisis-communication capability at least quarterly at the tabletop level, at least annually at the simulation level, and after every activation through a post-disruption review.

Roles and authorities. The BCM Manager is the custodian of the communication system. The Chief Executive Officer retains accountability for the spokesperson authority decision and for the disclosure decisions. The Head of Corporate Communications operates the public-facing channels. The Head of Customer Experience operates the customer channels. The Company Secretary operates the regulator-clock workflow. The CISO co-owns the cyber-incident communication. The Head of HR operates the workforce and family-notification channels. The DPO operates the DPDP breach-notification workflow. Functional heads operate the operational communication in their functions. Internal Audit independently tests the communication discipline.

Continual improvement. This Policy is reviewed at least annually and on trigger events (regulator change, sector change, post-disruption, post-exercise, organisational change).

BCM Communication Procedure, sketch

The Procedure operationalises the Policy through the six-phase lifecycle (Section 7). For each phase, the Procedure defines: the trigger, the inputs, the activities, the outputs, the roles, the evidence, the escalation paths, the integration with adjacent procedures, and the audit and review touchpoints. The Procedure is the working document the BCM Manager uses to run the programme; it is detailed enough that a new BCM Manager can pick it up and operate.

A defensible Procedure has the following section structure: purpose and scope; the six-phase lifecycle; the roles and authorities; the Audience and Stakeholder Map (with the eleven audiences named and owners assigned); the Communication Requirements Matrix; the Channel Architecture (with the channel tests defined); the Regulator-Clock Matrix (with the rehearsal cadence defined); the Holding-Statement Library (with the approval workflow defined); the Spokesperson Discipline Charter; the Rumour-Control and Social-Listening Design; the Two-Way Feedback Architecture; the Multilingual and Accessibility Plan; the Communication KPI Dashboard; the evidence and document-control requirements (under Clause 7.5); the exercise programme (under Clause 8.5); the audit and review cycle (under Clauses 9.2 and 9.3); the corrective-action workflow (under Clause 10.1); the integration map (with the adjacent procedures listed above).

Holding-statement library, starter set

A starter set of disruption classes for the Holding-Statement Library, with the structure of each holding statement: acknowledgement of the event in non-committal language; identification of the spokesperson and the next-update time; direction to verified sources; commitment to update; placeholder fields for event-specific details. The library should be customised to the organisation's sector, scope and stakeholders.

• Ransomware affecting operations, acknowledgement that the organisation is investigating a cyber incident affecting some systems; spokesperson; next-update time; verified-source channel; commitment to update customers, regulators and the public as the situation develops.
• Personal-data breach (DPDP-trigger), acknowledgement that the organisation has identified a personal-data breach affecting [category of Data Principals]; spokesperson; next-update time; commitment to notify the Data Protection Board within seventy-two hours and the affected Data Principals without delay; direction to the breach-response page.
• Payment-services outage, acknowledgement that the organisation is experiencing an outage affecting [payment service]; spokesperson; estimated restoration time; alternative channels (where applicable); commitment to update; customer-remedy commitment.
• Plant or site emergency, acknowledgement that an incident has occurred at [site]; spokesperson; status of emergency services; status of workforce safety; direction to the family-notification hotline; commitment to update.
• Natural-disaster activation, acknowledgement that the organisation has activated its BC plan in response to [event]; spokesperson; status of operations; status of workforce safety; customer-service arrangements; commitment to update.
• Supplier failure, acknowledgement that the organisation is experiencing disruption due to a third-party supplier incident; spokesperson; status of operations; alternative arrangements; commitment to update.
• Key-person loss, acknowledgement that the organisation has experienced the loss or serious illness of [role]; spokesperson; continuity arrangements; commitment to update.
• Industrial accident / environmental release, acknowledgement that an incident has occurred at [site] with [nature of release]; status of emergency services; status of workforce and community safety; direction to the public-safety instructions; commitment to update; cooperation with the regulator.
• Civil unrest / security incident, acknowledgement that the organisation is responding to a security situation at [location]; status of workforce safety; status of operations; direction to the family-notification hotline; commitment to update.
• Pandemic / public-health activation, acknowledgement that the organisation has activated its BC plan in response to [public-health event]; status of operations; workforce-safety arrangements; customer-service arrangements; commitment to update.
• Regulator investigation / inspection, typically a no-comment holding statement; the spokesperson confirms the regulator engagement and declines to comment on the substance pending the regulator's process.
• Product recall, acknowledgement that the organisation is initiating a voluntary recall of [product]; affected batches; consumer-safety instructions; refund or replacement arrangement; commitment to update.

Sample policy and contract "shall" clauses

The following are the author's own drafting, sample "shall" clauses that a growing company may use in its BCM Communication Policy (an internal document) and in its customer and supplier contracts. They are appropriate; only the standard's own clause text is paraphrased.

• Internal BCM Communication Policy sample shall clauses: "[Organisation] shall maintain a BCM Communication Policy approved by the Chief Executive Officer."; "[Organisation] shall maintain an Audience and Stakeholder Map naming the eleven canonical audiences and any organisation-specific additions."; "[Organisation] shall meet every regulator-clock obligation under the Regulator-Clock Matrix."; "[Organisation] shall issue a pre-approved holding statement within sixty minutes of activation of a Level 3 or Level 4 incident."; "[Organisation] shall exercise the crisis-communication capability at least quarterly at the tabletop level and at least annually at the simulation level."; "[Organisation] shall capture, retain and make available for audit a complete evidence record of every BCMS communication event."
• Customer MSAs (B2B SaaS / BFSI) sample shall clauses: "Vendor shall notify Customer within [clock, typically two hours for severity-1, four hours for severity-2] of becoming aware of any incident affecting the availability, confidentiality or integrity of Customer data or the service."; "Vendor shall provide Customer with a written incident report within [five business days] of incident closure, including root cause, impact, corrective action and the regulator notifications filed."; "Vendor shall not notify any regulator, the public or the media of an incident that identifies Customer without Customer's prior written consent, except where notification is required by law."
• Supplier / Outsourcing MSAs sample shall clauses (aligned to the RBI MD Outsourcing of IT Services, 10 April 2023): "Supplier shall maintain a BCM Communication Plan that meets the standards of [Organisation]'s BCM Communication Policy."; "Supplier shall provide a named 24x7 contact for incident communication."; "Supplier shall notify [Organisation] within [clock, typically one hour for critical services] of becoming aware of any incident affecting the service."; "Supplier shall cooperate with [Organisation]'s regulator-notification workflow and provide the information [Organisation] requires to meet its regulator-clock obligations."; "Supplier shall not notify any regulator, the public or the media of an incident that identifies [Organisation] without [Organisation]'s prior written consent, except where notification is required by law."
• Cyber-insurance loss-notification clause sample: "Insured shall notify the Insurer within [clock, typically forty-eight hours] of becoming aware of a cyber incident that may give rise to a claim under this Policy; Insured shall cooperate with the Insurer's appointed breach-response partner; Insured shall not admit liability, incur response cost without the Insurer's consent, or communicate publicly about the incident in a manner that prejudices the Insurer's position, except where required by law."

Risk Assessment and Treatment

The 7.4 risk register is a focused view of the enterprise risk register that lists the risks specifically affecting the BCMS communication discipline. It is owned by the BCM Manager, reviewed at least annually, and on trigger events (regulator change, sector change, post-disruption, post-exercise).

Communication risk categories

• Audience-coverage risk, the risk that an audience the organisation should be communicating with is not in the Audience and Stakeholder Map. The most common gaps in the Indian growing-company segment: the field force; the families of the workforce; the surrounding community at industrial sites; the smaller B2B customers without a dedicated account manager; the regulatory bodies whose jurisdiction the organisation falls under without realising (for example, the GST authorities for an e-commerce operator, the DGCA for a travel-tech firm, the EFSA-equivalent for a food-tech firm).
• Clock-adherence risk, the risk that a regulator clock is missed. The most common causes: the trigger is detected but the clock-start is not communicated to the owner; the owner is unreachable; the form is not pre-prepared; the channel is unfamiliar; the regulator's portal is down; the legal review runs late; the executive sign-off is unobtainable. Each cause maps to a treatment.
• Channel-failure risk, the risk that the primary channel fails on the day and the secondary or out-of-band channel is not designed, not tested, or not accessible. The most common failure pattern in the Indian growing-company segment: the primary channel is email; the secondary channel is the intranet; both fail simultaneously during a ransomware event.
• Message-accuracy risk, the risk that the message is wrong, wrong facts, wrong attribution, wrong admission, wrong tone, wrong language. Message accuracy is the discipline of pre-approved messages, single-voice enforcement, legal review, and post-event review.
• Spokesperson risk, the risk that the spokesperson is unprepared, off-brief, off-message, or off-the-record-when-they-meant-on-the-record. Spokesperson risk is the discipline of media training, message discipline, and the routing rule for off-brief questions.
• Rumour-amplification risk, the risk that the organisation's communication amplifies a rumour rather than correcting it (typically by denying it in a way that gives the rumour more oxygen, or by engaging publicly with bad-faith actors).
• Two-way-feedback-degradation risk, the risk that the two-way feedback path is degraded (the hotline is unanswered; the customer escalation route is misrouted; the supplier escalation is ignored) and the organisation loses its feedback loop.
• Multilingual-failure risk, the risk that the multilingual design fails, the regional-language message is poorly translated, the IVR misroutes, the field-force channel is down, the accessibility provision is missing.
• Evidence-gap risk, the risk that the communication evidence is not captured, is captured but not retained per Clause 7.5, or is captured but cannot be retrieved for audit or regulator enquiry.
• Reputational-amplification risk, the risk that the communication itself becomes the story, typically through a tone-deaf message, an insensitive timing (a customer-outage apology issued during a national mourning, for example), or a clumsy spokesperson appearance.
• Personal-liability risk, for senior managers under the Companies Act 2013 and the RBI senior-manager accountability regime, the risk that a communication failure is attributed personally to the CEO, the CFO, the CISO, the Company Secretary or the board.
• Concentration risk, the risk that the communication depends on a single person (the BCM Manager who is the only one who knows the mass-notification system), a single channel (the corporate mobile network), a single carrier, a single cloud, a single provider.

Treatment patterns

For each risk, the treatment pattern is documented in the register with: the risk description; the inherent likelihood and impact (1 to 5 scale); the treatment (the control or set of controls); the residual likelihood and impact; the treatment owner; the review date; the treatment effectiveness evidence. Typical treatments:

• For audience-coverage risk, the annual Audience and Stakeholder Map review, including a deliberate "who are we missing?" exercise with the BCM Steering Committee.
• For clock-adherence risk, the Regulator-Clock Matrix with the rehearsal cadence; the playbook for each clock; the deputy owner; the escalation path; the annual live regulator-clock exercise (a simulation of the full workflow from detection to filing within the clock).
• For channel-failure risk, the Channel Architecture with primary, secondary and out-of-band channels; the quarterly channel test (every channel tested end-to-end); the annual out-of-band test (satellite phone, runner, public-address).
• For message-accuracy risk, the pre-approved holding-statement library; the single-voice discipline; the legal review for non-pre-approved messages; the post-event message review.
• For spokesperson risk, the Spokesperson Discipline Charter; the annual media-training refresh; the post-event spokesperson review.
• For rumour-amplification risk, the Rumour-Control and Social-Listening Design; the rumour-response playbook; the legal-action threshold.
• For two-way-feedback-degradation risk, the Two-Way Feedback Architecture; the response-time targets per channel; the monthly review of feedback-handling performance.
• For multilingual-failure risk, the Multilingual and Accessibility Plan; the native-speaker verification of translations; the multilingual exercise scenarios.
• For evidence-gap risk, the Clause 7.5 document-control integration; the evidence-logging feature of every channel; the quarterly internal-audit sample of communication events.
• For reputational-amplification risk, the pre-approved message review by Corporate Communications; the timing-discipline rule (no customer-outage communication during a national mourning, for example); the post-event review.
• For personal-liability risk, the Directors-and-Officers insurance review; the senior-manager briefing cycle; the regulator-engagement cycle.
• For concentration risk, the deputy-owner rule for every critical communication role; the multi-carrier design for mobile communication; the multi-cloud or multi-region design for cloud-communication platforms; the multi-vendor design for the mass-notification system.

The risk register as a live document

The risk register is not a one-time artefact. It is reviewed at every BCM Steering Committee meeting (at least quarterly), at every Clause 9.3 management review, after every exercise (Clause 8.5), after every disruption (Clause 8.6), and on every regulator change. The risk register feeds the corrective-action register (Clause 10.1) and the continual-improvement pipeline (Clause 10.2).

Audit and Compliance Checklist

The 7.4 audit checklist below is suitable for both the internal audit (Clause 9.2) and the certification-audit self-assessment. Each item records the expected evidence and a red-flag indicator. The checklist is the working instrument the BCM Manager uses to prepare the audit; it is not a substitute for the underlying artefacts.

Documentation and policy

1. Is there a BCM Communication Policy approved by top management? Evidence: the signed policy with version, date, approver. Red flag: missing or unsigned; only the BCM Manager has signed; the policy is more than two years old.
2. Is there a BCM Communication Procedure operationalising the policy? Evidence: the procedure document with the six-phase lifecycle, roles, evidence, escalation. Red flag: missing; the procedure is aspirational; the procedure does not match the actual practice.
3. Is the Policy and Procedure reviewed at the defined cadence? Evidence: the review-cycle log with dates and reviewers. Red flag: no review record; the last review is more than a year old.
4. Is the Policy integrated with the BCMS Policy (Clause 5.2)? Evidence: cross-reference between the policies; consistent terminology; consistent authority structure. Red flag: the policies are inconsistent; the BCMS Policy does not mention communication; the BCM Communication Policy does not reference the BCMS Policy.

Audience and stakeholder map

5. Is the Audience and Stakeholder Map documented and complete? Evidence: the Map with the eleven canonical audiences named and owners assigned, plus any organisation-specific additions. Red flag: missing audiences (typically the field force, the families, the surrounding community); unnamed owners; no deputies.
6. Is the Map reviewed at the defined cadence and on trigger events? Evidence: the review log; the trigger-event log. Red flag: the Map has not been reviewed since creation; new audiences (post-acquisition, post-product-launch, post-sector-entry) have not been added.
7. Is each audience's two-way feedback path documented and operational? Evidence: the Two-Way Feedback Architecture; the response-time logs per channel. Red flag: no inbound path; the inbound path exists but the response time is unmeasured; the inbound path exists but is not monitored.

Communication requirements matrix

8. Is the Communication Requirements Matrix complete, per audience, per phase, per trigger? Evidence: the Matrix with content, channel, timing, owner, deputy, evidence, feedback for each cell. Red flag: the Matrix is a one-page summary; the Matrix has gaps (cells empty or marked TBD); the Matrix is not aligned with the Audience and Stakeholder Map.
9. Is the Matrix integrated with the BCM exercise programme (Clause 8.5)? Evidence: the exercise scenarios test specific Matrix cells; the exercise debrief feeds the Matrix revision. Red flag: the exercise programme does not test the Matrix; the Matrix and the exercise are independent documents.

Channel architecture

10. Is the Channel Architecture documented with primary, secondary and out-of-band channels for each audience? Evidence: the Architecture document. Red flag: no out-of-band channels; the secondary channel shares the failure mode of the primary (email and intranet both on the corporate network, for example).
11. Is the Channel Architecture tested at the defined cadence? Evidence: the channel-test reports; the out-of-band test reports. Red flag: the channels have never been tested end-to-end; the out-of-band channels have never been tested; the test reports are missing.
12. Is the multilingual capability of each channel documented and tested? Evidence: the Multilingual and Accessibility Plan; the multilingual test reports. Red flag: the multilingual capability is asserted but not tested; the regional-language messages are machine-translated without native-speaker review.
13. Is the accessibility capability of each channel documented and tested (sign language, screen reader, captioning, easy read)? Evidence: the Accessibility Plan; the accessibility test reports. Red flag: no accessibility provision; the accessibility is asserted but not tested.

Regulator-clock matrix

14. Is the Regulator-Clock Matrix complete for every regulator the organisation is subject to? Evidence: the Matrix with trigger, clock, recipient, form, channel, owner, deputy, evidence, dependencies, rehearsal cadence. Red flag: missing regulators; the CERT-In six-hour clock is missing; the DPDP seventy-two-hour clock is missing; the SEBI LODR Reg 30 disclosure clock is missing for a listed entity.
15. Has the Regulator-Clock Matrix been tested end-to-end in the last twelve months? Evidence: the regulator-clock exercise report; the simulated filings; the portal-access verification; the form-readiness verification. Red flag: the Matrix has never been tested; the regulators' portals have never been accessed in the test; the forms are not pre-prepared.
16. Has the CERT-In PoC been verified as 24x7 contactable in the last ninety days? Evidence: the PoC contact test log; the CERT-In acknowledgement. Red flag: the PoC has not been tested; the PoC's phone is unreachable; the PoC has left the organisation and the regulator has not been updated.
17. Has the DPDP breach-notification workflow been verified end-to-end, including the Data Protection Board portal access and the Data Principal notification template? Evidence: the workflow test log; the portal-access verification. Red flag: the workflow has never been tested; the Data Protection Board portal access has not been verified.

Holding-statement library

18. Is the Holding-Statement Library complete for each disruption class the BIA identifies? Evidence: the Library with statements per class. Red flag: missing classes; the Library is a single generic statement; the statements are not tailored to the organisation's stakeholders.
19. Are the holding statements pre-approved by Legal, Corporate Communications and the relevant executive? Evidence: the approval log per statement. Red flag: the statements exist but are not pre-approved; the approval is more than two years old; the approval does not cover the latest regulator changes.
20. Have the holding statements been tested in an exercise in the last twelve months? Evidence: the exercise report showing the holding-statement deployment. Red flag: the statements have never been tested in an exercise; the exercise tested only the technical response.

Spokesperson discipline

21. Is the Spokesperson Discipline Charter documented with primary, secondary, technical and regulatory spokespersons named? Evidence: the Charter. Red flag: missing Charter; the spokesperson is "the CEO will handle it"; the deputies are not named.
22. Are the spokespersons media-trained and refreshed at the defined cadence? Evidence: the media-training certificates; the refresh log. Red flag: the spokespersons have never been media-trained; the training is more than two years old; the deputies have not been trained.
23. Is the message-discipline rule (single voice, no speculation, no admission of fault pending investigation, no comment on rumour) documented and evidenced in operation? Evidence: the Charter; the post-event message reviews; the spokesperson log. Red flag: the rule is documented but not evidenced in operation; the post-event reviews are missing.

Rumour-control and social-listening

24. Is the Rumour-Control and Social-Listening Design documented? Evidence: the Design with tools, sweeps, escalation, single-voice enforcement, legal-action threshold. Red flag: missing Design; the Design exists but the tools are not deployed; the sweeps are not running.
25. Is the rumour-response workflow tested in the last twelve months? Evidence: the rumour-response exercise report. Red flag: the workflow has never been tested; the rumour response is improvised on the day.

Exercise programme

26. Is the crisis-communication exercise programme integrated with the BCM exercise programme (Clause 8.5)? Evidence: the exercise calendar; the exercise scenarios with communication objectives. Red flag: the crisis-communication exercise is independent; the BCM exercise programme does not test communication.
27. Has at least one tabletop crisis-communication exercise been conducted in the last quarter? Evidence: the tabletop exercise report. Red flag: no tabletop in the last quarter; the tabletop did not test the regulator-clock workflow; the tabletop did not include the multilingual dimension.
28. Has at least one simulation-level crisis-communication exercise been conducted in the last twelve months? Evidence: the simulation exercise report; the after-action report; the corrective-action pipeline. Red flag: no simulation in the last twelve months; the simulation did not include the public-facing dimension (media, social, customer); the corrective actions have not been closed.

Evidence and document control

29. Is the communication evidence captured per event, retained per Clause 7.5, and retrievable for audit? Evidence: the evidence record per event; the document-control log; the retrieval-time test. Red flag: the evidence is not captured; the evidence is captured but not retained per Clause 7.5; the evidence is not retrievable within a reasonable time.
30. Has the internal audit sampled the communication discipline in the last twelve months? Evidence: the internal audit report; the corrective actions. Red flag: the internal audit has not covered 7.4; the audit findings have not been closed.

Metrics and KPIs

The 7.4 KPI set should be small enough to be reported on a single dashboard and large enough to cover the four decisions, the bidirectional principle, the regulator clocks and the exercise programme. The fifteen KPIs below are a starting set; the organisation should customise to its sector, scope and stakeholder profile.

Process KPIs (the four decisions and the bidirectional principle)

1. Audience-coverage ratio, the percentage of identified audiences (per the Audience and Stakeholder Map) with a documented, owned, channel-mapped, clock-bound communication plan. Formula: (audiences with complete plan / total identified audiences) × 100. Target: 100 percent. Frequency: monthly.
2. Routine-communication-cadence adherence, the percentage of routine communication events delivered on the defined cadence. Formula: (events delivered on cadence / events scheduled) × 100. Target: 95 percent. Frequency: monthly.
3. Channel-test pass rate, the percentage of channels that passed the end-to-end test in the last quarter. Formula: (channels passed / channels tested) × 100. Target: 100 percent. Frequency: quarterly.
4. Out-of-band-channel test pass rate, the percentage of out-of-band channels that passed the end-to-end test in the last twelve months. Formula: (channels passed / channels tested) × 100. Target: 100 percent. Frequency: annual.
5. Multilingual-coverage ratio, the percentage of identified audiences whose communication plan includes the required languages, verified by native-speaker review. Formula: (audiences with multilingual plan complete / audiences requiring multilingual plan) × 100. Target: 100 percent. Frequency: quarterly.
6. Two-way-feedback response time, the median time to acknowledge and the median time to resolve inbound communication per channel. Formula: median time over the period. Target: acknowledge within 15 minutes during activation; resolve within 24 hours (or per SLA). Frequency: monthly.
7. Holding-statement coverage, the percentage of BIA-identified disruption classes with a pre-approved holding statement. Formula: (classes with statement / classes identified) × 100. Target: 100 percent. Frequency: quarterly.
8. Spokesperson-media-training currency, the percentage of named spokespersons whose media training is current (within 12 months). Formula: (spokespersons current / total spokespersons) × 100. Target: 100 percent. Frequency: quarterly.

Outcome KPIs (clocks and effectiveness)

9. CERT-In six-hour-clock adherence, the percentage of prescribed cyber incidents notified to CERT-In within six hours of noticing. Formula: (incidents notified on time / incidents notified) × 100. Target: 100 percent. Frequency: per incident; aggregated monthly.
10. DPDP seventy-two-hour-clock adherence, the percentage of personal-data breaches notified to the Data Protection Board within seventy-two hours of becoming aware. Formula: (breaches notified on time / breaches notified) × 100. Target: 100 percent. Frequency: per breach; aggregated monthly.
11. Other-regulator-clock adherence, the percentage of regulator notifications filed within the applicable clock (RBI, SEBI, IRDAI, NCIIPC, NDMA, MCA, sectoral). Formula: (notifications on time / notifications filed) × 100. Target: 100 percent. Frequency: monthly.
12. First-hour-communication adherence, the percentage of Level 3 or Level 4 activations in which the first-hour communication (internal alert, regulator notification, customer holding, supplier notification, media holding, board notification) was issued within sixty minutes of activation. Formula: (activations meeting the standard / activations) × 100. Target: 95 percent. Frequency: per activation.
13. Customer-communication satisfaction, the customer satisfaction score on communication during and after a disruption, measured through a post-incident survey. Formula: average score on a 5-point scale. Target: 4.0 or higher. Frequency: per disruption.

Learning KPIs

14. Exercise-to-corrective-action conversion, the percentage of exercise findings that produced a corrective action with an owner and a target date. Formula: (findings with corrective action / total findings) × 100. Target: 100 percent. Frequency: per exercise.
15. Corrective-action closure rate, the percentage of communication corrective actions closed within the target date. Formula: (actions closed on time / actions due) × 100. Target: 90 percent. Frequency: monthly.

Dashboard layout

A defensible Communication KPI Dashboard reports, on a single page: the audience-coverage ratio; the routine-communication-cadence adherence; the channel-test pass rate; the multilingual-coverage ratio; the two-way-feedback response time; the holding-statement coverage; the spokesperson-media-training currency; the regulator-clock adherence (CERT-In, DPDP, others); the first-hour-communication adherence; the customer-communication satisfaction (where measured); the exercise-to-corrective-action conversion; the corrective-action closure rate. The dashboard is reported to the BCM Steering Committee monthly, to the Board Risk Committee quarterly, and to the regulators as required.

Common Pitfalls and Audit Failures

The 7.4 audit failures cluster into twelve patterns. Each is named, illustrated, and paired with the corrective.

Pitfall 1, "Inform stakeholders". The communication plan reads "Inform stakeholders" with no further detail. The auditor will treat this as a major non-conformity because "inform" is not a decision; it is a deferred decision. Corrective: the Communication Requirements Matrix specifies the who, what, when, how and feedback for each audience.

Pitfall 2, The single-channel default. The communication plan assumes email for everything. The auditor will ask what happens when email is down (ransomware) or when the audience does not use email (the field force). Corrective: the Channel Architecture specifies primary, secondary and out-of-band channels with tested failover.

Pitfall 3, The CEO-spokesperson fallacy. The spokesperson is "the CEO will handle it". The auditor will ask what happens when the CEO is on a long-haul flight, in a regulator meeting, or personally affected by the disruption. Corrective: the Spokesperson Discipline Charter names primary, secondary, technical and regulatory spokespersons with deputies.

Pitfall 4, The untested regulator clock. The Regulator-Clock Matrix is documented but has never been tested end-to-end. The auditor will ask for the last test. Corrective: the regulator-clock workflow is tested at least annually, with the regulator's portal accessed, the form prepared, the owner and deputy both exercising.

Pitfall 5, The English-only default. The communication plan is in English; the workforce and customer base are not. The auditor will ask how the regional-language workforce receives the warning. Corrective: the Multilingual and Accessibility Plan covers the working languages and is tested with native-speaker verification.

Pitfall 6, The broadcast-only design. The communication is one-way, broadcasts without inbound paths. The auditor will ask how the workforce flags a concern, how the customer escalates, how the supplier raises an issue. Corrective: the Two-Way Feedback Architecture specifies the inbound path per audience with response-time targets.

Pitfall 7, The unexercised crisis-communication plan. The plan exists; the simulation has never been run. The auditor will ask for the last simulation report. Corrective: the crisis-communication exercise programme runs at least quarterly at tabletop and at least annually at simulation level.

Pitfall 8, The pre-approved-but-never-refreshed holding statement. The library exists but was approved three years ago, before the regulator changed the form, before the spokesperson changed, before the brand changed. Corrective: the library is reviewed at least annually and on trigger events.

Pitfall 9, The unlogged communication. The communication happens but is not logged; the auditor asks for the evidence and there is none. Corrective: every communication event is logged per Clause 7.5, with content, time, channel, audience, sender, delivery confirmation, and feedback.

Pitfall 10, The rumour-amplification mistake. The organisation's first response to a rumour is a public denial that gives the rumour more oxygen, or an engagement with bad-faith actors that legitimises them. Corrective: the Rumour-Control Design specifies the rumour-response playbook and the legal-action threshold.

Pitfall 11, The "we'll improvise" mindset. The leadership's posture is "we are smart people, we will figure it out on the day". The auditor will treat this as a major non-conformity because the day of a major incident is the worst possible day to figure anything out. Corrective: the six-phase lifecycle is designed, rehearsed, and evidenced.

Pitfall 12, The BCM-Manager-as-universal-communicator. The RACI reads "delivered by BCM Manager" for every line item. The auditor will ask why Corporate Communications, HR, Customer Experience, Legal and the DPO are not on the RACI for the audiences they own. Corrective: the RACI reflects the actual ownership of each audience.

Illustrative Scenario 1: Failure, MetroFins Cooperative Bank (Illustrative)

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

Disclaimer: MetroFins Cooperative Bank is a fictional entity. The scenario is illustrative, drawn from publicly reported patterns in the Indian BFSI segment (including the HDFC Bank RBI action of December 2020, the SBI YONO outages, and the Jio September 2024 communications gap), and does not describe any specific real organisation. All names, numbers and dates are illustrative.

The organisation

MetroFins Cooperative Bank is a Tier-2 urban cooperative bank headquartered in Pune, with 87 branches across Maharashtra and Goa, a customer base of approximately 1.4 million depositors, and a workforce of 2,800. The bank had been on a multi-year digital-transformation programme, replacing its legacy core-banking platform with a modern cloud-delivered system and launching a mobile-banking app that had grown to 620,000 active users. The bank's BCMS had been certified to ISO 22301:2019 two years earlier, with a stated scope covering the core-banking platform, the mobile and internet-banking channels, the branch network, and the back-office operations.

The disruption

At 03:42 IST on a Saturday in peak wedding-season, the bank's SOC detected anomalous encryption activity on the core-banking platform's database cluster. By 04:15 the platform was dark, the core banking, the mobile and internet banking, the UPI rails, the ATM switch, and the branch-processing systems were all unreachable. The ransomware (a LockBit variant) had entered through a phishing compromise of a database administrator's credentials two weeks earlier, pivoted through the corporate network, and reached the core on Friday night when the weekend monitoring was at its thinnest.

The communication failures

The technical response was competent. The IT DR team invoked the failover to the disaster-recovery site within four hours; the backups (most of them) were intact; the core was largely restored by Sunday evening. The communication response was not.

Failure 1, the regulator-clock miss. The CERT-In PoC was the bank's CISO. The CISO was on a personal trip to Andaman with limited mobile coverage; the deputy PoC had not been formally designated to CERT-In. The CERT-In six-hour clock started at 03:42 when the SOC detected the encryption; the first attempt to file the CERT-In notification was at 11:20 the same morning, over seven hours after the clock, and only after the bank's external forensics partner reminded the team. The RBI notification (under the 2016 Cyber Security Framework's two-to-six-hour expectation) was filed at 13:05, over nine hours after detection. The DPDP breach-notification clock (seventy-two hours for the personal-data component, which the ransomware had accessed) was identified only on Monday when Legal reviewed the forensics report; the notification to the Data Protection Board was filed at the sixty-ninth hour, with the affected-customer notification following three days later.

Failure 2, the customer-communication vacuum. The bank's customer-communication channel was the mobile app, the same mobile app that the ransomware had taken dark. The fallback channel was the call-centre, which received 280,000 calls in the first eight hours against a normal peak of 18,000; the IVR message was the generic "we are experiencing technical difficulties, please try later", with no acknowledgement of the scale, no estimated restoration time, no alternative-channel guidance. The bank's social-media handles went silent for the first six hours; the first tweet, at 09:45, called the outage "minor technical issues", at the same time, Downdetector was showing 12,000 user reports and the local press had already published a story sourced from angry customer tweets. The corporate website's incident page was not updated until Monday morning.

Failure 3, the spokesperson mis-step. The bank's primary spokesperson was the CEO. The CEO was in Mumbai for a family wedding; the secondary spokesperson (the Head of Corporate Communications) was not reachable until 11:00; the technical spokesperson (the CISO) was running the technical response and was unavailable. At 14:00, the CEO gave a brief phone interview to a Marathi news channel from his car, in which he said "some systems are slow, we will be back by evening", a statement that was inaccurate (the systems were not slow, they were dark), not aligned with the technical reality (the restoration timeline was uncertain), and inconsistent with the call-centre script ("technical difficulties"). The Marathi channel led its evening bulletin with the gap between the CEO's "back by evening" and the customers' experience of a full day of darkness.

Failure 4, the workforce communication vacuum. The branch workforce, 2,200 of the 2,800 staff, learned of the outage from customers walking in at branch opening on Saturday morning. The branch staff had no script, no manual-mode guidance, no escalation route, and no answer to the customer's question "is my money safe?". The workforce WhatsApp groups (not the official channel) filled with rumour, speculation, and screenshots of the ransomware claim. The Head of HR sent an all-staff email at 16:00, an email that 40 percent of the workforce (the branch staff using shared workstations without personal email access) never received until Monday.

Failure 5, the rumour cascade. By Saturday afternoon, social media was running three parallel narratives: a "bank run" narrative (false, the bank's ATMs were down, so there was no run); a "data breach" narrative (partly true, the ransomware actor had exfiltrated some customer data); and a "regulator takeover" narrative (false, the RBI had not, at that point, taken any action). The bank's rumour-control capability consisted of one junior corporate-affairs executive with a Hootsuite licence; the rumour-control response was a series of generic "we are aware of the rumours" tweets that amplified the rumours by acknowledging them.

The impact

The direct technical impact was largely recovered by Monday. The communication impact was not.

• Regulatory impact. The RBI opened a supervisory investigation on Monday. The investigation found the late notification, the inadequate customer communication, the spokesperson mis-statement, and the workforce-communication gap. The RBI imposed a monetary penalty of INR 4 crore under the Banking Regulation Act; required the bank to commission an external IT audit at its own cost; and restricted the bank from onboarding new mobile-banking customers for six months pending the audit closure. The CERT-In investigation required a formal remediation plan and quarterly reporting for twelve months. The DPDP investigation (the first material DPDP enforcement action in the BFSI segment) resulted in a INR 8 crore penalty for the breach-notification failures and a Direction to redesign the breach-notification workflow.
• Customer impact. The bank's deposit base shrank by INR 1,150 crore in the three months following the incident (a 3.2 percent decline), the mobile-banking active user base shrank by 18 percent, and the bank's Net Promoter Score dropped from +42 to -8. The customer-churn impact was concentrated in the under-35 segment, the segment the bank had been investing in attracting.
• Reputational impact. The bank's brand-tracking surveys recorded a 14-point drop in "trust" and a 19-point drop in "digital leadership", the two attributes the digital-transformation programme had been building for five years. The local press ran a series of "is your cooperative bank safe?" stories that affected the wider UCB segment.
• Workforce impact. The workforce engagement survey recorded a 22-point drop in "leadership communicates honestly in a crisis". The CISO resigned within four months. The CEO retired early within nine months. The Head of Corporate Communications moved to a different sector.
• Financial impact. The bank's internal estimate of the total financial impact, including the penalties, the audit cost, the customer-churn revenue loss, the brand-investment rebuilding cost, the workforce-replacement cost, and the legal cost, was INR 92 crore over the two years following the incident, a figure substantially larger than the cost of building a 7.4-conformant communication system would have been.

The root causes (the 7.4 lessons)

• The Regulator-Clock Matrix was documented but untested. The PoC was on a personal trip; the deputy was not designated; the forms were not pre-prepared; the portal access had not been verified.
• The Channel Architecture had no redundancy. The customer-communication channel depended on the same mobile app that the ransomware had taken dark.
• The Spokesperson Discipline was aspirational. The CEO was unbriefed and off-message; the secondary spokesperson was unreachable; the technical spokesperson was running the technical response.
• The holding-statement library was generic. No pre-approved statement for "core-banking outage with personal-data exposure"; the first hour was spent drafting from scratch.
• The multilingual design was missing. The Marathi-speaking customer base (the majority of the bank's customers) received only English-language communication through the call-centre and social media.
• The rumour-control capability was under-resourced. One junior executive with a basic social-media tool against three parallel rumour narratives.
• The two-way feedback was broken. The call-centre was overwhelmed; the workforce WhatsApp groups (the only functioning two-way channel) were not monitored.
• The crisis-communication exercise programme had not been run for two years. The last simulation had been a tabletop in the year of certification, and had not included the multilingual dimension, the regulator-clock workflow, or the rumour-control dimension.

The 7.4 lesson: a BCMS certified to ISO 22301:2019 can be technically competent and communicationally broken. The certification audit had passed the communication documentation; the audit had not tested the communication under stress. The bank's experience is the strongest argument for treating the crisis-communication exercise programme as a non-negotiable part of the BCMS, not as a nice-to-have.

Illustrative Scenario 2: Success, Dakshta Paytech Private Limited (Illustrative, with ROI)

Disclaimer: Dakshta Paytech Private Limited is a fictional entity. The scenario is illustrative, drawn from publicly reported patterns in the Indian fintech and payment-systems segment (including the NPCI / UPI outage of 12 April 2025 and the Akasa Air communication discipline of 19 July 2024), and does not describe any specific real organisation. All names, numbers and dates are illustrative.

The organisation

Dakshta Paytech is a Bengaluru-based payment-systems SaaS firm serving 4,800 merchants across India, processing an average of INR 380 crore per day in UPI, card, and net-banking transactions. The firm has 640 staff (engineering, operations, customer-success, compliance, finance), a Tier-1 BCMS certified to ISO 22301:2019, and a strong information-security programme certified to ISO/IEC 27001:2022. The firm's regulator footprint includes CERT-In, the RBI (as a non-bank Payment System Operator under the RBI Cyber Resilience and Digital Payment Security Controls Master Direction), DPDP (as a Significant Data Fiduciary for the volume of personal data processed), and the GST and STPI authorities.

The starting point

Two years before the events described below, Dakshta's BCM Manager (Priya Sharma) and Head of Corporate Communications (Rahul Iyer) had run a communication-back-fill workshop as part of a Clause 9.2 internal-audit finding closure. The workshop had surfaced eight gaps: no Audience and Stakeholder Map for the merchant-success tier; no Regulator-Clock Matrix covering DPDP; no Channel Architecture with redundancy; no holding-statement library for the top four disruption classes; no spokesperson discipline beyond "the CEO will handle it"; no multilingual design for the merchant base (heavily Tier-2 and Tier-3 city); no rumour-control capability; and no crisis-communication exercise in the previous twelve months.

The CEO had approved a two-year communication-build budget of INR 1.6 crore (spread across the mass-notification platform, the multilingual content production, the media-training cycle, the PR partner retainer for major-incident surge, the integration with the customer-communication stack, and the exercise programme). The BCM Steering Committee had endorsed the build as a Clause 7.4 programme-of-work alongside the broader Clause 10.2 continual-improvement pipeline.

The build

The build was sequenced over the two-year period, integrated with the existing BCM and IS programmes.

Months 1 to 6, Design phase. The Audience and Stakeholder Map was completed with 14 audiences (the eleven canonical audiences plus three organisation-specific: the merchant-success tier, the partner-bank operations teams, and the payment-network operators). The Communication Requirements Matrix was built out cell by cell. The Channel Architecture was designed with the mass-notification platform (an India-headquartered SaaS with multilingual and WhatsApp Business API capability) as the primary broadcast channel, the customer-communication stack (a global CXM with Indian data residency) as the primary customer channel, the workforce-collaboration platform (enterprise collaboration suite) as the primary internal channel, and the out-of-band layer (satellite phones at the two data centres, hard-line phones at the Bengaluru and Mumbai offices, runner protocol with the print shop on standby). The Regulator-Clock Matrix was built out for CERT-In (six hours), RBI (per the PSO Master Direction), DPDP (seventy-two hours), and SEBI LODR Reg 30 (Dakshta was preparing for an IPO). The Holding-Statement Library was drafted for 12 disruption classes, in English, Hindi, Kannada, Tamil, Telugu, Marathi, and Bengali.

Months 7 to 12, Deliver phase and first exercise. The routine-communication cadence went live. The first quarterly tabletop was run, with a payment-rail outage scenario that tested the regulator-clock workflow, the customer holding-statement deployment, the merchant-success tier escalation, and the rumour-control capability. The exercise surfaced nine findings; the corrective-action pipeline tracked them to closure.

Months 13 to 18, Spokesperson media-training and first simulation. The CEO, the COO, the Head of Corporate Communications, the CISO, and the Head of Customer Success completed a three-day media-training intensive with a corporate-affairs consultancy; the deputies completed a two-day version. The first annual simulation ran a Level 3 ransomware scenario across two days, with the simulation team playing the regulator, the media, the customers, the merchants, and the workforce; the after-action report opened 23 corrective actions; 21 were closed within six months.

Months 19 to 24, Multilingual production, rumour-control build, and second simulation. The multilingual production was completed, with native-speaker verification of every holding statement in every language. The rumour-control capability was upgraded with a social-listening platform and a 24x7 monitoring partner; the rumour-response playbook was written and rehearsed. The second annual simulation ran a Level 4 supplier-failure-and-data-breach scenario, with a particular focus on the DPDP seventy-two-hour workflow and the merchant-success communication; the after-action report opened 19 corrective actions.

The disruption

At 06:18 IST on a Wednesday, Dakshta's SOC detected a sophisticated intrusion in the merchant-onboarding microservice. The intrusion had originated from a compromised software supply chain (a popular open-source dependency), and the forensics team's first assessment was that the threat actor had accessed the merchant-data store containing personal data of approximately 280,000 merchants and the customer-data store containing personal data of approximately 1.4 million of the merchants' end-customers. The technical response was the SOC's; the communication response was the BCM Communication Procedure's.

The communication response

06:18, detection. The SOC analyst classified the event as a Level 3 cyber incident with potential personal-data exposure. The escalation to the BCM Manager and the CMT Chair followed within four minutes.

06:31, activation. The CMT Chair (the COO) activated the CMT at Level 3. The activation notice went to the CMT, the BCM team, the IT DR team, the SOC, the Legal counsel, the DPO, the Head of Corporate Communications, the Head of Customer Success, and the CEO. The activation notice included the trigger, the time of detection (the CERT-In clock start), the immediate assessment, and the recommended first-hour actions.

06:47, first-hour communication (within 60 minutes). The bank's first-hour communication package went out: (a) the internal alert to the workforce via the mass-notification platform (English, Hindi, Kannada, Tamil, Telugu, Marathi, Bengali), "We are responding to a cyber incident affecting some systems. Please follow instructions from your manager. Do not discuss externally. We will update at 08:00."; (b) the CERT-In notification filed by the CISO at 06:58, within the six-hour clock, well within; (c) the DPDP breach notification clock start confirmed by the DPO at 07:02, with the seventy-two-hour clock running from the awareness at 06:31 (the DPO chose the conservative start time of the activation, not the detection); (d) the merchant holding statement issued by the Head of Customer Success via the customer-communication stack at 07:14, in seven languages, "We have identified a security incident that may affect some of your data. We are investigating urgently. Your transactions are not affected. We will update you at 09:00. Please contact your Customer Success Manager with any concerns."; (e) the partner-bank notification issued by the COO at 07:21; (f) the media holding statement held in reserve pending confirmation of the scale (the spokesperson discipline rule: do not go public until the facts are verified); (g) the board notification issued by the Company Secretary at 07:35.

07:00 to 09:00, first two-hour window. The forensics team confirmed the scope of the personal-data exposure by 08:15. The DPO prepared the DPDP breach notification to the Data Protection Board, with the prescribed form, the affected-data-category detail, the root-cause summary, the corrective-action summary, and the affected-Data-Principal notification template. The notification was filed at 09:02, within the seventy-two-hour clock, with substantial margin.

09:00 to 12:00, customer and merchant communication. The Head of Customer Success issued the first detailed merchant communication at 09:00, with the scope of the affected data, the recommended merchant actions, the customer-communication template (for the merchants to use with their end-customers), the regulator notifications filed, and the commitment to a daily update until the incident closed. The customer-communication stack handled 47,000 merchant enquiries in the first eight hours (against a normal peak of 3,500), with the IVR updated in seven languages, the chatbot updated with the incident FAQ, and the merchant-success tier augmented with surge support from a partner firm.

12:00, media statement. The CEO (primary spokesperson, briefed and prepared) issued the first on-camera media statement at 12:00, accurate, empathetic, action-oriented, with the scope, the regulator notifications, the customer-remedy commitment, and the commitment to a daily update. The statement was carried by the major business wires and the fintech press; the tone of the coverage was notably more constructive than the typical breach-incident coverage.

12:00 onwards, rumour control. The social-listening platform and the 24x7 monitoring partner identified three emerging rumour narratives: a "Dakshta is shut down" narrative (false, transactions were processing normally); a "all customer card data was stolen" narrative (false, card data was tokenised and was not in the affected store); and a "regulator action is imminent" narrative (premature, the regulators had been notified and were engaged, but no action had been taken at that point). The rumour-response playbook was executed: each narrative was addressed on the official channel with verified facts; the legal-action threshold was reached for one originator (a social-media account with a pattern of market-manipulative posts against fintech firms) and a takedown request was filed.

Throughout the activation, two-way feedback. The merchant-success hotline, the customer escalation route, the workforce hotline, and the regulator response channel were all active. The workforce hotline received 187 calls in the first 24 hours; each was logged, routed, and resolved. The merchant-success escalation received 312 escalations; each was assigned to a Customer Success Manager and resolved within the SLA. The regulator response channel handled follow-up enquiries from CERT-In and the RBI; each was answered within the regulator's expected timeframe.

Day 2 to Day 7, sustain. The communication cadence sustained through the response and recovery. Daily merchant updates at 09:00 and 17:00. Daily regulator updates on the cadence each regulator specified. Daily workforce updates at 09:00. Daily media updates as required. The spokesperson discipline held, the CEO, the COO, the Head of Corporate Communications, and the CISO all delivered consistent messages across the channels and audiences.

Day 8, close. The incident was closed on Day 8 with the final regulator notifications, the all-clear communication to the merchants and the workforce, the final media statement, and the transition back to the routine-communication cadence.

Day 14, post-disruption review. The post-disruption communication review identified 17 findings, of which 11 were minor (message-timing, message-tone, channel-priority), 5 were moderate (the merchant-success surge staffing model, the partner-bank notification cadence, the legal-review bottleneck for non-pre-approved messages, the multilingual IVR-script gap for one minor language, the workforce-hotline peak-load capacity), and 1 was significant (the rumour-control partner's response-time SLA was breached twice). All 17 became corrective actions with owners and target dates.

The ROI

Investment. The two-year build had cost INR 1.6 crore (capitalised and operating). The incident response itself cost a further INR 2.4 crore (forensics, legal, customer-success surge, rumour-control partner, communication production, regulator-engagement cost), within the cyber-insurance loss-recovery, with the insurer's breach-response partner integrated from the first hour.

Avoided loss, illustrative. Without the build, the realistic counterfactual (based on the MetroFins failure pattern and the wider Indian fintech breach-incident pattern) would have included: a CERT-In late-notification penalty exposure and supervisory escalation (avoided cost: INR 50 to 200 lakh plus the management-attention cost); a DPDP breach-notification failure penalty exposure of up to INR 200 crore for the notification failure alone (avoided cost: substantial); a customer-churn impact of 4 to 8 percent of the merchant base (avoided revenue loss: INR 8 to 16 crore annualised); a brand-value impairment (avoided cost: hard to quantify but routinely estimated in the high-single-digit percentages of the firm's pre-IPO valuation); and a workforce-engagement impact (avoided cost: the CISO and the Head of Corporate Communications staying, against the MetroFins pattern of senior-comms attrition).

Net ROI. Even on the most conservative accounting (avoiding the DPDP penalty exposure alone, valued at INR 5 crore as the realistic expected-value of the penalty-and-legal-cost exposure given the breach scale), the build returned more than three times its cost on the single incident. On the broader accounting (avoiding customer churn, brand impairment, workforce attrition, and the regulator-escalation cascade), the build returned more than ten times its cost. The CEO's post-incident review with the Board Risk Committee concluded: "The ISO 22301:2019 Clause 7.4 build was the highest-ROI investment we made in the two years before the incident. It did not prevent the incident; it prevented the incident from becoming a crisis."

The 7.4 lessons

• The Design phase pays back the moment an activation fires. The first-hour communication package, the pre-approved holding statements, the regulator-clock workflow, the spokesperson briefings, all were ready when the SOC detected the intrusion.
• The exercise programme is the difference between a Plan that works and a Plan that is documented. Dakshta's two annual simulations had tested exactly the scenario that materialised; the team had rehearsed the workflow.
• The multilingual design is a customer-trust investment. The seven-language merchant communication was specifically cited in the post-incident merchant-survey as a reason for staying with Dakshta.
• The two-way feedback architecture is a learning investment. The 312 merchant escalations produced actionable product and process insights that fed the corrective-action pipeline.
• The rumour-control capability is a reputation investment. The three rumour narratives were addressed before they scaled; the legal-action threshold was applied decisively against the market-manipulative originator.
• The CEO-as-spokesperson is a credibility investment, but only with media training, briefing, and message discipline. The CEO's 12:00 statement set the tone for the entire coverage.
• The build is a continual investment, not a one-off project. The 17 findings from the post-disruption review feed the next iteration of the Design phase.

Multi-Framework Mapping

The 7.4 communication discipline maps across the major management-system, sector-regulatory, and resilience frameworks. The mapping is bidirectional: a 7.4-conformant system satisfies the mapped requirements of the other frameworks, and a conformant system under the other frameworks substantially satisfies 7.4. The mapping is also a tool for integrated audits, an integrated ISO 27001 + ISO 22301 audit samples the communication discipline once.

The mapping table

Using the mapping

The mapping is used three ways. First, for integrated audits, an integrated ISO 27001 + ISO 22301 audit samples the communication discipline once, with the auditor's findings attributed to the relevant clause(s). Second, for multi-regulator compliance, an Indian BFSI firm answers to RBI, SEBI (if listed), IRDAI (if insurance subsidiary), CERT-In, DPDP, and the MCA; the Regulator-Clock Matrix consolidates the multi-regulator communication obligations into a single workflow. Third, for cross-border recognition, an Indian SaaS firm serving EU financial clients inherits DORA contractually; the 7.4 communication discipline is the foundation for the DORA-aligned incident-reporting workflow.

Implementation Roadmap

The 7.4 implementation roadmap is sequenced over 30, 90, 180 days and 12 months for a typical Indian growing company. The roadmap is calibrated to the maturity model (Section 22), an organisation starting at L1 will be at L2 by day 90, L3 by day 180, and L4 by the end of month 12 with disciplined execution.

First 30 days, Charter and triage

Week 1, Charter the programme. Top-management charter meeting; the BCM Manager is named as the programme owner; the cross-functional team (Corporate Communications, Customer Experience, Legal/Company Secretary, CISO, HR, Investor Relations) is named; the budget envelope is approved; the integration with the broader BCMS programme is confirmed.

Week 2, Triage the current state. Run the 90-minute communication-back-fill workshop (Section 1, Quick Win). Document the current-state gaps against the four decisions, the bidirectional principle, the regulator clocks, the spokesperson discipline, the multilingual design, and the rumour-control capability. Output: the gap log.

Week 3, Draft the BCM Communication Policy. Draft the apex policy (sketch in Section 9.1); circulate to the cross-functional team; collect comments; target sign-off by the CEO at the end of week 4.

Week 4, Stand up the programme infrastructure. Confirm the document-control home for the 7.4 artefacts (under Clause 7.5); confirm the KPI dashboard reporting line (BCM Steering Committee); confirm the corrective-action register integration (Clause 10.1); confirm the exercise programme integration (Clause 8.5); confirm the audit-integration with Clause 9.2.

30-day milestone. BCM Communication Policy signed; programme team named and chartered; current-state gap log documented; document-control and KPI infrastructure stood up.

Days 31 to 90, Design and first build

Days 31 to 45, Build the Audience and Stakeholder Map. Identify the eleven canonical audiences plus any organisation-specific additions. Name the owner, deputy, channels, clocks, multilingual requirement, accessibility requirement, two-way feedback path, evidence retention rule per audience.

Days 46 to 60, Build the Communication Requirements Matrix. Translate the four decisions into a per-audience, per-phase, per-trigger plan. Walk every cell with the audience owner; surface the gaps; document the deliverable plan.

Days 61 to 75, Build the Channel Architecture and the Regulator-Clock Matrix. Document the channel families; the primary, secondary and out-of-band channels per audience; the failure modes; the recovery objectives. Document the regulator-clock matrix for every regulator the organisation is subject to; the trigger, clock, recipient, form, channel, owner, deputy, evidence, dependencies, rehearsal cadence per regulator.

Days 76 to 90, Build the Holding-Statement Library and the Spokesperson Discipline Charter. Draft the holding statements for the top six to eight disruption classes (the BIA's top priority activities' failure modes). Circulate to Legal, Corporate Communications, and the relevant executives for pre-approval. Draft the Spokesperson Discipline Charter naming the primary, secondary, technical and regulatory spokespersons and their authorities.

90-day milestone. Audience and Stakeholder Map complete; Communication Requirements Matrix complete; Channel Architecture complete; Regulator-Clock Matrix complete; Holding-Statement Library complete for top scenarios; Spokesperson Discipline Charter drafted; first quarterly tabletop scheduled.

Days 91 to 180, Deliver and first exercise

Days 91 to 120, Build the Two-Way Feedback Architecture and the Multilingual and Accessibility Plan. Document the inbound path per audience; the responder, the response-time target, the escalation path, the evidence capture. Document the multilingual requirement per location and audience; the translation workflow; the native-speaker verification; the accessibility provisions.

Days 121 to 150, Deploy the channel infrastructure. Stand up (or contract for) the mass-notification platform; the customer-communication stack integration; the workforce-collaboration platform integration; the regulator-notification portal access verification; the out-of-band channels (satellite phone procurement, hard-line installation, runner protocol). Run the first quarterly channel tests.

Days 151 to 165, Media-training cycle for spokespersons. Run the media-training intensive for the primary, secondary, technical and regulatory spokespersons. Refresh the Holding-Statement Library with the spokespersons' input.

Days 166 to 180, First crisis-communication tabletop. Run a tabletop scenario that exercises the regulator-clock workflow, the holding-statement deployment, the customer-communication cascade, the multilingual dimension, and the rumour-control response. Capture the findings; open the corrective-action register.

180-day milestone. Two-Way Feedback Architecture complete; Multilingual and Accessibility Plan complete; channel infrastructure deployed; spokespersons media-trained; first tabletop run; corrective-action pipeline active.

Days 181 to 365, Mature, simulate, and improve

Days 181 to 240, Rumour-control and social-listening build. Procure and deploy the social-listening platform; stand up (or contract for) the 24x7 monitoring partner; write and rehearse the rumour-response playbook; test the legal-action threshold workflow with Legal.

Days 241 to 300, First annual simulation. Run a Level 3 simulation scenario over two days. Include the technical response, the regulator-clock workflow, the customer communication, the merchant or partner communication, the spokesperson discipline, the multilingual dimension, the rumour-control response, the two-way feedback handling, and the board and workforce communication. After-action report; corrective actions.

Days 301 to 365, Internal audit, management review, and continual improvement. Run the Clause 9.2 internal audit on the 7.4 programme; close the audit findings. Run the Clause 9.3 management review on the communication portfolio; align the next-year programme with the strategic priorities. Refresh the documentation set; advance the maturity level.

12-month milestone. The 7.4 programme is at L3 maturity (a designed, delivered, exercised communication system with a complete artefact set). The next 12 months advance to L4 (a continuously improved, integrated, regulator-tested communication system).

Critical-path notes

• The Design phase (the first 90 days) is the critical path. Skipping or compressing it produces a programme that has the artefacts but not the alignment, and the alignment is what the auditor tests under stress.
• The exercise programme is the second critical path. A 7.4 programme that has not exercised the regulator-clock workflow end-to-end is a programme the auditor will treat as non-conformant regardless of the documentation quality.
• The spokesperson media-training is the third critical path. An untrained spokesperson is a single point of failure for the entire communication discipline.
• The multilingual production is the fourth critical path. The native-speaker verification takes longer than expected and is the most common slip on the implementation timeline.
• The integration with the broader BCMS programme (the BCM Steering Committee, the exercise calendar, the audit and review cycle, the corrective-action register) is the fifth critical path. A standalone 7.4 programme is non-conformant under the integrated-management-system requirement.

FAQ

Q1. We have a corporate-communications team and a customer-experience team. Do we need a separate BCM Communication Policy?

Yes. The corporate-communications team owns the brand and the media; the customer-experience team owns the customer journey; neither owns the BCMS communication discipline end-to-end. The BCM Communication Policy is the apex document that integrates both functions (and Legal, the CISO, HR, Investor Relations, the DPO) into a single, designed, exercised communication system for the BCMS. The policy is short; the integration is the value.

Q2. We are a small organisation. Can we run 7.4 with a one-page communication plan?

For a very small organisation (10 to 50 staff), a one-page Communication Plan that names the eleven audiences, the spokesperson, the mass-notification channel, the regulator clocks the organisation is subject to, and the top three holding statements may be sufficient as a starting artefact. The plan should evolve as the organisation grows. The auditor's test is whether the plan reflects the organisation's actual communication practice, not whether the plan is long.

Q3. The CERT-In six-hour clock starts at "noticing". What counts as noticing?

"Noticing" is broader than "confirming". If the SOC analyst sees anomalous activity at 02:00 and the shift handover at 06:00 escalates it to the CISO, the CERT-In clock arguably starts at 02:00, not at 06:00, and not at the forensics confirmation at 14:00. The conservative interpretation (and the one CERT-In enforcement appears to apply) is that the clock starts at the earliest point at which the organisation, acting reasonably, should have recognised the activity as a prescribed cyber incident. The Regulator-Clock Matrix should reflect this conservative interpretation and the BCM team should be trained accordingly.

Q4. We use WhatsApp for workforce communication. Is that acceptable under 7.4?

WhatsApp (and particularly WhatsApp Business API for official workforce communication) is a legitimate channel for the Indian workforce, particularly the field force. The design considerations: WhatsApp Business message templates must be pre-approved by Meta (a constraint on holding-statement deployment speed, pre-approve the templates for the top disruption classes); the WhatsApp messages and the responses should be logged in the communication-evidence record (typically via the WhatsApp Business API's logging feature, integrated with the BCM document-control); the WhatsApp broadcast lists should be segmented by audience (workforce, field force, key customers, key suppliers) to enable targeted communication; and the personal-WhatsApp vs WhatsApp Business boundary should be clear (workforce communication should be on the official WhatsApp Business channel, not on personal groups).

Q5. Our CEO does not want to do media training. What do we do?

The CEO is the primary spokesperson for severe incidents, and the spokesperson discipline requires media training. The conversation with the CEO typically includes: the personal-liability dimension (under the Companies Act and the regulator senior-manager accountability regimes, an untrained CEO making an inaccurate statement is a personal risk); the brand-dimension (an untrained CEO making an insensitive statement is a brand-damage risk); and the alternative (the CEO delegates the spokesperson role to a trained deputy for the specific incident, which the Spokesperson Discipline Charter should permit). If the CEO remains unwilling, the Charter should explicitly delegate the spokesperson role to a trained secondary spokesperson for all incidents; the CEO retains the disclosure-decision authority but does not deliver the public statement.

Q6. Our customers are B2B and have their own breach-notification clauses in the MSA. How do we reconcile the customer clocks with the regulator clocks?

The customer MSA's breach-notification clause and the regulator clock are separate obligations. The Regulator-Clock Matrix tracks the regulator clocks; the Customer Communication Matrix (a sub-view of the Communication Requirements Matrix) tracks the customer-specific clocks; the two matrices should be reconciled so that the customer notification (which may be required contractually before the regulator notification is filed) does not preempt or contradict the regulator notification. The Section 9.4 sample MSA clauses give a starting point; the customer-specific MSAs should be inventoried and the clocks consolidated.

Q7. Our crisis-communication exercise programme has never run. Where do we start?

Start with a 90-minute tabletop on the single most likely disruption class for the organisation (typically a ransomware affecting operations for a BFSI or SaaS firm, a payment-rail outage for a payment firm, a fire or flood for a manufacturing firm, a clinical-system outage for a hospital). The tabletop exercises the regulator-clock workflow, the holding-statement deployment, the spokesperson decision, and the customer-communication cascade, not the technical response. Run the tabletop with the cross-functional team (BCM, Corporate Communications, Customer Experience, Legal, CISO, HR). Capture the findings; open the corrective-action register; schedule the next tabletop in 90 days. The simulation-level exercise can wait until the tabletop cycle has matured (typically six to nine months).

Q8. Our board has not been briefed on BCM communication. What should we cover in the first briefing?

The first board briefing on 7.4 should cover: the regulator clocks the organisation is subject to (CERT-In, RBI, SEBI, IRDAI, DPDP, LODR Reg 30 if listed); the spokesperson discipline (who speaks for the organisation, on what authority, with what message discipline); the disclosure obligations (LODR Reg 30 for listed entities, Section 134(3)(n) for the board's report, DPDP for personal-data breaches); the board's own communication role during a major incident (the board does not speak publicly; the board approves the disclosure; the board reviews the spokesperson's performance); the maturity of the 7.4 programme (the maturity model in Section 22); and the board's oversight responsibilities under the Risk Management Committee (SEBI LODR Reg 21) and the Audit Committee (Companies Act s 177). The briefing should be 60 to 90 minutes, with the BCM Manager, the CISO, and the Company Secretary presenting.

Q9. Our field force uses personal smartphones, not corporate devices. How do we communicate with them during a disruption?

The field-force communication design (Section 7.7) addresses this. The channels: WhatsApp Business API for broadcast; SMS for redundancy; voice calls for the critical-response field force; regional-language short videos for awareness and training; the reporting manager as the two-way feedback path. The field-force communication should be tested in the exercise programme, the most common field-force failure is the assumption that "we sent it, so they got it". The field force should also be included in the Audience and Stakeholder Map and the Communication Requirements Matrix.

Q10. We are an Indian SaaS firm serving EU financial clients. Does DORA apply to our 7.4 programme?

DORA applies directly to EU financial entities and to the critical ICT service providers serving them (under Article 28). An Indian SaaS firm serving EU financial clients that are themselves DORA-regulated inherits DORA's communication obligations contractually, the customer's MSA will flow down DORA-aligned incident-reporting clauses. The Section 9.4 sample MSA clauses give a starting point; the customer-specific MSAs should be reviewed for the DORA-aligned flow-down. The Regulator-Clock Matrix should include the DORA clock (with the major-incident classification and thresholds) for the EU-customer-facing communication.

Industry-Specific Requirements

BFSI, banks, NBFCs, payment systems, insurers, capital markets

The BFSI segment is the most regulator-dense communication environment in India. The RBI Master Direction on IT Governance (7 November 2023, effective 1 April 2024) requires board and senior-management IT and BCM communication, customer-communication continuity, and inter-bank communication under stress. The RBI Cyber Security Framework (2 June 2016) requires incident reporting to RBI within two to six hours of detection, customer awareness against phishing and social engineering, and a Cyber Crisis Management Plan. The RBI MD Outsourcing of IT Services (10 April 2023) requires outsourcer communication and escalation to meet the RE's own standards. The SEBI CSCRF (20 August 2024) requires six-hour reporting for SEBI-RE cyber incidents, customer communication on incidents, and board communication. The SEBI MII BCP-DR circular (22 March 2021) requires MII communication to members, participants, and the public during disruption. The IRDAI Information and Cyber Security Guidelines (24 April 2023) require a board-approved communication plan, policyholder communication on claims continuity, and incident reporting to IRDAI and CERT-In.

The BFSI 7.4 programme adds: the BFSI-specific regulator-clock matrix (RBI two-to-six-hour, SEBI six-hour, IRDAI per the 2023 guidelines, CERT-In six-hour, DPDP seventy-two-hour); the BFSI-specific customer-communication discipline (the RBI customer-protection framework, the Banking Ombudsman scheme, the SEBI investor-protection framework, the IRDAI policyholder-protection framework); the BFSI-specific inter-bank communication (the IDRBT, the INFINET, the NPCI payment-network communication); the BFSI-specific spokesperson discipline (with the added dimension of market-sensitive disclosure for listed entities); and the BFSI-specific exercise programme (the annual RBI/SEBI/IRDAI cyber-drill requirements, the live-failover communication test under SEBI MII BCP-DR).

Healthcare, hospitals, pharma, medical devices, diagnostics

The healthcare 7.4 programme adds: the patient-communication discipline (informed consent continuity during an EHR outage, patient-notification of appointment or procedure changes, patient-safety communication during a clinical-system outage); the clinical-staff communication (the clinical-staff escalation tree, the clinical-staff manual-mode briefings, the clinical-staff family-notification in case of workforce harm); the regulator communication (the Clinical Establishments Act, the state health departments, the IRDAI for insured care, the DPDP for the special category of health data under the DPDP Rules 2025); the supplier communication (the critical-supplier communication for pharmaceuticals, medical devices, blood, oxygen, and the just-in-time supply chain); the family-notification workflow (the high-sensitivity communication with the families of affected patients); and the public-health communication (the coordination with the state and district health authorities during a public-health event).

IT/ITeS and SaaS

The IT/ITeS and SaaS 7.4 programme adds: the customer-communication discipline (the SLA-bound uptime reporting, the customer-incident communication under the MSA, the customer-data-breach notification under DPDP and the customer-jurisdiction regulators, GDPR for EU customers, DORA for EU financial customers, HIPAA for US healthcare customers, the state-level US breach-notification laws for US customers); the workforce-communication discipline (the global delivery centres, the field force, the offshore-onsite coordination, the multilingual design across the Indian and the global workforce); the supplier communication (the cloud providers, the SaaS dependencies, the critical-subcontractor communication); and the regulator communication (CERT-In, DPDP, GST and STPI, plus the customer-jurisdiction regulators for global SaaS).

Manufacturing, auto, pharma, chemicals, electronics, textiles

The manufacturing 7.4 programme adds: the workforce-safety communication (the plant-emergency communication, the evacuation communication, the industrial-incident communication under the Factory Inspectorate and the Pollution Control Boards); the regulator communication (the Factory Inspectorate, the Pollution Control Boards, the NDMA for chemical and industrial hazards under the Chemical Disaster Guidelines 2007, the PESO for petroleum and explosives, the ESI for workforce welfare, the state and district disaster-management authorities); the supplier communication (the critical raw-material suppliers, the logistics, the contract manufacturing); the customer communication (the B2B customer communication on production continuity, the product-recall communication, the customer-notification of supply disruption); the community communication (the surrounding community at industrial sites, the public-safety communication during a hazardous release); and the mutual-aid communication (the industrial-area mutual-aid associations, the fire brigade, the NDRF/SDRF coordination).

Government and Public Sector

The government and public-sector 7.4 programme adds: the citizen-communication discipline (the Right to Information, the Citizen's Charter, the public-facing communication during a disruption, the multilingual design across the Indian citizen base); the coordination communication (the parent ministry, the NDMA, the NDRF, the state and district authorities, the inter-departmental coordination); the regulator communication (the CAG, the CVC, the parliamentary committee structure); and the workforce communication (the multi-state, multi-language, multi-level government workforce, including the field workforce, the ASHA workers, the Anganwadi workers, the meter readers, the postal workers, the police constabulary).

Maturity Model

The 7.4 maturity model is the L1 to L5 scale used across the ISO 22301 programme, calibrated to the communication discipline. The INR estimates are indicative for an Indian growing company of 250 to 2,000 staff; smaller organisations will spend less, larger organisations more.

Level 1, Initial / Ad hoc

The 7.4 programme is informal. There is no BCM Communication Policy. The Audience and Stakeholder Map exists in someone's inbox. The Channel Architecture is "we use email". The Regulator-Clock Matrix exists for CERT-In and not for the other regulators. The Holding-Statement Library is a single generic statement. The Spokesperson Discipline is "the CEO will handle it". The multilingual design is missing. The rumour-control capability is one junior executive with a social-media account. The crisis-communication exercise programme has never run. The organisation will not pass a certification audit at L1.

Indicative investment to advance from L1 to L2: INR 8 to 15 lakh over 90 days.

Level 2, Managed / Repeatable

The 7.4 programme is documented. The BCM Communication Policy is approved. The Audience and Stakeholder Map is complete. The Communication Requirements Matrix is built. The Channel Architecture is documented. The Regulator-Clock Matrix is complete for every regulator. The Holding-Statement Library covers the top six to eight disruption classes. The Spokesperson Discipline Charter is drafted. The multilingual plan is in design. The first crisis-communication tabletop has been run. The organisation will pass a certification audit at L2 with minor non-conformities.

Indicative investment to advance from L2 to L3: INR 25 to 50 lakh over 180 days.

Level 3, Defined / Established

The 7.4 programme is established. The BCM Communication Procedure is operational. The Channel Architecture is tested with redundancy and out-of-band channels. The Holding-Statement Library is complete, pre-approved, and refreshed. The Spokespersons are media-trained. The multilingual design is complete with native-speaker verification. The Two-Way Feedback Architecture is operational with response-time targets. The crisis-communication exercise programme runs quarterly at tabletop and annually at simulation. The KPI Dashboard is live. The organisation will pass a certification audit at L3 cleanly.

Indicative investment to advance from L3 to L4: INR 50 to 150 lakh over 12 months.

Level 4, Quantitatively Managed

The 7.4 programme is measured. The KPI Dashboard drives the management review. The corrective-action pipeline is active and the closure rate is high. The exercise programme produces findings that drive continual improvement. The rumour-control capability is integrated with the social-listening platform and the 24x7 monitoring partner. The customer-communication satisfaction is measured post-incident. The organisation has demonstrated, in a real disruption, that the programme works.

Indicative investment to advance from L4 to L5: INR 75 to 200 lakh over 12 to 24 months.

Level 5, Optimising

The 7.4 programme is a strategic capability. The communication discipline is integrated with the broader enterprise risk management, the corporate affairs, the customer experience, and the regulator engagement. The programme is benchmarked externally. The organisation contributes to the industry communication practice (for example, the BCI India chapter, the FICCI Committee on Business Continuity, the NASSCOM Cybersecurity Working Group). The programme is a competitive differentiator in the organisation's market positioning.

The advancement pathway

The advancement pathway is not linear; an organisation may be at L4 on the regulator-clock workflow and at L2 on the multilingual design. The gap analysis (toolkit document 12) and the maturity assessment (toolkit document 11) are the working instruments the BCM Manager uses to plan the advancement.

Emerging Trends

The regulator-clock convergence

The Indian regulator clocks are converging. CERT-In's six-hour clock, the RBI two-to-six-hour expectation, the SEBI six-hour clock, the DPDP seventy-two-hour clock, and the LODR Reg 30 prompt disclosure are increasingly aligned in their expectations and increasingly enforced. The organisation that designs its Regulator-Clock Matrix as a single integrated workflow, not as separate per-regulator processes, will find the convergence easier to navigate. The trend is toward even shorter clocks for the most severe incidents (DORA's initial notification within four hours for major incidents at financial entities is a leading indicator); the organisation should design for shorter clocks than the current baseline.

The WhatsApp-and-social default

The Indian workforce and customer base default to WhatsApp and to the social platforms for unofficial communication. The organisation's official communication competes with a firehose of unofficial communication on personal channels. The trend is toward integrating the official communication with the unofficial channels (WhatsApp Business API for official workforce communication; the social platforms for official customer communication) rather than competing with them. The organisation that treats WhatsApp and social as auxiliary channels rather than primary channels is the organisation whose official communication is drowned out.

The AI-assisted communication

Generative AI is changing the communication discipline. The holding-statement drafting, the customer-message personalisation, the multilingual translation, the rumour-detection in social-listening, the sentiment analysis, and the chat-based customer interaction are all increasingly AI-assisted. The trend is toward AI as a tool for the communicator, not a replacement for the communicator, the spokesperson discipline, the message-accuracy control, the legal review, and the single-voice enforcement remain human. The organisation that adopts AI-assisted communication should address the AI-governance questions (the model's training-data provenance, the model's bias, the model's accuracy, the human-in-the-loop checkpoint, the data-residency and DPDP-compliance of the AI service).

The integrated resilience communication

The 7.4 communication discipline is increasingly integrated with the broader enterprise resilience communication, the cyber resilience (under ISO/IEC 27001 and the RBI cyber framework), the operational resilience (under DORA Article 28 for EU financial entities and APRA CPS 230 for Australian financial entities), the supply-chain resilience (under the RBI MD Outsourcing of IT Services), the climate resilience (under the ISO 22301:2019 Amendment 1:2024), and the public-health resilience (under the post-COVID operational expectations). The trend is toward a single integrated resilience communication programme that satisfies multiple management-system clauses and multiple regulator regimes simultaneously.

The deepfake and disinformation threat

The deepfake and disinformation threat is a 7.4 risk that did not exist five years ago. A deepfake of the CEO announcing a "bank run" or a "data breach" can move markets, trigger customer panic, and damage the brand before the organisation's official communication can respond. The trend is toward (a) the rumour-control and social-listening design including deepfake detection (the commercial social-listening platforms are adding deepfake-detection features); (b) the spokesperson discipline including a deepfake-response protocol (the "we did not say that; here is what we said" response); and (c) the customer and workforce education including deepfake awareness (the audience's ability to recognise a deepfake is part of the audience's communication competence).

The climate-change communication

The ISO 22301:2019 Amendment 1:2024 added climate-change adaptation to Clauses 4.1 and 4.2. The communication implication is that the organisation's BCMS communication must address climate-change-driven disruption scenarios, the heatwave, the urban flooding, the cyclone intensification, the sea-level rise, the supply-chain climate exposure, and must coordinate with the public climate-adaptation communication (the NDMA, the state and district authorities, the India Meteorological Department). The trend is toward climate-change communication as a defined sub-discipline of the 7.4 programme.

The customer-trust communication

The DPDP Act 2023 and the DPDP Rules 2025 have made the customer-data breach-notification a regulated communication. The trend is toward the customer-trust dimension of breach communication becoming as important as the legal dimension, the customer who receives a clear, empathetic, action-oriented breach notification is more likely to stay than the customer who receives a legalistic, defensive, action-light notification. The customer-trust communication discipline (the tone, the empathy, the action-orientation, the remedy commitment, the post-incident follow-through) is an emerging sub-discipline of 7.4.

The regulator-by-data communication

The Indian regulators are increasingly using data analytics to supervise the regulated entities, the RBI's advanced supervisory tools, the SEBI's data-driven surveillance, the IRDAI's analytics-based supervision. The trend is toward the regulator communication being continuous and data-fed, not episodic and incident-driven. The 7.4 programme that treats the regulator communication as a once-a-year compliance filing will find the new regulator-by-data environment challenging; the programme that treats the regulator communication as a continuous engagement will find it easier.

References and Further Reading

The references below are the Tier-1 sources (per the standard's sources.md) for the claims in this guide. Where a claim could not be machine-verified against a primary .gov.in or iso.org source, the source is marked as supplementary.

The standard and its companions

• ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements. International Organization for Standardization, Geneva. The standard (clause text paraphrased in this guide; not reproduced).
• ISO 22301:2019/Amd 1:2024, Climate change adaptation amendment.
• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301.
• ISO 22300:2021, Security and resilience, Vocabulary. (A fourth edition is under development (ISO/DIS 22300, 4th ed.) and not yet published; verify on iso.org.)
• ISO/TS 22318:2021, Supply chain continuity.
• ISO/TS 22330:2018, People resilience.
• ISO/IEC 27031:2011, ICT readiness for business continuity.

Cross-framework and resilience references

• ISO/IEC 27001:2022, Information security management systems, Requirements. Clause 7.4 and Annex A controls 5.29, 5.30, 8.13, 8.14, 5.6, 5.7, 5.24 to 5.28, 6.8.
• NIST SP 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems, May 2010.
• NIST SP 800-61 Rev 2, Computer Security Incident Handling Guide.
• NIST CSF 2.0, Cybersecurity Framework, 26 February 2024 (NIST.CSWP.29). Recover function Communicate category (RC.CO).
• FFIEC BCM Booklet, November 2019 (OCC 2019-57, FRB SR 19-13, FDIC FIL-19071).
• DORA, Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022. Applies 17 January 2025.
• APRA CPS 230, Operational Risk Management, effective 1 July 2025.
• MAS TRM Guidelines; HKMA TM-G-2 and SA-2.

Indian regulatory instruments

• RBI Master Direction, Information Technology Governance, Risk, Controls and Assurance Practices, 7 November 2023 (effective 1 April 2024). RBI portal.
• RBI, Cyber Security Framework in Banks, 2 June 2016. RBI portal.
• RBI Master Direction, Outsourcing of Information Technology Services, 10 April 2023. RBI portal.
• RBI, Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators (Master Direction).
• SEBI, Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, 20 August 2024 (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113). SEBI portal.
• SEBI, Guidelines for Business Continuity Plan and Disaster Recovery of Market Infrastructure Institutions, 22 March 2021 (SEBI/HO/MRD1/DTCS/CIR/P/2021/33). SEBI portal.
• IRDAI, Information and Cyber Security Guidelines, 2023, 24 April 2023. IRDAI portal.
• CERT-In, Directions under Section 70B(6) of the IT Act 2000, 28 April 2022 (No. 20(3)/2022-CERT-In). cert-in.org.in.
• Digital Personal Data Protection Act, 2023 (Act 22 of 2023), particularly Section 8(5) (availability duty) and Section 8(6) (breach notification). meity.gov.in.
• Digital Personal Data Protection Rules, 2025 (draft 3 January 2025; final notified November 2025, verify exact notification date against the MeitY gazette copy).
• Companies Act, 2013, Section 134(3)(n) (board risk statement); Section 177 (Audit Committee). mca.gov.in.
• SEBI LODR Regulation 30 (material-event disclosure) and Regulation 21 (Risk Management Committee).
• Disaster Management Act, 2005 (Act 53 of 2005). ndma.gov.in.
• NDMA, Guidelines for Preparation of Disaster Management Plans for Ministries and Departments of the Government of India.
• NDMA, Chemical Disaster (Industrial) Guidelines, 2007.
• Information Technology Act, 2000 (Act 21 of 2000, as amended by the IT (Amendment) Act, 2008). indiacode.nic.in.

Practitioner bodies of knowledge and data reports

• BCI practitioner guidance (31 October 2023), the Business Continuity Institute's practitioner reference.
• DRI International, DRI professional-practice framework (living framework; free at drii.org).
• BCI Horizon Scan 2025, Complex and Interconnected Risk.
• BCI Horizon Scan 2024, IT/telecom outages most-disruptive; productivity-loss data.

Incident and case anchors

• AIIMS Delhi ransomware (November 2022), peer-reviewed case in Indian Journal of Medical Informatics; The Hindu reporting on the NIA takeover.
• HDFC Bank RBI action (2 December 2020), RBI order; FinExtra and LiveMint reporting.
• Yes Bank moratorium (5 to 18 March 2020), Yale Journal of Financial Compliance case.
• Cognizant Maze ransomware (April 2020), SEC-filed 10-Q/10-K, USD 50 to 70 million impact.
• Cognizant Chennai floods response (December 2015), Cognizant official statement; FY2015 revenue guidance reaffirmed at USD 12.41 billion.
• Jio 17 September 2024 outage, Reuters; Cloudflare Radar measured AS55836 traffic drop of up to 53 percent.
• Akasa Air CrowdStrike outage (19 July 2024), zero flight cancellations on the same day IndiGo cancelled approximately 283 flights. The Hindu and Livemint reporting.
• NPCI / UPI nationwide outage (12 April 2025), approximately five hours; Times of India and ORF reporting.
• LG Polymers Vizag styrene release (7 May 2020), NGT interim penalty of INR 50 crore (OA 73/2020).
• Tokyo Stock Exchange full-day halt (1 October 2020), Reuters; JPX trading-system report.
• DBS Bank recurring digital-banking outages (2018/2021/2023), MAS six-month pause on non-essential IT changes; operational-risk capital multiplier.
• CrowdStrike global IT outage (19 July 2024), The Guardian; Parametrix USD 5.4 billion Fortune 500 direct-loss estimate.
• Colonial Pipeline ransomware (7 May 2021), DOJ seizure; CISA advisory.
• Change Healthcare ransomware (21 February 2024), UnitedHealth Q3 2024 disclosure.

How the references are used

The references above anchor the factual claims in this guide, the regulator-clock numbers, the regulator-circular dates, the framework-clause numbers, the incident facts. Where a claim is the author's own analysis (the four-decision model, the six-phase lifecycle, the eleven-audience map, the maturity model, the INR estimates, the illustrative scenarios), no external reference is required; the analysis is the value. Where a claim is drawn from a reference, the reference is cited by name and (where relevant) by date and number.

Singahi, the ISO 22301 specialists for growing companies in India.