ISO 27001 Clause 7.4: Planning and Evidencing ISMS Communication

An information security management system that lives only in a policy folder will fail the moment it's tested — not by an auditor, but by your own people. If staff don't know where the policies are, who to call when something goes wrong, or what changed after the last risk review, the ISMS isn't operating; it's decorating. Clause 7.4 of ISO 27001:2022 exists to close that gap. It's short, easy to underestimate, and one of the first places a certification auditor will poke when they interview your team. This article explains what the clause demands, how to build a communication plan that holds up, and how to generate the evidence that proves you're actually following it.

What Clause 7.4 Actually Requires

The clause asks your organisation to determine the need for internal and external communications relevant to the ISMS, and to answer four questions for each of them:

What will be communicated — the subject matter of each message.
When it will be communicated — the schedule or the trigger event.
With whom it will be communicated — the audience, inside and outside the business.
How it will be communicated — the channel and mechanism.

That's the whole text. There's no mandated template, no prescribed frequency, and no requirement for a document titled "Communication Plan". But the operative word is determine: an auditor won't accept that communication "just happens". You need a deliberate, documented decision-making process — and, in practice, the cleanest way to show that is a simple communication matrix covering the four questions above for every recurring ISMS message.

Clause 7.4 also sits at the centre of the Clause 7 "Support" family. Competence (7.2) and awareness (7.3) define what people must know; communication is the delivery mechanism that gets it to them. Treat it that way and the rest of the clause structure falls into place.

Building the Communication Plan

What to communicate

Start from your ISMS, not from a generic list. Typical entries include:

The policies themselves — where they're stored, what's changed, and what each person is accountable for.
Incident reporting — how to raise a security event, and who the first point of contact is.
Risk posture — significant risks, treatment decisions, and anything that changes how people should behave.
ISMS performance — audit results, management review outcomes, metrics and monitoring findings.
Threat awareness — phishing campaigns, new scams, and lessons from real incidents (yours or others').
Changes to the ISMS — scope changes, new controls, updated procedures, supplier changes.

When to communicate

There's no single right cadence, but a workable pattern for most Australian SMEs is:

Onboarding and offboarding — security expectations on day one; confidentiality obligations on the way out.
Event-driven — immediately after incidents, control changes, or newly identified risks.
Quarterly or monthly — security tips, threat updates, metrics to leadership.
Annually — policy refreshes, awareness training re-attestation, and the management review cycle.

The test an auditor applies is whether the timing is adequate: too infrequent and awareness decays; too frequent and people start muting you. Match the frequency to the risk each message manages.

With whom to communicate

Internal — all staff for awareness-level messages; targeted groups (IT, incident responders, department heads, the board) for role-specific content.
External — customers with contractual notification rights, regulators (for example, the OAIC under the Notifiable Data Breaches scheme), suppliers, and your certification body.

Your interested parties analysis from Clause 4.2 is the natural source for the external list. Don't forget it — missing external stakeholders is one of the most common Clause 7.4 findings we see when conducting internal audits.

How to communicate

Use the channels your organisation actually reads: team meetings, all-hands sessions, email, Teams or Slack announcements, the intranet, and training modules. Two rules matter more than the channel itself:

Match the channel to the sensitivity — incident details and breach notifications belong in controlled, access-restricted channels, not open email threads.
Assign an owner — name the role authorised to send each class of message, so technical alerts don't contradict policy and nobody freelances during a crisis.

---

Evidencing It for the Audit

Having a plan is half the requirement; the other half is proving you executed it. Auditors live by "show, don't tell", so build evidence capture into the process itself rather than reconstructing it the week before the audit.

Keep a communication matrix — one living document mapping what, when, with whom and how, version-controlled like the rest of your documented information.
Retain proof of delivery — sent-folder archives, meeting minutes, intranet announcements, and training completion records with dates and names.
Capture acknowledgement — signed or digital confirmations for policy acceptance, especially at onboarding and after major policy changes.
Measure effectiveness — short quizzes, phishing simulation results, or spot-check interviews show people understood the message, not just received it.
Review it at management review — a standing agenda item on communication adequacy turns Clause 9.3 into your evidence of continual improvement.

If your governance and compliance program is mature in other areas, this is usually the lightest-lift clause in the whole standard — the evidence is a by-product of doing the work, not extra work.

Common Pitfalls to Avoid

Send and forget — broadcasting emails with no record of receipt or understanding. Keep archives and test comprehension.
The ghost plan — a communication matrix written for certification and never touched again. Auditors check version history and interview staff.
Internal-only thinking — a plan that covers staff but says nothing about regulators, customers or suppliers. External obligations carry legal deadlines.
No named sender — unclear authority over who may speak for the ISMS, which collapses exactly when an incident hits.
Communicating change late — updating controls or infrastructure without telling the people affected, leaving them working to outdated procedures.

---

Keeping the Plan Alive

Communication needs shift as your threat landscape, structure and obligations change. Revisit the matrix after every significant incident, audit finding, or organisational change, and fold the lessons back in. For smaller teams without a dedicated security lead, a vCISO arrangement can own this rhythm — chairing the reviews, keeping the matrix current, and making sure nothing slips between audits.

Done well, Clause 7.4 stops being a compliance artefact and becomes the connective tissue of your ISMS: the mechanism that turns documented intent into organisation-wide behaviour. That's what certification auditors are really looking for — and it's what actually reduces your risk.

Assess your ISO 27001 readiness with our FREE ISO 27001 Gap Assessment Tool — instant results, no sign-up required.