Establishing the service management policy

To meet ISO/IEC 20000-1:2018 Clause 5.2.1, top management must formally establish a service management policy that fits your organization’s purpose, sets the framework for service management objectives, commits to meeting applicable requirements, and commits to continual improvement of the service management system 1. Operationalize it by drafting, approving, communicating, and governing a policy that drives measurable objectives and routine review.

Key takeaways:

  • The policy is a top-management-controlled document that must explicitly commit to applicable requirements and continual improvement.
  • Your policy must be “usable”: it should drive objectives, ownership, communication, and review cadence, not sit as generic prose.
  • Auditors will test traceability from policy → objectives → operational controls and evidence, plus proof of management approval and communication.

“Establishing the service management policy” is the first real test of whether your service management system (SMS) is directed by leadership or assembled bottom-up. Clause 5.2.1 requires a policy that is appropriate to your organization’s purpose, provides a framework for service management objectives, and includes commitments to satisfy applicable requirements and continually improve the SMS 1.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a governance control with clear inputs and outputs: a policy statement approved by top management, mapped to the scope of services, translated into objectives, and maintained through a lightweight but disciplined review process. The policy is not your procedures. It is the “north star” that sets expectations and the boundaries your procedures must meet.

This page shows how to write the policy so it passes an ISO audit and works operationally: what the requirement means in plain English, who must approve it, how to connect it to objectives and control evidence, what artifacts to retain, and where teams commonly fail.

Regulatory text

Requirement (Clause 5.2.1): “Top management shall establish a service management policy that is appropriate to the purpose of the organization, provides a framework for setting service management objectives, includes a commitment to satisfy applicable requirements, and includes a commitment to continual improvement of the service management system.” 1

What the operator must do:
You need a documented service management policy that:

  1. Fits your organization’s purpose (it reads like it was written for your service context, not copied from a template).
  2. Provides a framework for objectives (you can derive measurable service management objectives from it).
  3. Commits to satisfying applicable requirements (explicit statement; you can show how you identify and meet requirements).
  4. Commits to continual improvement of the SMS (explicit statement; you can show a mechanism that drives improvement over time).
    All of this must be established by top management, meaning leadership approves and owns the policy, not just “reviews” it.

Plain-English interpretation

This clause asks a simple question: What has leadership decided “good service management” means here, and how do they keep the organization accountable to it?

A compliant policy does three jobs:

  • Direction: It tells the organization what to optimize for (for example, reliable services, controlled change, clear accountability).
  • Accountability: It commits the organization to meet requirements that apply to the services and the SMS (regulatory, contractual, internal).
  • Improvement: It makes improvement a managed expectation, not an ad hoc activity.

If the policy cannot be traced to objectives (and then to operational evidence), auditors will treat it as shelfware even if it is signed.

Who it applies to (entity and operational context)

This applies to any organization acting as a service provider, internal or external, that is implementing or certifying to ISO/IEC 20000-1. Typical contexts:

  • IT service organizations running production services for internal business units.
  • Managed service providers delivering services to customers.
  • Shared services teams (cloud platform, workplace IT, network operations).
  • Hybrid organizations where some components are delivered by third parties under your SMS scope.

It applies across the SMS scope: whatever services, locations, teams, and interfaces you included in your service management system boundaries must be governed by this policy.

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

Step 1: Confirm SMS scope and “purpose” statement (inputs)

Before drafting, capture two inputs that keep the policy “appropriate to purpose”:

  • SMS scope statement: which services and service components are covered.
  • Organization purpose in service terms: one paragraph that explains what services exist to do (for example, “operate and improve customer-facing applications supporting revenue operations” or “deliver secure and reliable internal collaboration services”).

Practical tip: If your organization already has a corporate mission statement, translate it into service outcomes (availability, customer experience, risk control). Don’t paste the mission statement into the policy.

Step 2: Draft a policy that contains the four required elements

Use a short structure that auditors can read in minutes. Recommended sections:

  1. Policy statement and intent

    • Who the policy applies to (scope-aligned).
    • What “service management” covers in your context (end-to-end service lifecycle, customer and internal users).
  2. Framework for objectives
    Write policy commitments that can become objectives. Examples of “objective-ready” commitments:

    • Define and maintain a service catalog and service level targets.
    • Control changes to reduce service risk.
    • Restore service promptly when incidents occur.
    • Maintain capacity and continuity expectations appropriate to critical services. Avoid vague commitments like “provide excellent service.”
  3. Commitment to satisfy applicable requirements
    Include a clear line such as: “We commit to satisfy applicable requirements related to our services and the service management system,” then define what “applicable requirements” includes in your organization (contracts, customer requirements, internal policies, and any external obligations relevant to your services). This directly addresses the clause text 1.

  4. Commitment to continual improvement
    State that you will continually improve the SMS, and name the mechanism at a high level (for example, “through measurable objectives, management review, audits, corrective actions, and improvement tracking”). Keep it high-level; procedures live elsewhere.

Step 3: Assign ownership and approval (top management control)

Operationalize “top management shall establish” by documenting:

  • Policy owner: usually the head of service management, CIO/CTO, or equivalent accountable executive.
  • Approver(s): top management role(s) with authority over the SMS scope.
  • Effective date and version control: to show governance and continuity.

If you expect turnover, make the approval role-based, not person-based.

Step 4: Translate the policy into service management objectives

The requirement says the policy must provide a framework for setting objectives 1. Make that real by creating:

  • An objectives register with each objective mapped to a policy commitment.
  • Owner, measurement method, data source, and review forum for each objective.

Keep objectives balanced: include customer outcomes (service levels), operational performance (incident response), risk/compliance (change control), and improvement (problem trends, corrective actions).

Step 5: Communicate the policy and make it findable

Even though Clause 5.2.1 does not list communication mechanics, auditors will still test whether the policy is actually established and functional. Implement:

  • Publication in a controlled repository (GRC tool, QMS/SMS portal, document control system).
  • Targeted communication to in-scope teams (service desk, ops, engineering, service owners).
  • Onboarding/training reference: a “where to find it” and “what it means for your role” note.

Step 6: Establish a review and update routine

Continual improvement is part of the policy content, but you also need the policy itself to stay current. Define:

  • Review triggers: major scope changes, new services, major incident learnings, contract/regulatory changes.
  • Periodic review via management review meetings and internal audits, aligning to your SMS governance approach 1.

If you use Daydream to manage controls and evidence, treat the policy as a governed control with mapped objectives, owners, review tasks, and evidence collection reminders. The goal is fewer gaps during audit sampling.

Required evidence and artifacts to retain

Auditors typically sample both document control and operational traceability. Retain:

Policy artifacts

  • Service management policy (current approved version).
  • Version history / change log.
  • Approval record showing top management approval (meeting minutes, e-signature, or formal approval workflow).
  • Scope statement and policy-to-scope alignment note (can be a short mapping).

Objective and traceability artifacts

  • Objectives register mapped to policy commitments.
  • Evidence of objective review in governance forums (agenda/minutes excerpts, dashboards).
  • Mapping of “applicable requirements” to how you meet them (a requirements register, contract obligations list, or compliance obligations inventory, as appropriate to your context).

Communication artifacts

  • Publication record (intranet page, document repository access log, or announcement).
  • Training/onboarding materials referencing the policy for in-scope roles.

Common exam/audit questions and hangups

Expect questions like:

  • “Show me the service management policy and who approved it.”
  • “How is this policy appropriate to your purpose? Where is that reflected?”
  • “Point to the policy language that commits to applicable requirements and continual improvement.”
  • “Show how the policy provides a framework for objectives. Which objectives were derived from it?”
  • “How do teams know this policy exists and applies to them?”
  • “What changed since last version, and why?”

Hangups that trigger findings:

  • Policy exists but is not approved by top management.
  • Commitments are generic and cannot be tied to objectives or operational controls.
  • “Applicable requirements” is asserted but there is no method to identify what those requirements are for the SMS scope.

Frequent implementation mistakes and how to avoid them

Mistake Why it fails How to fix it fast
Copy/paste policy with generic IT language Not “appropriate to purpose”; auditors see it immediately Add scope-specific services, customers, and operating model references
No objective linkage Violates “framework for setting objectives” expectation Create a simple mapping table: policy commitment → objective(s) → owner
“Applicable requirements” not defined Commitment is empty without a mechanism Maintain a requirements register tied to contracts and obligations relevant to services
Policy owned by GRC only “Top management shall establish” becomes questionable Keep GRC as facilitator; make executive accountable and visible
Policy published but not operational Teams cannot explain it Add role-based bullets: “If you are a service owner / engineer / service desk, you must…”

Enforcement context and risk implications

No public enforcement cases were provided for this ISO clause. Practically, the “risk” is certification and operational governance risk:

  • A weak policy often correlates with weak objective-setting and inconsistent service governance, which increases incident recurrence, uncontrolled change, and customer dissatisfaction.
  • During an ISO audit, failures here can cascade: if the policy is not usable, objective-setting, management review, and continual improvement evidence often fails sampling.

Practical 30/60/90-day execution plan

First 30 days: Establish and approve

  • Confirm SMS scope and write a one-paragraph “service purpose” statement.
  • Draft the policy with the four required elements (purpose fit, objectives framework, applicable requirements commitment, continual improvement commitment) 1.
  • Route for top management approval using your document control method.
  • Publish the approved policy in a controlled location.

By 60 days: Make it operational

  • Build an objectives register mapped to each policy commitment.
  • Assign owners and define measurement sources for each objective.
  • Create a lightweight “applicable requirements” capture method for the SMS scope (contracts, customer requirements, internal obligations).
  • Communicate the policy to in-scope teams; add onboarding references.

By 90 days: Prove it works

  • Run an objective review in an operational governance forum; retain minutes and dashboards as evidence.
  • Test audit readiness: sample a team member and ask them where the policy is and how it affects their work.
  • Review for scope changes or lessons learned and update the policy if required; record version changes and approvals.

Frequently Asked Questions

Who counts as “top management” for approving the service management policy?

Use the role(s) with authority over the SMS scope and resources, such as the CIO/CTO or equivalent executive. What matters is that approval is clearly attributable to leadership, not only to the service management team 1.

Can we combine the service management policy with other policies (quality, security, IT)?

You can, as long as the resulting document still clearly meets the Clause 5.2.1 elements and is clearly applicable to the SMS scope. Auditors should be able to point to the required commitments without interpretation 1.

What does “applicable requirements” mean in practice?

Treat it as the set of obligations that apply to your services and SMS scope, including contract commitments, customer requirements, and internal governance requirements you have adopted. Document how you identify them and where they are tracked so the commitment is testable.

How detailed should the policy be versus procedures?

Keep the policy brief and directive: commitments, scope, and governance expectations. Put “how-to” steps in processes and procedures; auditors want the policy to set direction and the procedures to implement it 1.

What evidence is strongest that the policy is “established”?

A controlled document with versioning, top management approval records, and proof it is communicated and used to set objectives. The objective mapping is often the clearest demonstration that the policy drives the SMS.

We outsource major service components to third parties. Does the policy need to mention that?

The policy should remain scope-aligned. If third parties materially affect service delivery, ensure the policy commitments and objectives cover governing third-party contributions (for example, meeting service levels and requirements), and maintain evidence that your SMS controls extend to those dependencies.

Footnotes

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

Frequently Asked Questions

Who counts as “top management” for approving the service management policy?

Use the role(s) with authority over the SMS scope and resources, such as the CIO/CTO or equivalent executive. What matters is that approval is clearly attributable to leadership, not only to the service management team (Source: ISO/IEC 20000-1:2018 Information technology — Service management).

Can we combine the service management policy with other policies (quality, security, IT)?

You can, as long as the resulting document still clearly meets the Clause 5.2.1 elements and is clearly applicable to the SMS scope. Auditors should be able to point to the required commitments without interpretation (Source: ISO/IEC 20000-1:2018 Information technology — Service management).

What does “applicable requirements” mean in practice?

Treat it as the set of obligations that apply to your services and SMS scope, including contract commitments, customer requirements, and internal governance requirements you have adopted. Document how you identify them and where they are tracked so the commitment is testable.

How detailed should the policy be versus procedures?

Keep the policy brief and directive: commitments, scope, and governance expectations. Put “how-to” steps in processes and procedures; auditors want the policy to set direction and the procedures to implement it (Source: ISO/IEC 20000-1:2018 Information technology — Service management).

What evidence is strongest that the policy is “established”?

A controlled document with versioning, top management approval records, and proof it is communicated and used to set objectives. The objective mapping is often the clearest demonstration that the policy drives the SMS.

We outsource major service components to third parties. Does the policy need to mention that?

The policy should remain scope-aligned. If third parties materially affect service delivery, ensure the policy commitments and objectives cover governing third-party contributions (for example, meeting service levels and requirements), and maintain evidence that your SMS controls extend to those dependencies.

Authoritative Sources

Operationalize this requirement

Map requirement text to controls, owners, evidence, and review workflows inside Daydream.

See Daydream
ISO/IEC 20000-1: Establishing the service management policy | Daydream