Clause 7 · Support

7.4 — Communication

Security incidents are rarely made worse by too much communication. They are made worse by nobody having decided in advance who needed to know what.

Mandatory requirementDocumented information required: No

In plain language

In plain language: 7.4 requires you to decide, in advance, what you need to communicate about the ISMS, to whom, when, and how — covering both internal audiences (staff, leadership) and external ones (customers, regulators, certification bodies) — rather than improvising communication in the moment.

Position in the standard

Clause 7 · Support
7.4 · Communication ← you are here
See also: 7.1 · 7.2 · 7.3 · 7.5

Why this requirement exists

When an incident or a significant ISMS change happens, the worst time to figure out who needs to be told is in the middle of it. This requirement forces that planning to happen ahead of time, so a breach notification, a policy update, or a scope change follows a known path instead of an improvised one.

Scenario: a data incident occurs and the response team spends the first critical hours debating who should be told — legal, affected customers, a regulator, the board — instead of executing a plan. A defined communication plan, decided calmly before any incident, would have made those calls automatic.

What the standard expects

The standard expects the organization to determine the need for internal and external communications relevant to the ISMS, including what to communicate, when to communicate, with whom to communicate, who communicates, and the processes by which communication is affected.

In practice

  • Build a short communication matrix: trigger event, audience, channel, timing, and owner — for both routine updates and incident scenarios.
  • Cover external obligations explicitly — breach notification timelines to regulators or customers are often legally mandated and time-sensitive.
  • Keep the plan short enough that people actually remember it exists — a communication plan nobody can find in a crisis does not help.

Evidence the auditor will ask for

  • A documented communication plan or matrix covering internal and external audiences.
  • Examples of the plan being followed — a policy update actually communicated, an incident notification actually sent per the defined process.

Common pitfalls

  • A communication plan that covers internal staff updates but says nothing about external notification obligations.
  • No named owner for a given communication — everyone assumes someone else will send it.

Related requirements

Parent link: Clause 7 · Support

Frequently asked questions

Does the communication plan need to be a standalone document?
Not necessarily — it can live inside your incident response plan or a broader policy, as long as the what/when/who/how is clearly addressed somewhere an auditor can find it.

Decide who needs to know what — before you need to.

Sentrix helps you build a communication plan that covers both routine ISMS updates and incident notification obligations.