Communication is the capability that most organisations underestimate in their BCMS. A BCMS that has excellent recovery procedures but fails to communicate effectively during the disruption will lose stakeholder confidence, suffer regulatory findings, and sustain reputational damage independent of how well the recovery itself goes. The ability to communicate clearly and consistently — to internal staff, to clients, to regulators, and (if necessary) to the public and media — determines the organisational outcome of a disruption event, because it determines whether stakeholders believe the organisation has the situation under control and is managing it responsibly.
ISO 22301 requires that communication procedures be documented in the BCMS (Clause 7.4 and 8.4). Clause 8.4 specifically requires BCPs to include communication procedures and the arrangements for notifying all relevant parties. This requirement is often interpreted narrowly (""we need a contact list and a notification template"") when it should be interpreted broadly (""we need a complete communication strategy that addresses all stakeholder groups, covers the entire duration of the disruption, and is coordinated across internal, external, regulatory, and media channels"").
The ISO 22301 Communication Requirement
ISO 22301 Clause 7.4 requires the organisation to ”determine communication needs and how communication shall be addressed within the BCMS"", including: (a) communication channels, including those that may remain available in unusual circumstances; (b) means of access to communication systems and channels for use during an incident or disruption; (c) information to be communicated; and (d) people and organisations that may need communication. Clause 8.4 requires BCPs to include communication procedures and contact information. These requirements define the scope of communication planning: it is not optional, and it must cover multiple channels (not just email), must address scenarios where normal channels are unavailable, must specify what information will be communicated, and must reach all relevant stakeholders.
The most common shortfall in communication planning is that it focuses only on internal staff notification and overlooks external stakeholders (clients, regulators, media). Another shortfall is treating communication as a one-time activity (""we will send one notification telling everyone the incident has occurred"") rather than as an ongoing dialogue throughout the disruption (initial notification, status updates, resolution notification, post-incident communication). A third shortfall is assuming that normal communication channels will be available; in a major disruption, email may be unavailable, phone systems may be congested, and the organisation may need to activate alternative channels (SMS, WhatsApp, website, media statements).
Internal Communication During Disruption
Internal communication serves multiple purposes during a disruption: it notifies staff of the incident and whether to report to work, it provides staff with their role assignments and what they need to do, it keeps staff informed of incident progression and expected duration, it manages rumours and keeps staff focused on their assigned activities, and it maintains staff morale by demonstrating that leadership has the situation under control. Internal communication typically proceeds through a cascade: executive leadership is notified first, then operational managers, then front-line staff, then support staff.
The cascade structure prevents overwhelming communication channels with a broadcast notification; instead, information flows down the chain with each level adding context or specific instructions relevant to their scope. For example: the Chief Risk Officer notifies the CEO that the plan is activated; the CEO notifies department heads; department heads notify their teams; team leaders provide specific instructions to their staff. Each level of the cascade takes approximately 5–10 minutes, so a full cascade from CEO to all staff might take 30–45 minutes for an organisation with 500 people.
Command bridge protocols establish how leadership coordinates during a disruption. A command bridge is a regularly scheduled conference call or video meeting (e.g., every 30 minutes) where incident command, operational managers, and support functions gather to share status, make decisions, and coordinate actions. The command bridge serves as the information hub; decisions made in the command bridge are communicated downward to operational staff, and status information from operational teams is reported upward through the command bridge.
External Stakeholder Communication
External communication is significantly more complex than internal communication because there is no single relationship with external stakeholders; each stakeholder group (clients, regulators, media, public) has different information needs, different time expectations, and different regulatory obligations. Clients need to know what services are affected, when they will be restored, and what interim arrangements are available. Regulators need to know what happened, what the impact is, what the organisation is doing about it, and when the situation will be resolved. Media and the public need assurance that the organisation is managing the situation responsibly and transparently.
Communication to clients must be prioritised by client importance and service dependency. Tier 1 clients (those with the largest account balances or transaction volumes, or those with critical service dependencies) should be notified directly within 2–4 hours of incident declaration; Tier 2 clients should be notified within 4–8 hours; and mass notification to all clients should occur within 8–24 hours. Prioritised notification prevents the situation where a large client becomes aware of the disruption through another channel (social media, news) before hearing from the organisation directly.
Pre-Written Communication Scripts and Templates
The value of pre-written scripts and templates is that they are already approved, they have been reviewed for legal/compliance implications, and they can be deployed quickly without time spent drafting and approval during a stressful event. Pre-written scripts do not constrain communication; they provide a starting template that can be adapted to the specific incident. Templates should be scenario-specific: an IT system outage communication looks different from a ransomware incident communication, which looks different from a premises disruption.
Pre-written scripts should include not only the message content but also the distribution list, the distribution channel (email, phone call, press release), and the approval required before sending. For example, a client notification script might specify: ""Send to Tier 1 clients via phone call from Account Manager. Script: [message]. Account Manager to record time of contact and client response in incident log. Regional Manager to approve before any calls are made. If client indicates they are switching providers, escalate immediately to Account Director."" This level of detail ensures consistent execution during the disruption.
| Communication Scenario | Template Elements | Approval Required |
|---|---|---|
| IT system outage affecting client services | Incident acknowledgment; affected services; workaround available; expected resolution; next update | Customer communications manager; no CEO approval required for standard outage |
| Premises unavailability (fire/flood) | Staff safety confirmed; alternative working arrangements; client impact; timeline; staff contact point | Operations Director; CEO if client-facing |
| Ransomware / cyber incident | Incident confirmed; investigation underway; law enforcement notified; client data status; OJK/BSSN notification | CEO; Legal; PR agency; no speculation on root cause or data impact until known |
| Pandemic / mass illness | Staff welfare priority; service continuity measures; client impact; remote working activated | CEO; HR Director |
| Supplier failure causing service disruption | Supplier issue identified; contingency activated; client impact; resolution timeline | Operations Director; Account Management for affected clients |
| KEY IDEA | Regulatory notification is not optional and timing matters. OJK-supervised entities must notify OJK of significant IT incidents and BCM activations within specified timeframes — failure to notify on time can result in regulatory findings independent of the incident itself. The BCP must include: who is responsible for regulatory notification, what the notification must contain, what the timelines are, and a template for the notification. These should be pre-prepared, pre-approved, and tested in exercises — not drafted during a live incident. |
Social Media Crisis Management During a Disruption Event
Social media during a crisis moves faster than any internal communication process. A client who cannot access a service will tweet about it, post on Facebook, or share it on WhatsApp groups within minutes of discovering the problem. If the organisation has not already provided information, the social media narrative will be shaped by user speculation, rumour, and complaint. The BCMS communication plan must include social media monitoring as a mandatory step in the first hour of any significant disruption, a designated social media responder with pre-approved response templates, and clear authority limits on what can be said without executive approval.
Social media responses should be brief, acknowledge the issue, and direct users to an official channel for more information. Example: ""We are aware that customers are experiencing delays accessing our services. Our technical team is investigating. For updates, please visit [website] or call [number]. We will provide an update in 30 minutes."" This response acknowledges the issue (eliminating the perception that the organisation is unaware), provides a time expectation for the next update, and directs users to an official channel. Follow-up updates should be posted at regular intervals (every 30–60 minutes during the acute phase) to maintain the narrative.
| IMPORTANT | Social media during a crisis moves faster than any internal communication process. A client who cannot access your service will tweet about it before your communications team has been notified. The BCMS communication plan must include social media monitoring as a mandatory step in the first hour of any significant disruption, a designated social media responder with pre-approved response templates, and clear authority limits on what can be said without CEO/Legal approval. Silence on social media during a visible disruption is interpreted as either ignorance or evasion — neither is the desired signal. |
| Stakeholder | Notification Trigger | Channel | Key Message Elements |
|---|---|---|---|
| Board/Directors | Immediately | Phone call from CEO | Incident description; business impact; BCP activated; initial RTO; board action needed |
| Executive leadership | Within 30 min | Email + phone cascade | Incident description; affected areas; BCP activated; initial RTO; next update time |
| Operational staff | Within 1 hour | Email + intranet + phone cascade | What happened; your role; where to report; system status; first actions |
| Priority clients (Tier 1) | Within 2-4 hours | Direct phone call from Account Manager | Acknowledgment; service impact; interim arrangements; resolution timeline; contact person |
| All clients | Within 8-24 hours | Email + website announcement | Incident acknowledgment; service impact; recovery status; workarounds; next update |
| OJK/BI/BSSN | Per regulatory timeline (often 24h) | Official letter + secure email | Incident description; scope; systems affected; customer impact; recovery ETA; regulatory SLA impact |
| Media | Only if external visibility | Press release to major outlets | Prepared statement; single spokesperson; focus on management and resolution |
| General public | Only if widespread visibility | Website + social media | Acknowledgment; we are managing it; updates available at [channel] |
| BITLION INSIGHT | Indonesian organisations often treat regulatory communication as a post-resolution activity — sending the notification after the incident is closed. Most regulatory frameworks, including OJK and Bank Indonesia, require notification during the incident, not after. The notification obligation is triggered by the incident, not by its resolution. BCPs should include a regulatory notification workflow that is activated in parallel with recovery procedures, with a designated regulatory liaison who maintains the notification thread throughout the event, not a retrospective report drafted when normal operations resume. |