What Clause 7.4 Requires
Clause 7.4 requires the organization to determine which communications the ISMS needs — internal and external — and to answer four questions for each: what will be communicated, when it will be communicated (on what schedule or trigger), with whom, and how (through which channel or mechanism). The determination must cover everything communication-relevant to the management system, which spans routine messages such as policy updates and security objectives as well as event-driven ones such as incident notifications and regulator filings.
The 2022 revision simplified this clause. The 2013 edition listed five considerations, including defining who shall communicate and the processes by which communication takes place; the 2022 text folds both into how to communicate. Nothing changed in substance — auditors still expect each communication to have a named owner. Note also what the clause does not demand: no documented communication plan is formally required. But since you must be able to show the determination happened, almost every organization documents it anyway, typically as a one-page matrix.
Why This Clause Exists
To make security communication deliberate rather than accidental — the right messages reaching staff, customers, regulators, and the certification body by design, each with an owner, a trigger, and a channel, instead of being improvised under pressure.
What This Really Means
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?
Why It Matters
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; 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
Regional Compliance Context
For organizations in scope of the CERT-In directions, the with-whom and when of regulator communication is pre-answered: qualifying incidents on India-connected systems must be reported to CERT-In within six hours, a row your matrix and incident runbook must carry with the contact route ready before it is needed. Entities regulated by RBI or SEBI carry additional sector reporting lines, and the DPDP Act adds breach notification to the Data Protection Board and affected individuals as obligations phase in toward full effect on 13 May 2027.
In the Gulf, personal data breach notification duties under the Saudi PDPL and the UAE federal PDPL belong in the same matrix — identify the competent authority, trigger, and submission route per jurisdiction in advance rather than mid-incident.
Documented Information Required
Communication matrix (communication plan)
RecommendedA one-page table answering the clause's questions for every ISMS communication: topic, trigger or frequency, audience, owner, and channel. Not formally mandatory, but the simplest credible evidence that the determination Clause 7.4 requires actually took place.
Incident and crisis communication procedure
RecommendedDefines who speaks for the organization during an incident, who approves wording, the regulator deadlines and contact routes per jurisdiction, and pre-approved holding statements. The bridge between Clause 7.4 and incident management planning (A.5.24).
Records of significant communications
RecommendedRetained samples — policy launch announcements, regulator notifications, certification body correspondence, customer security advisories — that let an auditor trace a planned communication to its actual execution.
See the full ISO 27001 mandatory documents checklist for every document and record the standard requires.
How to Implement Clause 7.4
Inventory the communications you already make
Before designing anything, list what already flows: all-hands security updates, the status page, customer questionnaire responses, certification body correspondence, incident escalations. Most organizations discover they already perform most of the required communication informally — the gap is determination and ownership, not volume.
Build the communication matrix
One row per communication; columns for what, when or on what trigger, with whom, owner, and channel. Cover both directions: internal (policy changes, objectives, review outcomes, escalations) and external (customers, regulators, certification body, suppliers). Keep it to a page — it should be readable in a management review, not archived in a binder.
Name an owner for every row
The 2022 text folded who-communicates into how, but an unowned communication is an unsent one. Assign roles rather than individuals — incident manager, ISMS lead, head of legal — so the matrix survives turnover. The owner is accountable for the message going out on its trigger and for the record it leaves.
Pre-plan the regulatory and crisis rows
For each jurisdiction and regulator touching your scope, record the notification trigger, deadline, recipient, and submission route before any incident occurs. Draft holding statements and have legal pre-approve them. The middle of an incident is the wrong time to research a regulator's reporting portal.
Decide the customer-facing channel
Choose where security information for customers lives — a trust center, a security page, or direct account communication — and assign who keeps it current. A stale public claim is worse than no page at all: it becomes evidence against you in the next dispute or assessment.
Make the channels self-archiving
Prefer channels that retain their own record: mailing lists with archives, intranet news posts, ticketed notifications, pinned announcements. The matrix says what should happen; the archives prove it did. Retain samples of significant communications with the ISMS records.
Review the matrix on a cycle and after events
Revisit the matrix at least annually at management review, and after every significant incident or organizational change. A new regulator, a new market, a new product line — each usually adds rows. Post-incident reviews should explicitly ask whether the communication rows held up.
Audit Evidence
During Stage 1 and Stage 2 of your ISO 27001 certification audit, auditors will expect the following evidence to demonstrate conformity with Clause 7.4:
Documentation
- Communication matrix or plan showing what, when, with whom, how, and the owner for each ISMS communication
- Incident communication procedure with spokesperson, approval chain, and regulator deadlines per jurisdiction
- Samples of internal communications — policy launch posts, objectives updates, management review outcomes shared with staff
- Records of external notifications: regulator filings, certification body change notices, customer security advisories
- Management review minutes showing communication decisions or updates to the matrix
Interviews
- The ISMS lead on how communication needs were determined and how the matrix is kept current
- The incident manager or communications owner on who speaks externally during an incident and within what deadlines
- Staff outside the security team on how security messages actually reach them — a cross-check against Clause 7.3
Observations
- The live channel where security communications land — intranet, chat channel, mailing list — and its archive
- The trust center or public security page, checked for currency against actual practice
- Incident tooling showing notification templates and escalation workflows ready for use
Practitioner Insights
Most small organizations already perform nearly every communication this clause asks about — they post in the company channel when a policy changes, they email customers about maintenance, they answer security questionnaires all day. What is missing is the determination: nobody has written the full set down, so the rows nobody owns silently fail. In my experience those are almost always the same two: notifying the regulator on time and telling the certification body about significant changes. Spend one hour building the matrix from what you already do, then add the missing rows. That hour closes the clause.
I watch organizations bring a fifteen-page communication strategy to Stage 2 and then fail the simplest trace: the auditor picks one real event — a policy update, a vulnerability disclosure — and asks to see it travel through the plan. The polished strategy says one thing; the email trail shows improvisation. A one-page matrix that matches reality defends far better than a strategy document that does not. Before the audit, run the trace yourself: pick three communications from the last year and check that each had an owner, a trigger, and a record.
Common Challenges & Solutions
Challenge
During an incident, nobody is sure who is authorized to speak externally, so either nobody communicates or everybody does.
Solution
Name the spokesperson role and the approval chain in the incident communication procedure, and pre-approve holding statements with legal. Rehearse the arrangement in tabletop exercises so its first use is not a live breach. One named role with a deputy beats a committee every time.
Challenge
The communication plan was written for the certification audit and bears no resemblance to how the organization actually communicates.
Solution
Rebuild the matrix bottom-up from communications that already happen, then add only the genuinely missing rows. Keep it to one page and review it at management review so it stays a working tool. Auditors trace real events through the plan — fidelity to reality is worth more than polish.
Challenge
Regulatory notification requirements are discovered mid-incident, when the deadline is already running.
Solution
Map the regimes that apply to your scope in advance — data protection authorities, sector regulators, national CERTs — with the trigger, deadline, recipient, and submission route for each. Several regimes allow hours, not days. Keep the map inside the incident runbook with live contact details, and re-verify it whenever you enter a new market or jurisdiction.
Challenge
Internal communications happen but leave no evidence, so conformity cannot be demonstrated at audit.
Solution
Route planned communications through channels that archive themselves — mailing lists, intranet news, pinned chat announcements — and retain samples with the ISMS records. If a communication matters enough to plan, it matters enough to keep proof that it went out.
Challenge
External parties hear about significant changes late or inconsistently — including the certification body.
Solution
Add a trigger table to the matrix: which changes require notifying whom. Scope changes, legal entity or ownership changes, relocations, and major incidents typically must reach your certification body under the certification agreement; security-relevant service changes should reach customers through account teams with agreed wording. Tie the triggers into your change planning under Clause 6.3 so notification is part of the change, not an afterthought.
