Communication

ISO 22301 Clause 7.4 requires you to define BCMS-related internal and external communications and to put in place procedures you can execute during a disruption. Operationally, you need a documented communication plan, assigned roles, approved message paths, and redundant channels, plus evidence that the plan is tested and works under stress. ¹

Key takeaways:

• Document who communicates what, to whom, when, and how for BCMS topics, not just “in an incident.” ¹
• Build disruption-ready procedures: authority, escalation, templates, and channel failover. ¹
• Keep evidence that communications are controlled, current, trained, and exercised. ¹

“Communication” in ISO 22301 is an execution requirement, not a branding exercise. Clause 7.4 expects you to decide which communications matter to the BCMS (internal and external) and to establish procedures you can rely on during disruption. ¹

CCOs and GRC leads usually inherit communication fragments: an HR phone tree, an IT incident page, a crisis PR playbook, and a third-party notification clause in procurement templates. Auditors then ask the obvious questions: Who is authorized to declare disruption? Who talks to regulators, customers, and critical third parties? What happens if email and chat are down? Where are the approved messages? How do you prevent conflicting statements across teams?

This page translates Clause 7.4 into a requirement-level implementation approach you can stand up quickly: define scope and audiences, assign decision rights, build disruption-specific procedures with redundancies, and capture evidence that the process is maintained and tested. It also flags the hangups that slow certifications and internal audits, especially around ownership, channel resilience, and external notification commitments. ¹

Regulatory text

ISO 22301:2019 Clause 7.4 (Communication): “The organization shall determine internal and external communications relevant to the BCMS and establish procedures for communicating during disruption.” ¹

Operator meaning (what the standard expects you to do):

• Determine communications relevant to the BCMS: decide which messages, stakeholders, and situations fall under business continuity communications (for example: incident/disruption declarations, status updates, workarounds, resumption notices, and post-incident communications). ¹
• Cover internal and external audiences: employees and leadership, plus customers, regulators (if applicable to your business), emergency services (as relevant), and critical third parties such as cloud providers, call centers, and logistics partners. ¹
• Establish procedures for disruption communications: define roles, escalation, approval paths, channels, timing triggers, and failover methods that still work when primary systems are unavailable. ¹

Plain-English interpretation (requirement-level)

You must be able to answer, in writing and in practice:

1. Who communicates (named roles, not departments).
2. What gets communicated (message types and minimum content).
3. To whom (audience lists, including external parties).
4. When (triggers and cadence during disruption).
5. How (channels, tools, and backups).
6. Under what authority (who can approve and who can speak publicly). ¹

If you cannot execute communications when corporate email, Teams/Slack, network access, or normal approvals are disrupted, you have not met the intent of Clause 7.4. ¹

Who it applies to (entity and operational context)

Applies to: any organization implementing or certifying to ISO 22301 and operating a BCMS. ¹

Operational contexts that make Clause 7.4 “high scrutiny”:

• Centralized comms control (PR/legal gatekeeping) that may slow disruption updates.
• Regulated or contractual notification obligations (common in financial services, healthcare, SaaS, and critical supply chains), even if the specific obligations are outside ISO 22301.
• Dependence on third parties for core operations (cloud, payroll, customer support outsourcers), where your communication plan must coordinate across organizational boundaries.
• Multi-site operations where localized incidents require targeted instructions and multi-language communications. ¹

What you actually need to do (step-by-step)

Step 1: Set BCMS communication scope and ownership

• Name an executive owner for disruption communications (often Crisis Manager, COO delegate, or BC Lead) and a content owner (often Comms Lead) with documented authority boundaries.
• Define which events trigger the BCMS communication procedures (for example: disruption declaration, activation of alternate site, invocation of manual workarounds, or extended service degradation).
• Clarify relationship to adjacent processes (incident response, cybersecurity, HR emergency comms, safety). Avoid competing “source of truth” channels. ¹

Step 2: Build a communications requirements matrix

Create a table that an operator can run without interpretation:

Audience	Purpose	Trigger	Sender (role)	Approval	Channel(s)	Backup channel	Record kept
Employees	Safety/work instructions	Disruption declared	BC Lead or HR Lead	Crisis Manager	SMS, intranet	Voice tree	Copy of message + distribution log
Exec team/Board	Decision support	Initial assessment + cadence	Incident/Crisis Lead	N/A	Phone bridge	Satellite/alt bridge	Situation reports
Customers	Service status + workarounds	Customer impact confirmed	Customer Comms Lead	Legal/PR	Status page, email	Support banner	Status updates archive
Critical third parties	Coordination	Dependency impacted	Vendor/TPRM Lead	Crisis Manager	Phone/email	Alternate contacts	Call notes + tickets

Tune the matrix to your business, but keep the structure. Auditors want to see that internal and external communications are “determined,” not improvised. ¹

Step 3: Define disruption-ready procedures (not just a plan)

Your procedure should answer these execution questions:

• Activation: who declares disruption communications “on,” and how that decision is recorded.
• Cadence: how you schedule updates (for example: “initial within X,” “recurring every Y,” or “on material change”). If you pick numeric targets, make them internal commitments you can meet consistently.
• Message control: how you prevent conflicting statements (single message owner, versioning, and approvals).
• Confidentiality and legal review: what must be reviewed by legal/privacy before external release, and what can be pre-approved.
• Channel failover: what you do if primary tools are unavailable (personal phones, alternate bridges, out-of-band messaging, printed call lists). ¹

Step 4: Pre-stage content and contact data

• Build message templates for common disruption scenarios (internal instruction, customer status, third-party coordination, leadership briefing).
• Maintain call trees and external contact lists with owners and refresh triggers (new contract, re-org, supplier change).
• Keep distribution groups controlled (who can send to all-staff, who can post to status page).
• Store critical artifacts in a resilient location reachable during an outage (offline-capable repository or printed emergency binder, as appropriate to your environment). ¹

Step 5: Train and exercise communications as part of BCMS testing

• Train primary and backup communicators on the procedure and tools.
• Include communications injects in tabletop exercises: conflicting facts, executive unavailability, third-party outage, and channel failure.
• Capture what was sent, when, by whom, and what approvals occurred. Treat this as audit evidence. ¹

Step 6: Operationalize with governance and change control

• Add the communication procedure to the BCMS document control process (versioning, approval, distribution).
• Review after disruptions and exercises. Update templates, call lists, and channel assumptions. ¹

Where Daydream fits naturally Most teams fail Clause 7.4 on execution details: stale contacts, unclear approvals, and missing evidence. Daydream can serve as the control system of record for your communication matrix, maintain third-party contact points tied to suppliers, and produce an audit-ready evidence pack (approved procedures, distribution lists, exercise outputs) without hunting across chat logs and shared drives.

Required evidence and artifacts to retain

Auditors typically expect to see:

• BCMS Communication Procedure (during disruption): roles, triggers, approvals, channels, backups. ¹
• Internal/External Communication Matrix covering relevant stakeholders. ¹
• Approved templates (version-controlled) and guidance on when to use each.
• Contact lists / call trees with ownership and last review/refresh record.
• Training records for communicators and alternates.
• Exercise records: scenarios, messages sent, timelines, approvals, lessons learned, and resulting updates.
• Incident/disruption communication logs (if real events occurred): copies of notices, status page archives, stakeholder notifications, and decision notes. ¹

Common exam/audit questions and hangups

Expect these, and pre-answer them in your artifacts:

• “Show me how you determined which external parties must be notified during disruption.” ¹
• “Who is authorized to communicate externally, and where is that documented?” ¹
• “What happens if email and chat are unavailable?” ¹
• “How do you ensure messages are consistent across IT, customer support, HR, and PR?”
• “Prove the procedure works: show an exercise or real event record.” ¹

Auditors often hang up on external communications because organizations document internal comms well but rely on ad hoc customer and third-party notifications.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating comms as a single document.
   Fix: build a matrix + procedure + templates + contact governance. ¹

2. Mistake: no backup channels or dependency on the same identity system.
   Fix: define out-of-band options that do not require corporate SSO, and practice switching. ¹

3. Mistake: unclear approval rights under time pressure.
   Fix: pre-approve categories of messages and set escalation rules for exceptions.

4. Mistake: stale third-party contacts.
   Fix: tie contact refresh to supplier management events (renewals, QBRs, onboarding/offboarding) and make one role accountable.

5. Mistake: no retained evidence.
   Fix: treat every exercise and incident as an evidence-producing workflow, with logs saved to the BCMS repository. ¹

Enforcement context and risk implications

No public enforcement case sources were provided for this requirement. From a risk lens, Clause 7.4 failures typically surface as:

• delayed or conflicting stakeholder direction during disruption,
• breach of contractual notification expectations,
• reputational harm from inconsistent external statements,
• operational losses from poor coordination with critical third parties. ¹

Practical 30/60/90-day execution plan

First 30 days: establish the minimum viable communication capability

• Assign roles, backups, and decision rights for disruption communications. ¹
• Build the communication matrix for your top internal groups and top external parties (customers, critical third parties). ¹
• Draft the disruption communication procedure with channel failover.
• Produce initial templates and stand up a controlled repository for them.

By 60 days: make it executable

• Validate contact lists and distribution groups; confirm ownership and refresh triggers.
• Run a tabletop exercise focused on communications failure modes (conflicting facts, tool outage, exec unavailable). ¹
• Update procedure and templates based on findings; document changes under version control.

By 90 days: make it auditable and repeatable

• Integrate communications testing into your BCMS exercise program and post-incident review loop. ¹
• Create an evidence pack format: procedure, matrix, templates, training, exercise outputs, and sample communications logs.
• If you manage many third parties, consider Daydream to maintain third-party communication points and produce consistent evidence on demand.

Frequently Asked Questions

Do we need separate internal and external communication procedures?

Clause 7.4 requires you to determine both internal and external communications and to have disruption communication procedures. ¹ You can keep one procedure if it clearly distinguishes audiences, approval paths, and channels.

What counts as “communication relevant to the BCMS”?

Anything stakeholders must know to keep priority activities running during disruption: declarations, work instructions, service status, workarounds, resumption steps, and coordination requests. Document your choices in a communication matrix. ¹

How do we prove compliance if we haven’t had a real disruption?

Use exercise evidence: scenarios, drafted/sent messages, approval records, and lessons learned that result in updates to the procedure. Auditors accept tested readiness as long as it’s documented and controlled. ¹

Do we need a dedicated status page?

ISO 22301 does not mandate a specific tool; it requires that you establish procedures for communicating during disruption. ¹ Choose channels that match your stakeholders and include a backup if your primary channel fails.

How should we handle third-party communications during a disruption?

Treat critical third parties as a named external audience with specific triggers, contacts, and coordination messages in the matrix. Keep current escalation contacts and record notification attempts and outcomes during exercises and incidents. ¹

Who should approve external messages when time is tight?

Pre-define approval authority by message type and risk level, and pre-approve standard templates to reduce bottlenecks. Escalate only the exceptions (for example, statements that create legal exposure or commit to timelines). ¹

Footnotes

1. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements