Skip to content
Audit-Checklist

ITSM · ISO Standards

ISO/IEC 20000-1: ITSM certification without copying ITIL theatre

How to prepare an ISO 20000-1:2018 service management system — service catalog, SLAs, and what auditors sample beyond ticket queues.

6 min read

ISO/IEC 20000-1 is a service management system standard. It certifies the way an organization plans, delivers, controls, reports, and improves services, not the fact that it owns an ITIL tool or has incident tickets.

The checklist helps execute the SMS requirements, but the guide explains the judgment behind them: which services are in scope, what customers were promised, which suppliers support those promises, and whether change, incident, problem, release, and continuity practices match daily work.

In 2026, ITSM is shaped by SaaS, cloud platforms, DevOps delivery, outsourced support, and business-facing service levels. An SMS that exists only inside a ticketing platform cannot explain emergency changes, supplier flow-down, or unmeasurable SLAs. For ISO 20000, the guide should make the service model visible before process evidence is collected. A service has customers, outcomes, components, support teams, suppliers, commitments, risks, and reports. Incidents, changes, problems, and releases only make sense in that context. The common audit weakness is a ticket queue that records activity but cannot show whether the service met its commitments or improved. Emergency changes are a useful stress test because they reveal governance shortcuts, poor release planning, missing rollback criteria, or pressure from customers. Supplier reports are another test: if the supplier does not measure what the service promises, the SMS cannot honestly report end-to-end performance. A useful way to read the rest of this guide is to separate evidence from judgment. Evidence shows that an activity happened: a review, record, test, approval, training, scan, exercise, assessment, or decision. Judgment explains why the activity was scoped that way, why the risk treatment is proportionate, why an exception is acceptable, and what would cause the decision to change. The paired checklist should collect evidence and owners, while the guide should help teams avoid false certainty. For each topic, ask what a knowledgeable reviewer would challenge after seeing the first answer. They may ask whether the scope matches production, whether suppliers are included, whether recurring work is current, whether leadership approved trade-offs, and whether public or customer-facing claims match operations. That second layer is where preparation becomes credible. It also keeps teams from overclaiming, because a documented limitation with a plan is usually stronger than a broad statement no one can support. Keep a dated rationale beside the evidence so reviewers can see what changed, who approved the interpretation, and which operating signal would trigger a fresh review. Keep the reviewer-facing story specific enough that another team can repeat the analysis without guessing.

What ISO 20000-1 actually is

ISO 20000-1 defines requirements for a service management system. It includes planning, service portfolio, relationship and agreement, supply and demand, service design and transition, resolution and fulfillment, assurance, reporting, and continual improvement.

The core artifact is not the tool; it is the service model. The organization needs to define services, customers, service components, responsibilities, service levels, dependencies, suppliers, and interfaces between practices.

ITIL can help with vocabulary and process design, but ISO 20000-1 asks for a coherent management system with scope, policy, objectives, competence, performance evaluation, internal audit, corrective action, and management review.

Decisions the checklist will not make for you

The checklist cannot decide the SMS scope. Leaders must decide which services, customers, locations, suppliers, and support teams are included. A tool-wide scope that covers every queue may be too broad; a narrow scope may omit critical dependencies.

It also cannot define meaningful SLAs. Teams must choose measures customers understand and operations can support. Vague availability, response, or resolution commitments do not drive behavior if no one can measure them consistently.

The checklist cannot decide how emergency changes are governed. A mature SMS needs criteria, approval routes, risk review, testing expectations, retrospective review, and trend monitoring rather than daily exceptions becoming the normal release path.

Where service teams actually fail

The most common failure is using ITIL tooling without defining SMS scope. Ticket categories, workflows, and dashboards exist, but auditors cannot tell which services are certified, who the customers are, or what commitments govern delivery.

Unmeasurable SLAs create another gap. If the agreement says rapid response or high availability without data definitions, exclusions, reporting frequency, or ownership, the SMS cannot evaluate service performance.

Supplier flow-down is often weak. Cloud providers, subcontracted support, network vendors, and specialist teams affect service commitments, yet contracts and reports do not map to the organization's SLAs. The supplier chain must support the service story.

How to use the paired checklist

Use the checklist to define SMS scope before documenting practices. Name services, customers, service levels, suppliers, dependencies, responsible teams, and excluded areas with rationale.

Attach evidence that shows the SMS operating: service catalog records, SLA reports, incident and problem samples, change records, release plans, supplier reviews, continuity tests, complaints, improvement actions, internal audits, and management review.

Review emergency changes and supplier performance separately. They often reveal whether the SMS is managing reality or simply describing a preferred process nobody follows under pressure.

What teams get wrong

An ITIL tool means we have an SMS.
A tool can support the SMS, but certification depends on scoped services, commitments, practices, governance, performance evaluation, and improvement.
Every urgent change is an emergency change.
Emergency change should be exceptional, risk-based, approved, documented, and reviewed. Daily emergency changes indicate process or planning failure.
Supplier performance is outside ITSM scope.
Suppliers that support certified services need requirements, monitoring, review, and escalation that align with service commitments.

When the checklist is enough — and when it is not

  • Use the checklist to organize SMS scope, services, SLAs, practices, supplier controls, and audit evidence.
  • Ask a registrar, ISO 20000 advisor, or service management assessor when scope, SLA evidence, or certification readiness is unclear.
  • Ask counsel when customer service commitments, outsourcing terms, penalties, or incident obligations are contractually significant.
  • Treat this guide as practical orientation, not official ISO text; use the licensed standard and registrar instructions for authoritative requirements.

Related checklists

Related field notes

The checklists and field notes provided on this website are for educational and informational purposes only. They do not constitute legal, financial, or professional advice. Completing a checklist does not guarantee compliance, certification, or immunity from audits. Always consult with a certified auditor or legal counsel for your specific organizational needs. Full disclaimer