Communication

ISO/IEC 20000-1:2018 Clause 7.4 requires you to define and control the communications that affect your service management system (SMS): what gets communicated, when, to whom, and by what method. To operationalize it, publish an SMS Communication Plan, assign owners, map recurring and event-driven messages, and retain evidence that communications happened and were effective. ¹

Key takeaways:

• Build a single, owned “SMS Communication Plan” that covers internal and external audiences, triggers, channels, and required records.
• Treat communication as a controlled process: approvals, versioning, distribution, and confirmation of receipt where appropriate.
• Evidence wins audits: keep artifacts that show timing, audience, content, and delivery method for key SMS communications.

Clause 7.4 is a deceptively small requirement with outsized audit impact: auditors will look for a clear, intentional approach to how you communicate SMS-relevant information across the organization and to third parties. “Communication requirement” in ISO/IEC 20000-1:2018 is not a generic “be transparent” expectation. It is a requirement to determine the communications relevant to the SMS and to define four attributes for each: content, timing, audience, and method. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat communications like any other controlled SMS element: document it, assign accountability, make it repeatable, and prove it happened. The core deliverable is an SMS Communication Plan (or procedure) that ties into your operational reality: incident communications, change notices, service reporting, supplier/third-party touchpoints, customer notices, internal governance updates, and staff awareness messages.

If you implement this well, you reduce avoidable operational friction: missed escalations, inconsistent customer messaging, unclear ownership during incidents, and audit findings for “process not defined” or “defined but not implemented.”

Regulatory text

Clause 7.4 (Communication): “The organization shall determine the internal and external communications relevant to the service management system, including what it will communicate, when to communicate, with whom to communicate, and how to communicate.” ¹

Operator interpretation (what the auditor expects):

• You have identified the SMS-relevant communications (not every message in the company).
• For each communication, you can show:
  • What is communicated (topic/content and minimum required elements).
  • When it is communicated (recurrence or triggering events, plus timing expectations).
  • With whom you communicate (roles, groups, third parties, customers).
  • How you communicate (channels, tools, templates, and escalation paths).
• You can demonstrate the plan is implemented (not just written) with records and examples.

Plain-English interpretation of the requirement

You need a controlled, repeatable way to communicate service-management information to the right people at the right time, using defined channels. This includes internal communications (leadership, service owners, operations teams, impacted business units) and external communications (customers, regulators if applicable to your context, and third parties such as suppliers and outsourced service providers). ¹

This requirement becomes real during high-risk moments: major incidents, emergency changes, service transitions, SLA misses, security events that affect services, and supplier failures. If you cannot show who gets told what and when, you are depending on tribal knowledge. Auditors tend to treat that as a control weakness because it fails under pressure or staff turnover.

Who it applies to (entity and operational context)

Applies to:

• Any organization operating an ISO/IEC 20000-1 service management system, including internal IT organizations and external service providers. ¹

Where it shows up operationally:

• Service desk and operations: user advisories, outage updates, planned maintenance notices, status page messaging.
• Change and release: change notifications, CAB communications, deployment windows, rollback communications.
• Incident and problem management: escalations, major incident comms, post-incident summaries where required by your SMS.
• Service level management: periodic service reports and SLA performance communications.
• Supplier/third-party management: operational communications with third parties delivering parts of your services (handoffs, escalations, outage coordination).
• SMS governance: management reviews, policy updates, process changes, training/awareness communications tied to the SMS.

What you actually need to do (step-by-step)

1) Define scope: “SMS-relevant communications”

Create a short definition that draws a line around what you will control. Example: “SMS-relevant communications are messages that instruct, inform, or coordinate stakeholders about service delivery, service performance, service changes, service interruptions, service risks, and SMS governance.” Keep this definition aligned to how your SMS is described. ¹

2) Build the SMS Communication Plan (single source of truth)

Create a document (or controlled wiki page) titled SMS Communication Plan. It should include:

• Purpose and scope
• Roles and responsibilities (owner, approvers, backups)
• Communication inventory (table)
• Templates (or links to templates)
• Distribution lists and how they are managed
• Escalation paths for urgent communications
• Recordkeeping expectations (what gets retained, where, and by whom) This satisfies the “determine” requirement only if it is specific and implemented. ¹

3) Inventory communications using a table (make audits easy)

Use a table that covers the four required attributes and adds operational fields you will need.

Suggested table fields (minimum viable + operator-grade):

• Communication name (e.g., “Major Incident Customer Update”)
• Type: internal / external
• Trigger: scheduled or event-driven
• What: required content elements (bullets)
• When: timing expectation (e.g., “on declaration,” “after approval,” “weekly on business day”)
• With whom: audience (roles/groups; named third parties if applicable)
• How: channel(s) (ticketing tool, email, collaboration tool, phone bridge, status page)
• Owner (role)
• Approver (role) if required
• Evidence/record location
• Template/link The table is the practical interpretation of Clause 7.4. ¹

4) Establish control points: approvals, versioning, and access

Decide which communications need formal approval (common examples: customer-impacting notices, contractual SLA reports, and major incident public statements). Then:

• Put templates under document control.
• Control who can publish to high-impact channels (status page, mass email lists).
• Ensure distribution lists have an owner and a change process. Auditors often test whether communications are consistent and controlled, not improvised. ¹

5) Operationalize event-driven communications (where failures happen)

Define “event triggers” and embed them into workflows:

• Major incident declared: auto-create comms tasks in the incident ticket; assign a comms owner.
• Planned maintenance approved: require a customer notice task before implementation.
• Emergency change: define the internal escalation and after-the-fact notification steps. This turns communication from “remember to send an email” into a workflow requirement. ¹

6) Train and validate: do people know the playbook?

Train the people who must execute the plan (service desk leads, incident commanders, change managers, service owners). Then test it:

• Run a tabletop exercise for major incident communications.
• Review a sample of recent changes/incidents to confirm comms occurred and records exist. You are validating both execution and evidence quality. ¹

7) Monitor effectiveness and update the plan

Clause 7.4 does not prescribe metrics, but auditors may ask how you know communications work. Keep it practical:

• Track repeated failures: missed notifications, wrong audience, unclear messaging.
• Update templates and distribution lists after org changes.
• Treat communication failures as process improvements where appropriate within your SMS. ¹

Required evidence and artifacts to retain

Retain evidence that proves the four attributes were defined and that communications occurred as planned:

Core artifacts

• SMS Communication Plan (controlled document with version history) ¹
• Communication inventory table (current state)
• Communication templates (customer notice, incident update, maintenance notice, SLA report cover note)

Execution records (samples are fine if volume is high)

• Major incident comms logs: timestamps, messages sent, audience/channel
• Change records showing notification tasks completed (ticket screenshots/export, change checklist)
• Service reports distributed to stakeholders (report plus distribution evidence)
• Evidence of distribution list ownership and updates (request tickets, approvals)

Governance evidence

• Training/awareness records for SMS communication responsibilities
• Post-incident reviews that include communication effectiveness feedback where applicable

Common exam/audit questions and hangups

Auditors typically probe in these areas:

1. “Show me where you determined SMS-relevant communications.”
   They want the plan/table, not a verbal description. ¹

2. “Pick a recent major incident; show what you communicated, when, to whom, and how.”
   Have one or two clean examples ready with timestamps and channel evidence. ¹

3. “How do you ensure external communications are consistent and approved?”
   They look for templates, approval steps, and controlled channels.

4. “What happens when key staff are out?”
   They look for role-based ownership and backups, not a single named person.

Frequent implementation mistakes and how to avoid them

• Mistake: Writing a policy with no inventory.
  Fix: build the table. Clause 7.4 is easiest to prove with a communication matrix. ¹

• Mistake: Covering only internal communications.
  Fix: include external audiences relevant to your SMS, especially customers and third parties in your delivery chain. ¹

• Mistake: No evidence trail.
  Fix: define “records to retain” per communication type, and store them in consistent locations (ticket, document repository, status page archive).

• Mistake: Uncontrolled distribution lists and ad hoc channels.
  Fix: assign owners to lists/channels and require changes through a request workflow.

• Mistake: Over-scoping.
  Fix: keep it “SMS-relevant.” Trying to control every corporate communication creates noise and noncompliance.

Enforcement context and risk implications

No public enforcement cases were provided for this clause in the source catalog. Practically, the risk is operational and contractual: inconsistent customer communications can worsen incident impact, trigger dispute escalations, and create audit findings for “documented but not implemented” controls. Clause 7.4 is also a dependency: weak communication undermines incident, change, and service level processes even if those processes are well-designed. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Appoint an SMS Communication Plan owner (role-based).
• Draft the plan structure and define “SMS-relevant communications.”
• Build the first-pass communication inventory for the highest-risk flows: major incident updates, planned maintenance notices, emergency change notifications, and service reporting.
• Identify controlled channels and current gaps (who can publish, where records live).

Days 31–60 (Near-term)

• Finalize templates and approval rules for external communications.
• Integrate communication tasks into incident and change workflows (checklists or ticket automation).
• Assign owners for distribution lists and status-page publishing rights.
• Run a tabletop exercise for a major incident communication scenario; capture lessons learned.

Days 61–90 (Operationalize + evidence)

• Start sampling and QA: select recent incidents/changes and confirm communications occurred with retained evidence.
• Tune the inventory: remove low-value items, add missing third-party touchpoints.
• Prepare an audit-ready packet: plan, matrix, templates, and two clean execution examples.
• If you use Daydream to manage third-party governance or service delivery evidence, store communication artifacts alongside the related incident/change/third-party record so audits can trace end-to-end execution without chasing screenshots across tools.

Frequently Asked Questions

Do we need a separate “Communication Policy” for ISO 20000, or is a plan enough?

Clause 7.4 requires you to determine relevant communications and define what/when/with whom/how. A controlled SMS Communication Plan that includes a communication inventory and execution expectations typically satisfies this, if it is implemented and evidenced. ¹

What counts as “external communication” in the SMS context?

External means outside your organization and relevant to service management, commonly customers and third parties supporting service delivery. Include the audiences you actually depend on during changes, incidents, and service reporting. ¹

How detailed does the “when to communicate” field need to be?

Make it actionable: specify the trigger (scheduled vs event-driven) and the expected timing in operational terms (for example, “upon major incident declaration” or “after change approval, before implementation”). The goal is consistent execution, not perfect precision. ¹

Do we need proof that recipients read the message?

Clause 7.4 requires you to determine communications, including method and timing, and to implement them. For high-impact communications, confirmation of receipt can be a practical control, but the baseline expectation is evidence of sending/publishing through controlled channels. ¹

How do we handle third-party communications (suppliers, outsourcers, cloud providers)?

Treat third-party touchpoints as explicit rows in the communication inventory: escalation paths, outage coordination, and change notifications. Store records with the related incident/change and define who owns the relationship and the channel. ¹

What’s the fastest way to get audit-ready evidence for this requirement?

Prepare two strong examples (one incident, one change) that show the full chain: the plan requirement, the executed communication (content + timestamp), the audience/channel, and where records are stored. Auditors accept sampling when it is clearly tied to the SMS Communication Plan. ¹

Footnotes

1. ISO/IEC 20000-1:2018 Information technology — Service management