Clause 7.4 Communication

The fastest way to understand Clause 7.4 is to picture the artifact that satisfies it: a communication matrix. One table, five columns — topic, trigger or frequency, audience, owner, channel — and a row for every communication the ISMS relies on. Policy launches, awareness messages, management review outcomes, incident escalations, breach notifications, customer security updates, certification body correspondence. If you can produce that table and show it reflects what actually happens, you have met the clause.

The internal half is the plumbing of the management system: policy and procedure changes reaching the people they bind, security objectives and progress against them, incident escalation paths, and the results of audits and management reviews reaching the people who must act on them. This is the machinery that Clause 7.3 (awareness) and Clause 5.1 (top management communicating the importance of security) both depend on.

The external half is broader than most teams first assume. Customers increasingly consume your security story through trust centers, security pages, and questionnaire responses. Regulators have notification expectations — some with hard deadlines measured in hours. Your certification body must be told about significant changes to scope, ownership, or major incidents under most certification agreements. Suppliers need security requirements communicated to them. Each of these is a row in the matrix with a named owner.

The highest-stakes rows are the crisis ones, where 7.4 intersects incident management planning (A.5.24): who speaks for the organization during an incident, who approves the wording, which regulator is notified within which window. What auditors treat as the heart of the clause is deliberateness — they pick a real communication from the audit period, an incident notice or a policy rollout, and trace it: was this planned, did the named owner send it, on the agreed trigger, through the agreed channel?

Communication failures rarely show up on quiet days. They detonate during incidents. The pattern repeats across post-incident reviews: the engineers know exactly what happened, but nobody agreed who tells customers, legal has not pre-approved any language, and a regulatory notification deadline expires while the draft cycles through approvals. A determined communication plan costs an afternoon to build. Its absence costs trust at the precise moment trust is hardest to rebuild.

For certification, 7.4 is checked at Stage 1 as part of the documentation review — does a determination exist at all — and tested at Stage 2 against reality. A missing or purely decorative communication plan typically draws a minor nonconformity. Communication failures the auditor finds inside a sampled incident record — a notification sent late, or never — can escalate the finding and bleed into the incident-management controls as well.

When communication is left to improvisation:

• Blown notification windows – several regimes measure breach-reporting deadlines in hours, and they expire while teams debate who calls whom
• Contradictory messages – the status page, the support team, and the account managers tell three different stories during an incident, and customers remember the contradiction longer than the outage
• Policies that never land – publishing without a planned communication path leaves staff unaware, which resurfaces later as Clause 7.3 interview failures
• A certification body kept in the dark – unreported scope changes, ownership changes, or major incidents can put the certificate itself at risk under the certification agreement
• Evidence gaps at audit – communications genuinely happened but left no trace, forcing teams to reconstruct email threads the week before Stage 2