ISO 27001 Clause 7.4: communication matrix and audit evidence

The due-diligence questionnaire asks who would tell your biggest client about a breach, and by when. Your answer is a communication document last edited two years ago, or a hopeful "we'd work it out on the day". ISO 27001 Clause 7.4 is the requirement that turns that answer into something an auditor can check.

This guide is for security and compliance leads at UK service providers and SaaS firms of 25–250 people. It replaces the document nobody maintains with a one-page matrix and ties the 72-hour ICO clock and client deadlines to named senders. It also shows how to prove at audit that people understood the message, not just received it.

What does ISO 27001 Clause 7.4 actually require?

ISO 27001 Clause 7.4 requires you to decide in advance what the ISMS communicates, when, to whom, who speaks and through which channel. It covers routine traffic, such as policy launches and training reminders, and high-stakes traffic, such as breach notifications. The decisions must exist before the bad day arrives.

The clause comes down to four decisions, made for each audience your ISMS needs to reach, whether staff, regulators, clients, suppliers or law enforcement:

• What: the subject matter of the message.
• When: a calendar date or an event trigger.
• To whom: the audience, internal or external.
• Who and how: the sender with authority to speak, and the channel they use.

Routine traffic is the easy half, because policy launches and training reminders follow a calendar. The high-stakes half is where the clause gets tested for real. A breach starts the UK GDPR clock, enterprise clients hold notification windows in their contracts, and a team that never decided who says what to whom has to improvise. The cost is fines, breached SLAs and conflicting messages mid-incident.

The usual error is scoping the clause down to incident alerts. Supplier notices, training nudges and post-incident debriefs sit in scope too, and an auditor who traces a recent policy update will find that gap quickly.

How do you build an ISO 27001 communication plan as a single-page matrix?

Build one row per message type: policy launches, training reminders, incident escalations, regulator filings, client notices, supplier alerts and post-incident debriefs. For each row record the audience, the trigger (calendar-driven or event-driven), the authorised sender and the channel. That single page answers every question the clause asks, without a document nobody maintains.

Take the client breach notice as a worked row. The audience is the affected client's security contact. The trigger is a confirmed incident touching their data. The sender is the managing director or a named deputy, and the channel is a phone call followed by email.

Three habits keep the page short and alive:

• Index, don't duplicate. Incident response, business continuity and supplier management procedures each carry their own communication detail. The matrix points to them rather than copying them.
• Wire people rows to HR moments. Joiners receive policy packs, training enrolment and sign-offs. Leavers receive a confidentiality reminder at exit.
• Draft it alongside the incident management procedure. Those procedures supply most of the rows, so the matrix grows out of work you are already doing.

Refresh the matrix after every incident, audit and restructure. A page tied to those events stays in step with the org chart, which is where most plans drift: written once, then never checked against who now holds each role.

Who is allowed to speak for you during an incident?

Only named spokespeople with documented authority should speak to clients, regulators, the police or the media. A simple RACI authority table lists who may communicate internally and externally, and who sends each message type. Writing it down before an incident prevents conflicting statements and unauthorised disclosures when pressure is highest.

For each external audience, the table assigns four roles:

• Responsible: the named person who sends the message.
• Accountable: the executive who approves it, such as the managing director or CISO.
• Consulted: the legal adviser or data protection lead who checks the wording.
• Informed: the board and any team that will field follow-up calls.

Name a deputy for every spokesperson. Incidents do not wait for holidays, and a table with one name per role fails the first time that person is unreachable.

If no one is named to speak, the spokesperson is whoever answers the phone first.

Everyone else needs a single instruction: route client, press and police queries to the named spokesperson and say nothing further. The table takes an afternoon to write, and it spares you a conflicting statement to a client and a regulator on the same day.

Pair it with a few pre-approved holding statements: one for staff, one for affected clients and one for press enquiries. NCSC guidance recommends drafting these templates in advance and training spokespeople in crisis communication, so the first message goes out quickly instead of after a drafting debate.

How do the UK GDPR 72-hour ICO rule and client contract windows fit the matrix?

A reportable personal data breach must reach the ICO within 72 hours of the organisation becoming aware of it, under the UK GDPR. Client contracts add their own notification windows. Both belong in the matrix as external rows: the regulator clock written down once, each client's contractual deadline lifted out of its contract.

UK GDPR Article 33 on breach notification sets the timing: without undue delay and, where feasible, within 72 hours of becoming aware. Not every breach is reportable. The ICO guide to personal data breach notification says to report when a risk to people's rights and freedoms is likely, and to document your reasoning when you decide not to. The row should therefore name who makes that call and where the decision is recorded.

Each external row records the same four facts:

• Clock start: the moment the organisation becomes aware of the breach.
• Deadline: 72 hours for the ICO, or the contractual figure for the client.
• Sender and deputy: taken from the authority table.
• Recipient and route: the regulator's reporting route, or the client's named security contact.

Lifting client windows takes an afternoon with the contract folder. Pull the notification clause from each enterprise contract, record the deadline and the named contact, and sort the matrix by shortest window. Copy each figure exactly as the contract states it, including whether the clock runs in hours or business days. Add a row for the police, noting when you would involve them, and rows for any sector supervisor you answer to.

Vague external rows are where improvisation costs most. A row reading "notify client as required" hands the incident lead a contract search at the worst moment, with the clock already running.

Which ISO 27001 communication channels still work when your systems are down?

Keep an out-of-band copy of the communication matrix and contact tree, either printed or held in a separate cloud tenant. NCSC guidance warns that your usual channels may be unavailable during a cyber incident, so agree the fallback routes and who uses them before anything goes wrong.

The NCSC guidance on effective cyber incident communications names phone lines, messaging apps and social media as alternative ways to keep in touch with staff, stakeholders and customers. Decide which you would use, and who holds the logins, before an incident rather than during one.

A contact tree that lives on the system that is down is a list, not a plan.

Ransomware makes the point sharply. The intranet page, shared drive and mailbox that hold the contact tree can be encrypted along with everything else. The incident lead is then calling people from memory. Three arrangements prevent that:

• Printed copy: held by the incident lead and the deputy, with mobile numbers rather than email addresses alone.
• Separate cloud tenant: a copy under a different account and login from your primary environment.
• Annual drill: ask the incident lead to reach five named people without the intranet, and log how long it takes.

In a multi-site scope, one maintained copy should serve every office, remote team and cloud hosting environment. Keep a single source and publish it to each out-of-band location on a schedule, so an auditor visiting any site is shown the same version. Include escalation contacts for your cloud hosting providers. Treat each ISO 27001 communication provider you depend on, from email platform to chat tool, as a failure point. Record what you would use if it went down.

How do you prove a message was understood, not just sent?

Use closed-loop signals: tracked acknowledgements, short comprehension checks, phishing-simulation trends and drill response times. A broadcast email proves only that something was sent. Feed those signals into Awareness (Clause 7.3) activity and Management Review (Clause 9.3), where the effectiveness of your communication arrangements is examined.

Each signal proves something different:

• Tracked acknowledgements show who accepted a policy and when.
• Comprehension checks, such as a three-question quiz, show whether the content landed.
• Phishing-simulation trends show whether behaviour changes over months.
• Drill response times show whether the contact tree works under pressure.

Your communication KPIs are already in that list. Staff-facing messaging overlaps with Awareness under Clause 7.3, so the same signals serve both clauses. Bounce rates, drill outcomes and notification misses then go to management review as standing agenda items, with minutes recording what changed as a result.

A policy update nobody read is an obligation nobody follows.

A low quiz score on one policy is a prompt to rewrite the policy, not to chase staff. Retire the broadcast email as your only evidence: "we emailed everyone" is a claim, while a signed acknowledgement is a record.

What evidence and audit questions come with ISO 27001 Clause 7.4?

Auditors want timestamped proof of real sends, an authority table, HR lifecycle records and, where they exist, actual regulator or client notifications. Expect questions on Friday-evening breaches, last policy change, spokespeople and contact-tree access. Under certification-body practice, missing arrangements grade major; stale contact lists or undefined external rows grade minor, adding up to a major as a pattern.

The artefacts that carry weight at this scale:

• The matrix itself, or communication sections inside the incident, continuity and supplier procedures, provided together they answer subject, timing, audience and channel.
• An authority table, where a simple RACI does the job.
• Timestamped sends: intranet announcements, distribution logs, read receipts and signed acknowledgements.
• HR lifecycle records: onboarding sign-offs, training completions and exit confidentiality confirmations.
• Real notifications showing a deadline was met. Auditors treat one real example as worth ten templates.
• Effectiveness signals: quiz scores, simulation metrics, drill logs and the management review minutes where they were discussed.

Questions to expect in the room:

• You discover a personal-data breach on Friday evening. Who informs the regulator, by when, and where is that written?
• Show me how the last policy change reached staff, and how you know they read it.
• Who is permitted to talk to clients or the press during an incident?
• Your contact tree lives on the intranet. How do you reach it if the intranet is down?
• Which client contracts carry notification deadlines, and where are they reflected in your plan?

Sampling is concrete. The auditor traces a recent policy update from decision to distribution to acknowledgement, checks one client contract against the matrix, and looks in drill or incident records for proof that the defined pathways were used.

Two pitfalls erode the trail. Evidence kept in personal mailboxes vanishes when someone leaves, and load-bearing conversations held verbally or in ephemeral chat leave nothing to show. Keep sends and decisions in shared, retained systems.

How does GRC engineering automate Clause 7.4?

Treat communication as an engineered system. Policy launches ride the HR or LMS platform so acknowledgements log themselves. Notification deadlines become countdown timers in incident ticketing. The contact tree syncs from the HR system to an out-of-band location, and effectiveness data feeds a dashboard that management review reads directly.

Acknowledgements are the cleanest win, because the audit trail assembles itself as people sign. Deadlines need one design choice: start the countdown when the ticket records awareness of a breach, not when the ticket opens, because awareness is when the ICO clock starts.

The contact tree becomes data rather than a document, current after every joiner and leaver because the HR system is its source. Have the sync job alert someone when it fails, or the out-of-band copy quietly goes stale. For the dashboard, export a dated snapshot for each management review: a live view shows today's figures, not the history an auditor samples.

Defining the matrix, authority table and notification rules is governance, which our fractional CISO engagement establishes. Our GRC engineering service builds the automated layer on top. At audit, the sampling described above becomes a query rather than a scramble.

Frequently asked questions