ISO 27001 Communication Planning: Who Needs What, When and Why

Information-security communication fails in two opposite ways. Some organisations broadcast generic reminders that nobody can act on. Others communicate only during a crisis, when audiences, approvals and channels have not been agreed. ISO/IEC 27001 clause 7.4 requires the organisation to determine communications relevant to the ISMS, including what, when, with whom and how to communicate.

The standard does not require one named communication-plan document. The organisation needs a controlled, workable arrangement that supports its context, risks and obligations. This guide shows how to design that arrangement and prove it operates.

Direct answer: An ISO 27001 communication arrangement should identify the message or decision, trigger, audience, owner, approver, channel, sensitivity, delivery evidence and required follow-up. The strongest evidence connects a planned rule to a real message and the action it caused.

Start with the decision or behaviour

Before choosing a channel, state what the communication must achieve. Examples include:

• obtain management approval for risk treatment;
• tell personnel how to report a suspected incident;
• notify a customer under a contractual requirement;
• instruct administrators about an urgent control change;
• inform suppliers of new security obligations;
• report performance and exceptions to leadership; or
• communicate the scope and responsibilities of the ISMS.

“Raise awareness” is rarely enough. Define the intended decision, action or understanding. That makes it possible to select the audience, owner, timing and evidence.

The business-language guide provides a method for translating formal terms into decisions, actions and evidence without changing their meaning.

Build a communication register

A concise register can organise recurring and event-driven communications. Useful fields include:

Field	Purpose
Subject and objective	What must be understood or decided
Trigger or frequency	When communication occurs
Audience	Who needs the message
Owner	Who prepares and is accountable for it
Approver	Who confirms accuracy and authority
Channel	How it is delivered
Sensitivity	Handling and access restrictions
Required content	Facts, instructions and caveats
Evidence	What proves delivery and outcome
Escalation	What happens if delivery fails

Do not populate the register with every ordinary email. Include communications that materially affect the ISMS, security behaviour, obligations or decisions.

Worked communication-plan example

The following illustrative record shows how a single incident communication can be planned without inventing a universal notification period. The actual timing and recipients must come from the organisation’s applicable law, contract and response criteria.

Field	Worked example
Objective	Enable the customer incident lead to decide whether service-continuity and contractual notification actions are required
Trigger	Incident commander classifies a confirmed production confidentiality event affecting the customer’s service
Audience	Named customer security contact, internal service owner, privacy lead and legal adviser
Owner and approver	Incident communications lead prepares; incident commander and legal/privacy role approve facts within their authority
Required content	Confirmed scope, known impact, containment status, unresolved questions, customer action if any and next-update time
Channel and fallback	Approved customer portal; verified phone contact if the portal or corporate identity is unavailable
Handling	Customer-confidential; distribution limited to the authorised case team
Delivery evidence	Approved message version, time sent, recipient record and portal delivery event
Outcome evidence	Customer acknowledgement, recorded decision and any agreed follow-up action

During testing, trace the source facts into the approved message. Then confirm that the recipient list was current, the fallback contact was usable and the promised next update occurred. This separates evidence of sending from evidence that the communication achieved its purpose.

The ISO 27001 clause explainer can help relate the communication process to wider clauses without making the register clause-driven.

Segment audiences by their decisions

Different audiences need different depth and language.

Top management

Leaders need material risk, obligations, control performance, unresolved decisions, resource constraints and improvement priorities. Provide options and consequences, not raw technical alerts.

Risk and control owners

Owners need affected services, criteria, current evidence, exceptions, due dates and authority required. Their message should enable a treatment or operational decision.

Personnel and contractors

Users need clear expected behaviour, observable triggers and reporting routes. Avoid copying policy language without explaining the action. Test comprehension where the consequence matters.

Customers and interested parties

External messages must match contracts, law, certificate scope and approved claims. Coordinate security, legal, privacy, commercial and communications roles where necessary.

Auditors and certification bodies

Provide controlled, relevant evidence while protecting sensitive data and investigation material. Define who coordinates requests and how source records remain traceable.

One message rarely serves all audiences. Reuse verified facts, but adapt detail, timing and action to the recipient.

Separate routine and event-driven communication

Routine communication follows a planned cadence: objectives, performance, policy changes, risk status, audit outcomes, supplier assurance, awareness and management review.

Event-driven communication begins when a threshold is met: incident severity, legal deadline, control failure, overdue risk decision, material supplier change, certificate change or urgent vulnerability. These messages need defined triggers and alternates because they occur under time pressure.

For event-driven cases, specify who can activate the communication path and who can approve content. Include out-of-hours coverage and alternate channels if normal systems may be unavailable.

The incident-management guide explains how communication decisions fit into the incident timeline and evidence record.

Control accuracy, confidentiality and timing

Fast communication can still cause harm if facts are unverified, recipients are wrong or sensitive details spread. Define a minimum approval path that reflects urgency.

Use status labels such as confirmed, suspected and unknown. Time-stamp material facts. State when the next update will occur. Restrict technical indicators, personal data, legal advice and attacker communications to appropriate recipients.

For urgent operational instructions, preserve what was approved and sent. Where a verbal direction is necessary, create a reliable retrospective record. Do not allow the need for documentation to delay immediate protective action, but do not let the decision disappear afterwards.

Choose resilient channels

Match the channel to urgency, audience, sensitivity and expected availability. Options may include service-management systems, collaboration platforms, email, phone trees, emergency notification services, customer portals and approved public channels.

Consider failure modes. A ransomware event may make corporate email or identity unavailable. A cloud outage may affect the communication tool and the service simultaneously. Maintain protected contact information and alternate methods proportionate to risk.

Test access, distribution groups and role coverage. A plan that names a departed approver or an inaccessible channel is design without operation.

Connect obligations to the message path

Legal, regulatory and contractual duties may define recipients, content, timing or evidence. Maintain traceability from the obligation to:

• the triggering condition;
• decision owner;
• competent reviewer;
• approved message route;
• delivery evidence; and
• correction or follow-up.

There is no universal notification deadline for every event. Avoid hard-coding a period unless it is supported by the applicable obligation and facts. Legal and privacy owners should make decisions within their competence.

Design evidence before sending

Delivery evidence varies by channel. It may include an approved bulletin, recipient list, system log, meeting record, acknowledgement, training result, customer notice or management decision. Protect records according to sensitivity and retention needs.

Evidence should answer three questions:

1. Was the right information approved and sent?
2. Did it reach the intended audience at the required time?
3. Did the recipient make the decision or take the action expected?

Read receipts alone rarely prove understanding. For critical operational messages, use confirmation, exercise, interview or system behaviour to evaluate outcome.

Measure communication effectiveness

Possible measures include high-severity escalations delivered within defined targets, failed contact attempts, outdated recipients, required acknowledgements received, incident updates issued as planned, overdue management decisions and exercises that reached alternate contacts.

Interpret metrics carefully. A high acknowledgement rate may still hide poor understanding. A rise in incident reporting may reflect improved awareness, not deteriorating behaviour.

Use results in management review when they reveal material performance, resource or improvement decisions.

Audit the process through real messages

Select both planned and triggered samples:

• a policy or control change;
• a management risk escalation;
• an incident notification decision;
• a supplier communication;
• an external assurance claim; and
• an out-of-hours exercise.

For each sample, trace trigger, source facts, owner, approval, audience, channel, delivery and outcome. Compare the communication register with actual systems and interview recipients. Test whether alternates remain current.

Pass, partial and fail examples

Pass: Material communications had clear objectives, audiences, approvals and triggers. Recent samples were accurate, timely and evidenced, and exercises confirmed alternate channels.

Partial: Routine reports were reliable, but incident recipients and out-of-hours approvals were outdated and outcome evidence was limited to delivery logs.

Fail: Communication depended on individual judgement, sensitive messages used uncontrolled channels, and the organisation could not show who approved or received them.

Common design errors

Avoid:

• listing channels without defining the message objective;
• sending the same technical detail to every audience;
• treating awareness campaigns as the whole process;
• omitting suppliers, customers or regulators from relevant paths;
• relying on systems likely to fail during the event;
• publishing certification or compliance claims beyond supported scope;
• measuring delivery without evaluating action; and
• retaining sensitive recipient or incident data without controls.

Practical conclusion

ISO 27001 communication planning is a governance process for getting accurate information to the right decision-maker or actor at the right time. Start with the required outcome, then define audience, trigger, owner, approval, channel, sensitivity and evidence.

A short, maintained register linked to real workflows is stronger than a long document nobody uses. The audit trail should show not only that a message was sent, but that it enabled the intended decision or behaviour.

This article was cross-checked against the official ISO/IEC 27001 overview. The register structure, evidence model and audit sampling approach are original AuditPrepared guidance.