Communicating the service management policy

To meet ISO/IEC 20000-1:2018 Clause 5.2.2, you must keep the service management policy as controlled documented information, communicate it across the organization, make it available to interested parties where appropriate, and review it to confirm it remains suitable. Operationalize this by defining audiences, channels, ownership, review triggers, and evidence of receipt and publication. ¹

Key takeaways:

• You need both a policy document and proof it was communicated and made available to the right people. ¹
• “Interested parties” includes internal and external stakeholders; decide access by role and need, then document the rationale. ¹
• A review mechanism must exist and be provable (versioning, review records, and trigger-based updates). ¹

“Communicating the service management policy” sounds simple until an auditor asks two questions: (1) how do you know people actually received and understood it, and (2) how do you decide which third parties or customers get access, and which don’t. ISO/IEC 20000-1:2018 Clause 5.2.2 is a requirement about governance and operational control: your service management policy can’t be a forgotten PDF in a shared drive. It must be controlled documented information, actively communicated internally, available to interested parties as appropriate, and reviewed for continuing suitability. ¹

This page translates that into an execution-ready approach a Compliance Officer, CCO, or GRC lead can run. You’ll get (a) a plain-English interpretation, (b) applicability guidance, (c) step-by-step actions that map to typical service management operations (service desk, change, incident, supplier management), (d) the evidence package auditors expect, and (e) common failure modes that derail ISO/IEC 20000 audits. The goal is quick operationalization: clear ownership, clear communication pathways, and clean artifacts that stand up under scrutiny.

Regulatory text

Requirement (verbatim): “The service management policy shall be available as documented information, communicated within the organization, available to interested parties as appropriate, and reviewed for continuing suitability.” ¹

What an operator must do

You must implement four things and be able to prove each one:

1. Available as documented information: Maintain the policy in a controlled form (versioning, approvals, and access control consistent with your document control approach). ¹
2. Communicated within the organization: Ensure relevant internal roles know it exists, can access it, and understand what it requires from them (not just “it’s posted somewhere”). ¹
3. Available to interested parties as appropriate: Decide which stakeholders outside the immediate service management team need the policy (customers, regulators, auditors, key third parties), then make it accessible in a governed way. ¹
4. Reviewed for continuing suitability: Establish a review and update mechanism, with records that show when it was reviewed and what changed or why it didn’t. ¹

Plain-English interpretation (what this requirement is really testing)

Auditors use Clause 5.2.2 to test whether your service management policy is a living control that drives behavior. The “policy” is the top-level statement of intent and direction for the Service Management System (SMS). Communication proves adoption. Availability to interested parties proves transparency and appropriate stakeholder engagement. Review proves the SMS adapts when services, risks, tooling, or organization changes. ¹

A practical reading: if a service desk manager or change manager can’t quickly find the current policy, explain what it means for their process, and show how it gets updated, you will struggle in an ISO/IEC 20000 assessment.

Who it applies to (entity and operational context)

This applies to any organization or service provider operating an SMS aligned to ISO/IEC 20000-1, including internal IT organizations and external managed service providers. ¹

Operationally, it touches:

• Service management leadership (SMS owner, Head of ITSM, Service Delivery)
• Process owners (incident, service request, problem, change, release, configuration, service level, continuity/availability, capacity, information security as it relates to services)
• Governance functions (Compliance, Risk, Internal Audit, Quality)
• Human resources / training (policy awareness)
• Third-party management where third parties deliver or support services that fall under your SMS scope

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

Step 1: Lock down the “documented information” mechanics

• Create or confirm a single system of record for controlled policies (QMS tool, GRC system, document management platform).
• Apply minimum document controls: owner, approver, effective date, version, change history, classification/handling, and access permissions.
• Ensure the policy is readable and scoped: it should state scope boundaries (which services/teams it covers) and the governance expectations (compliance with SMS processes, continual improvement, meeting service requirements).
  Evidence you want: the policy file with metadata and version history. ¹

Step 2: Define internal communication requirements by audience

Build a small communication matrix. Keep it operational:

Audience	What they need	Channel	Proof to keep
Service management roles (process owners, service desk, SRE/ops)	The policy + “what this means for your process” summary	Team briefing + intranet post + onboarding	attendance record, link, onboarding checklist
Senior management	The policy + accountability expectations	Steering committee deck + approval workflow	meeting minutes, approvals
Broader IT / impacted business functions	Where to find it + key commitments	intranet announcement + manager cascade	announcement, manager attestation

Your standard should be: “a reasonable person can find the current policy quickly and knows it applies to them.” ¹

Step 3: Execute internal communication and capture evidence of reach

Do not treat “communicated” as “posted.” Implement at least one push mechanism and one pull mechanism:

• Push: onboarding module, all-hands slide, targeted email to service owners, or team talk track.
• Pull: intranet policy library, service management handbook, knowledge base article.

Evidence options (pick ones your culture will sustain):

• Learning system completion for relevant roles
• Meeting minutes with policy review as an agenda item
• Attestation workflow (manager or individual)
• Change log entries that show policy updates were announced ¹

Step 4: Identify “interested parties” and decide what “as appropriate” means

This clause gives you discretion, but auditors will expect a reasoned approach. Create an “interested parties” register entry (even a small table) tied to your SMS scope, such as:

• Customers receiving in-scope services
• Critical third parties supporting in-scope services (outsourcers, cloud providers, support partners)
• External auditors or certification bodies
• Regulators (where relevant to your organization)

Then decide:

• What version they can see (full policy, redacted policy, summary statement)
• How they access it (public web page, customer portal, contract exhibit, NDA-protected share)
• Who approves external sharing (Compliance, Legal, SMS owner)

Keep the decision consistent with confidentiality and contractual commitments, but document the rationale. ¹

Step 5: Make the policy available externally (only where it’s appropriate)

Common operational patterns:

• Customer-ready excerpt in a customer trust portal or as part of onboarding packs.
• Contractual availability: referenced in MSAs/SOWs with a link to the current controlled version.
• Third-party coordination: share the policy (or summary) with third parties who must align their operational practices to your SMS processes.

Evidence: portal screenshot, shared link with access logs, contract language referencing the policy location, or a controlled distribution list. ¹

Step 6: Implement a “continuing suitability” review mechanism

A review mechanism must exist even when the policy doesn’t change. Use:

• Periodic review cadence you can sustain (record the review).
• Trigger-based review when major changes occur (re-org, new service model, major incident learnings, tooling replacement, significant third-party change, scope changes).

Evidence: review record, change request/ticket, approval workflow, updated version history. ¹

Step 7: Operationalize with a control owner and workflow in your GRC system

Assign a single accountable owner (SMS manager or ITSM governance lead) and define:

• Review tasks
• Distribution tasks
• Evidence collection tasks
• Exceptions process (who can deviate and how it is approved)

If you run a third-party risk program in Daydream, treat “service management policy communication” as a control with mapped evidence, tasking, and reminders so you can produce audit-ready artifacts without scrambling.

Required evidence and artifacts to retain

Auditors typically want to see proof across the four verbs: documented, communicated, available, reviewed. Keep:

• Controlled service management policy (current + prior versions)
• Approval record (who approved, when)
• Publication record (where it lives, access controls)
• Internal communication artifacts (announcement, training/attestation, meeting minutes)
• Interested parties determination (register or memo: who, what access, rationale)
• External availability proof (customer portal screenshot, contract reference, secure share record)
• Review records (periodic review sign-off, trigger-based review tickets)
• Exception documentation (if you restrict access or delay publication, capture approval and compensating controls) ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me the current service management policy and explain how you control versions.” ¹
• “How do new hires in service management roles learn about this policy?”
• “How do you know the policy was communicated beyond the ITSM governance team?”
• “Who are your interested parties, and why is your policy available (or not) to them?”
• “When was the policy last reviewed, and what drove the decision to change or not change it?” ¹

Hangup to anticipate: teams can often produce a policy but cannot show distribution evidence, or they share externally without documenting why it was appropriate.

Frequent implementation mistakes (and how to avoid them)

1. Posting equals communicating.
   Fix: require at least one push channel plus a retained record (attestation, minutes, training completion). ¹

2. No defined “interested parties” logic.
   Fix: maintain a simple register and decision rule (role/need/contract). Document when you choose not to share. ¹

3. Policy is too abstract to drive operations.
   Fix: add a short “What this means for you” section, linking to core SMS processes and responsibilities.

4. Reviews happen informally.
   Fix: create a repeatable review workflow with sign-off, even if outcome is “no change.” ¹

5. Multiple conflicting copies.
   Fix: publish one canonical link and retire old storage locations; block editing outside controlled workflow.

Enforcement context and risk implications

No public enforcement cases are provided for this requirement in the supplied sources. Practically, the risk is audit nonconformity and operational drift: teams follow tribal knowledge, third parties operate to different expectations, and management cannot prove the SMS is governed. Clause 5.2.2 is an early test of whether your SMS governance is real, which can affect confidence in downstream controls (incident, change, continuity) during an ISO/IEC 20000 certification audit. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize the basics)

• Confirm the current service management policy exists, has an owner, and is under document control. ¹
• Establish canonical publication location and remove obvious duplicates.
• Draft your audience-based communication matrix and interested parties list.
• Choose evidence methods you can sustain (attestation vs training vs minutes).

Days 31–60 (prove communication and availability)

• Run an internal communication cycle: management sign-off, process owner briefing, and onboarding integration.
• Capture and store evidence in one place (GRC repository or controlled folder with index).
• Decide external availability approach (portal, contract reference, secure share) and implement it for applicable interested parties. ¹

Days 61–90 (make it durable)

• Implement the continuing suitability review workflow (periodic + trigger-based).
• Test retrieval: ask several roles to find the policy and explain their responsibilities; fix gaps.
• Add a lightweight KPI-style check: “Can we produce the last communication evidence and last review record quickly?” If not, tighten workflow ownership.
• If you use Daydream, configure recurring tasks and evidence requests so policy review and communication records are collected continuously rather than at audit time.

Frequently Asked Questions

Do we have to publish the service management policy publicly?

No. The requirement is “available to interested parties as appropriate,” which allows you to control access based on need, confidentiality, and contractual context. Document who gets access and why. ¹

What counts as “communicated within the organization”?

You need a method that reasonably reaches the roles in scope and leaves evidence. Common approaches include onboarding/training, recorded briefings, or attestations plus a canonical intranet location. ¹

Can we share a summarized or redacted version with customers or third parties?

Yes, if that is what “as appropriate” means in your context. Keep the controlled full policy internally and document the rationale for the external version and its distribution control. ¹

How often do we need to review the policy?

The clause requires review for continuing suitability but does not prescribe a frequency. Set a review approach you can execute consistently and add trigger-based reviews for major operational changes. ¹

What evidence is strongest in an audit: attestation, training completion, or meeting minutes?

The strongest evidence is the one that is repeatable and role-appropriate. Auditors typically accept any of these if it clearly shows the right audience received the policy and you can trace it to a controlled version. ¹

We have multiple service lines. Do we need separate policies?

Not necessarily. You can maintain one policy with clear scope statements and appendices, or separate policies per SMS scope. The key is controlled documented information, clear communication, and provable review for each in-scope SMS. ¹

Footnotes

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