ISO/IEC 20000-1: ISO/IEC 20000-1 – Tutorial (about 60 minutes)

ISO/IEC 20000-1 is the international standard that sets out the requirements for a service management system (SMS): a managed, repeatable way for an organisation to plan, design, deliver, run and improve the services it provides to customers. It is used mainly by IT departments, managed service providers, cloud and hosting companies and outsourcers, very often to obtain a certificate that customers recognise. After this tutorial you will be able to explain how the standard is built, what its service management processes require, how certification works, and how to apply it to a real organisation without drowning in paperwork.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO/IEC 20000-1:2018, Information technology – Service management – Part 1: Service management system requirements (third edition, published in 2018 by ISO and IEC through joint technical committee ISO/IEC JTC 1/SC 40, IT service management and IT governance). It has one amendment, ISO/IEC 20000-1:2018/Amd 1:2024 (published February 2024), the short "climate action changes" amendment that ISO applied to its management system standards, which asks the organisation to consider whether climate change is a relevant issue in its context. No newer edition of Part 1 has been published; certificates are issued against the 2018 edition with its amendment, and the transition from the 2011 edition finished in 2021. SC 40 keeps adding guidance parts to the 20000 series around it (for example on Agile and DevOps in 2024 and on sustainability in 2025). Verified 2026-10-29.

Who this is for: IT operations and support staff, site reliability and platform engineers, service desk leads, service owners, project and quality managers, auditors and anyone whose organisation has said "our customers want ISO 20000" and who now needs to understand what that means in daily work.

Prerequisites: none. It helps if you have seen a service desk ticket, a change request or a service level report, but every term is explained when it first appears. Familiarity with ITIL is useful but not required.

By the end of this tutorial:

You will be able to explain what a service management system is and why ISO/IEC 20000-1 is written as requirements rather than as a book of good practice.
You will be able to describe the ten-clause structure of the standard and the six process groups of clause 8.
You will be able to explain how key processes such as service level, change, incident, problem, configuration and supplier management fit together.
You will be able to outline the certification journey, from scoping and internal audit to stage 1 and stage 2 audits, surveillance and recertification.
You will be able to apply the standard to a realistic service provider, including services that depend on suppliers and other parties.
You will be able to compare ISO/IEC 20000-1 with ITIL, ISO/IEC 27001, ISO 9001 and COBIT and explain how they work together.

Lesson 1 – Origins, purpose and scope

Why a management system for services?

Almost every organisation that runs IT already does some service management. Someone answers the phone when a system breaks, someone approves changes, and someone writes a monthly report on uptime. The problem is that these activities are often informal. They depend on a few experienced people, they are done differently by each team, and nobody can show a customer, with evidence, that services are delivered as promised and that problems are actually prevented rather than just fixed again and again.

ISO/IEC 20000-1 tackles this by treating service delivery as something to be managed as a system. Instead of telling you which tool to buy or which team structure to use, it lists the outcomes an organisation must achieve: understand what customers need, agree and document services, control changes, restore service quickly when things go wrong, find and remove the causes of failures, keep enough capacity, protect information, and keep improving. The combination of policies, plans, processes, roles, records and tools that achieves this is called the service management system, or SMS. The SMS is not a software product, even though tools usually support it.

A short history

The standard grew out of British Standard BS 15000, published by BSI in the early 2000s and strongly influenced by the IT Infrastructure Library (ITIL), the UK government's collection of IT service management practices. BS 15000 was adopted internationally as ISO/IEC 20000 in 2005, in two parts: a set of requirements (Part 1) and a code of practice (Part 2). A second edition of Part 1 followed in 2011 and tightened the requirements. The third edition, published in 2018, was a major rewrite. It adopted the common structure that ISO uses for all management system standards, made the requirements less tied to a particular way of organising processes, and added topics such as knowledge, service planning, demand management, asset management and the control of other parties. The 2024 amendment added only the climate-change consideration mentioned above.

Responsibility for the series moved from the software engineering subcommittee (JTC 1/SC 7) to a new subcommittee, JTC 1/SC 40, when SC 40 was created in 2013. SC 40 also looks after the governance of IT (the ISO/IEC 38500 family) and IT-enabled services. The standard is copyrighted and sold by ISO, IEC and national standards bodies; this tutorial explains it in its own words.

What the standard covers and what it does not

ISO/IEC 20000-1 is a requirements standard. Its requirements use the word "shall", which means an organisation that claims conformity must meet them and an auditor can check whether it does. The rest of the series consists mostly of guidance (with words like "should" and "can") that helps you meet those requirements. Part 1 applies to any organisation that delivers services, whatever its type, size or sector: an internal IT department serving its own company, a software-as-a-service vendor, a managed service provider, a government shared-services centre or a telecom operator. Although the title starts with "Information technology", the requirements are written generically, and some organisations use them for non-IT services as well.

Two features make the scope unusual. First, the organisation decides which services are inside the SMS: it may certify one service for one group of customers at one location, or every service it offers. Second, once the scope is set, none of the requirements in clauses 4 to 10 may be excluded. You cannot say "we do not do problem management" or "capacity is not our concern" and still claim conformity. This is different from standards with a menu of optional controls. The flexibility lies in how you meet each requirement and in the scope you choose, not in which requirements apply.

The standard does not prescribe tools, team names, ticket fields, specific service level targets or a particular framework. It does not say what your availability target should be; it says you must agree targets with customers, monitor them and act when they are missed. It also does not certify people. Individual qualifications exist, but they are separate from organisational certification, as Lesson 5 explains.

What organisations get out of it

The benefits most often reported are practical. Customers get clear agreements and reliable reporting. Staff get consistent processes instead of tribal knowledge. Management gets data about performance, workload and risk. Suppliers are managed against defined expectations. Over time, recurring incidents fall because problems are analysed rather than ignored. For service providers, a certificate is also a way to answer customer due-diligence questionnaires and tender requirements with one piece of independent evidence. None of this comes from the certificate itself; it comes from running the system well.

Lesson 2 – Key concepts and vocabulary

The vocabulary of ISO/IEC 20000-1 is shared with ISO/IEC 20000-10, the concepts and vocabulary part of the series, and with the common terms used in all ISO management system standards. The definitions below are explained in plain language, not quoted. Learning them first will make the rest of the standard much easier to read.

Service – a means of delivering value to a customer by helping them achieve outcomes they want, such as "employees can send email" or "shoppers can pay online". A service is defined from the customer's point of view, not as a list of servers.
Service component – a single part of a service which, combined with others, makes up the whole service. Examples are an application, a database, a network link, a support team or a supplier's hosting platform.
Service management system (SMS) – the management system that directs and controls the organisation's service management activities: policy, objectives, plans, processes, roles, documented information and resources.
Organization – in the 2018 edition this is the party that operates the SMS and delivers the services in scope. Older texts called it the "service provider".
Customer and user – the customer is the organisation or person that receives a service and usually agrees to its terms; the user is the person or group who actually uses it. A company's finance director may be the customer of a payroll service whose users are all the employees.
Interested party – anyone who can affect, be affected by, or believe themselves affected by the SMS: customers, users, staff, suppliers, regulators and owners.
Service level agreement (SLA) – a documented agreement between the organisation and a customer that identifies the services and the service level targets, such as hours of support, availability or response times.
Service catalogue – documented information about services, including what each one is for, who it is for and how it is requested and supported.
Incident – an unplanned interruption to a service, a reduction in its quality, or an event that has not yet affected customers but could. A full disk that has not yet stopped anything still counts.
Service request – a user's request for something routine that is part of normal service delivery, such as a password reset, access to a system or information.
Problem – the cause of one or more actual or potential incidents. A problem is not a big incident; it is the underlying reason why incidents happen.
Known error – a problem whose root cause has been identified, or for which there is a way to reduce or remove its impact (a workaround), even if it has not yet been permanently fixed.
Change – adding, modifying or removing anything that could affect services, such as code, configuration, infrastructure or documentation.
Release – a collection of one or more new or changed services or service components that is deployed into the live environment as a result of one or more changes.
Configuration item (CI) – an element that needs to be controlled in order to deliver services, for example a server, an application version, a contract or a network device. Information about CIs and their relationships is called configuration information.
Asset – an item that has potential or actual value to the organisation, such as hardware, software licences or data. Assets and CIs overlap but are not the same: a licence matters for cost and legality, a CI matters for controlling the service.
Other party – a party outside the organisation's SMS that is involved in delivering services: an external supplier, an internal supplier (another department in the same company), or a customer that itself acts as a supplier.
Documented information – information the organisation must control and keep, along with the medium it sits on. It covers both documents (such as a policy) and records (such as a closed incident ticket).
Nonconformity and corrective action – a nonconformity is a failure to meet a requirement; corrective action removes its cause so that it does not happen again.

Requirements versus guidance

A frequent beginner mistake is to treat every document in the 20000 series as mandatory. Only Part 1 contains requirements for an organisation's SMS. ISO/IEC 20000-2 explains how to apply them, ISO/IEC 20000-3 helps with defining scope, ISO/IEC 20000-10 sets out concepts and vocabulary, and several technical specifications and reports show how the standard relates to ITIL, to service integration, to Agile and DevOps and to sustainability. ISO/IEC 20000-6 contains requirements too, but for certification bodies, not for the organisation being certified.

Services, not technology

The single most important idea in ISO/IEC 20000-1 is that everything starts from the service as the customer experiences it. Infrastructure, applications and teams matter only as components of services. This changes the questions people ask. Instead of "Is the database cluster up?", the question becomes "Can customers place orders, and are we meeting what we agreed with them?" Service level targets, incident priorities, change risk and capacity plans are all expressed in terms of their effect on services.

Lesson 3 – Structure of the standard

ISO/IEC 20000-1:2018 follows the harmonized structure (formerly called Annex SL) that ISO uses for all management system standards. This means its first ten clause titles are the same as those of ISO 9001, ISO/IEC 27001 and ISO 22301, which makes it much easier to run an integrated management system. Clauses 1 to 3 are introductory; clauses 4 to 10 contain the requirements an auditor checks.

Figure 1 – The requirement clauses 4 to 10 of ISO/IEC 20000-1 arranged on the Plan-Do-Check-Act cycle.

Clauses 1 to 3: scope, references, terms

Clause 1 explains what the standard is for and how it applies, including the rule that requirements in clauses 4 to 10 cannot be excluded. Clause 2 lists normative references; in the 2018 edition there are none. Clause 3 defines terms, split into those common to all management system standards and those specific to service management.

Clause 4: Context of the organization

Before designing anything, the organisation must understand its situation: internal and external issues that affect its ability to deliver the intended outcomes of the SMS (since the 2024 amendment, explicitly including whether climate change is relevant), the interested parties and their requirements, and the scope of the SMS. The scope must be stated in terms of the services and the organisation delivering them. Clause 4 finishes with the general requirement to establish, implement, maintain and continually improve the SMS.

Clause 5: Leadership

Top management, meaning the people who direct the organisation at the highest level for the scope, must show leadership and commitment. In practice that means setting a service management policy and objectives, making sure the SMS fits the business, providing resources, communicating why service management matters, and assigning responsibilities and authorities. Auditors look for evidence that top management itself takes part; leadership cannot simply be handed to a "20000 project team".

Clause 6: Planning

Clause 6 has three parts. The organisation must identify risks and opportunities related to the SMS and its services and decide how to address them, including setting criteria for which risks are acceptable. It must set measurable service management objectives and plan how to achieve them. And it must produce a service management plan, a document that brings together the objectives, the services, known limitations, roles, resources, the approach for working with other parties, and how the SMS will be monitored and measured.

Clause 7: Support of the SMS

Clause 7 covers resources, competence, awareness, communication and documented information, as in other management system standards. ISO/IEC 20000-1 adds two things. It lists specific documented information the SMS must have, such as the scope, policy and objectives, the service management plan, the change management, information security and continuity documentation, the service catalogue, SLAs, and supplier contracts and agreements. It also includes a clause on knowledge, which asks the organisation to determine and maintain the knowledge needed to run the SMS and services: the diagnosis notes, design decisions and lessons that experienced staff otherwise keep in their heads.

Clause 8: Operation of the SMS

Clause 8 is by far the longest clause and the one that makes ISO/IEC 20000-1 a service management standard. After an introductory subclause on operational planning and control (8.1), the processes are arranged into six groups. The grouping is a way of organising the text; it does not require you to build six departments.

Figure 2 – The six process groups of clause 8 and the main processes each group contains.

8.2 Service portfolio – deciding which services to offer and planning them (service delivery and planning the services), controlling other parties involved in the service lifecycle, and the service catalogue, asset management and configuration management processes. This group ensures the organisation knows what it delivers and what it depends on.
8.3 Relationship and agreement – business relationship management (understanding customers, handling complaints, measuring satisfaction), service level management (agreeing SLAs with targets and monitoring them) and supplier management, which covers both external suppliers and internal suppliers or customers acting as suppliers.
8.4 Supply and demand – budgeting and accounting for services, demand management (understanding current and forecast demand for services) and capacity management (making sure there is enough human, technical, information and financial capacity to meet agreed requirements).
8.5 Service design, build and transition – change management, guided by a change management policy, service design and transition for new services and for changes with potential major impact, and release and deployment management.
8.6 Resolution and fulfilment – incident management (including a documented approach to major incidents), service request management and problem management.
8.7 Service assurance – service availability management, service continuity management and information security management.

Clause 9: Performance evaluation

The organisation must decide what to monitor and measure, analyse the results, run internal audits at planned intervals and hold management reviews. ISO/IEC 20000-1 adds a fourth subclause on service reporting: the organisation must determine what reports are needed, by whom and how often, and produce reports on the performance of the services and the SMS, including trends. Reports are not decoration; they are inputs to decisions in service level reviews and management reviews.

Clause 10: Improvement

When something does not conform, the organisation must react, correct it, find the cause, take corrective action and check that the action worked. Beyond fixing nonconformities, it must continually improve the suitability, adequacy and effectiveness of the SMS and services, using evaluation criteria to decide which improvement opportunities to pursue.

What changed from the 2011 edition

If you meet people who learned the 2011 edition, a few differences matter. The 2018 edition adopted the harmonized clause structure, so the old explicit Plan-Do-Check-Act clause disappeared (the cycle is now built into the structure). It reduced the volume of mandatory documented procedures, separated service request management from incident management, added knowledge, service planning, demand and asset management, and renamed the clause on processes operated by others as the control of parties involved in the service lifecycle. The term "service provider" was replaced by "organization".

Lesson 4 – How it works in practice

Reading the clauses tells you what is required. This lesson shows how the pieces behave in daily operation, focusing on the processes auditors look at most closely and on how they connect to each other.

From customer need to agreed service

Everything starts in the relationship and agreement group. Business relationship management identifies the customers and their needs and keeps an open channel for complaints and feedback. Service level management turns those needs into SLAs with measurable targets, such as "service available 99.9 % of the time during business hours" or "priority 1 incidents responded to within 15 minutes". The SLA also records workload limits and exceptions, for example how many user requests per month the price covers. The service catalogue describes the agreed services in a form customers and staff can use. The organisation then monitors performance against the targets, reports the results and reviews them with customers at planned intervals.

Service level targets only make sense if the components behind them can support them. That is why supplier management is in the same group. If a hosting supplier promises 99.5 % availability for a platform, the organisation cannot sensibly promise 99.9 % for a service that depends entirely on it. Contracts with external suppliers and agreements with internal suppliers must be aligned with the SLAs, and supplier performance must be monitored and reviewed.

Controlling change and release

Many service failures are triggered by changes, so ISO/IEC 20000-1 puts change management at the centre of service design, build and transition. The organisation must write a change management policy that defines, at a minimum, which CIs are under change control and the criteria for deciding whether a change could have a major impact on customers or services. Most organisations also use the policy to say how standard (pre-approved) and emergency changes are handled. Every change request is recorded and classified, its risks and benefits are assessed, it is approved by a person or group with the right authority, and it is scheduled, implemented, reviewed and closed. Changes that fail can be reversed or remedied.

Figure 3 – How a change moves through change management, with major changes routed through service design and transition.

Changes with potential major impact, and new services or the removal or transfer of services, go through service design and transition. This means planning them properly: requirements, design, building, testing against acceptance criteria and a controlled transition into live operation, with everybody who will support the service ready on day one. Release and deployment management then decides how changes are bundled and deployed, tests releases, and checks after deployment that the result is as expected. None of this rules out frequent, automated deployments. A pipeline that runs tests, records approvals and keeps an audit trail can meet these requirements more reliably than a weekly meeting, and ISO/IEC TS 20000-15 gives guidance on applying the standard with Agile and DevOps ways of working.

Restoring service and removing causes

When something breaks, incident management takes over. Incidents are recorded, classified, prioritised by impact and urgency, escalated when needed, resolved and closed, with the customer kept informed. The organisation must define what a major incident is and follow a documented approach for it: a named person responsible, top management informed, and a review after the incident to learn from it. Service request management handles routine requests through a separate, usually faster path, often with self-service and automation.

Figure 4 – Incident management restores service, while problem management finds and removes the causes so incidents stop repeating.

Problem management works on causes rather than symptoms. Problems are identified from incident trends, major incident reviews or proactive analysis; their root causes are investigated; known errors and workarounds are recorded so that the service desk can resolve future incidents faster; and permanent fixes are raised as changes. The connection is the point of the standard: incident data feeds problem management, problem fixes go through change management, changes update configuration information, and configuration information helps diagnose the next incident.

Knowing what you have

Configuration management keeps accurate information about the CIs that make up services, including their versions, owners and relationships. The standard asks you to define which types of CI you control and to record the information at a level of detail that is useful, not to build a perfect database of every cable. Many organisations hold this in a configuration management database (CMDB), but the standard does not require a particular tool; well-maintained infrastructure-as-code repositories and cloud inventories can serve as sources of configuration information. Asset management makes sure the assets used to deliver services, such as licences and hardware, are managed so that legal, contractual and financial obligations are met.

Keeping enough capacity and protecting the service

Demand management tracks how much customers use each service and forecasts how that will change. Capacity management uses those forecasts to plan the people, infrastructure, information and money needed. Availability management sets availability requirements and targets, monitors them and investigates unplanned unavailability. Continuity management prepares and tests plans to keep or restore services after a serious disruption such as the loss of a data centre. Information security management requires a policy, controls based on assessed information security risks and the handling of security incidents. Organisations that already run an ISO/IEC 27001 ISMS can use it to satisfy much of this, but ISO/IEC 20000-1 itself does not require ISO/IEC 27001 certification.

Other parties and accountability

Modern services almost always depend on suppliers: cloud platforms, telecom carriers, outsourced service desks, software vendors. ISO/IEC 20000-1 accepts this, but it insists that the organisation keeps accountability for meeting the requirements and for the services, whoever performs the work. The organisation must identify every other party involved, decide which processes or components they run, set how their performance is measured, and keep control of them. There is a limit: if other parties provide or operate everything within the scope, the organisation has nothing left to demonstrate and cannot show conformity. A company that merely signs contracts while a supplier does all the work is a broker, not a certifiable service provider.

Roles and artefacts

The standard names few roles explicitly. Top management and the person or group with authority for the SMS are required, and process owners are a common and sensible choice. Typical artefacts include the service management policy, the service management plan, the service catalogue, SLAs, supplier contracts, the change management policy, continuity plans, configuration information, records of incidents, requests, problems and changes, service reports, internal audit reports and management review minutes. The guidance in ISO/IEC 20000-2 helps decide what each should contain.

Lesson 5 – Assessment, certification and compliance

Conformity, certification and accreditation

An organisation conforms to ISO/IEC 20000-1 when its SMS meets every requirement for the chosen scope. It can declare this itself, ask a customer to check it, or obtain independent certification. Certification is performed by certification bodies, which are companies that audit management systems. The most credible certificates come from certification bodies that are themselves accredited by a national accreditation body to show they are competent and impartial. For service management systems, certification bodies follow ISO/IEC 17021-1, the general requirements for bodies certifying management systems, together with ISO/IEC 20000-6, which adds requirements and guidance specific to auditing and certifying a service management system, such as auditor competence. ISO itself does not certify organisations.

Figure 5 – The certification cycle, from preparation through the two initial audit stages to surveillance and recertification.

The audit stages

The initial certification audit has two stages. In stage 1 the auditor reviews the design of the SMS: the scope, the policy, the service management plan, the required documented information, the results of internal audits and management review, and whether the organisation is ready. Stage 1 often finds gaps that must be fixed before stage 2. In stage 2 the auditor checks that the SMS is really implemented and effective. They interview people at all levels, sample records such as incidents, changes and SLA reports, follow a few changes or problems end to end, and look for evidence that the processes work together.

Findings are usually graded as major nonconformities (a requirement is not met at all, or a failure that throws doubt on the system), minor nonconformities (an isolated lapse) and opportunities for improvement. Major nonconformities must be corrected and verified before a certificate is granted. The certificate states the scope, meaning which services, for which customers and from which locations, and is normally valid for three years, with surveillance audits at least once a year and a recertification audit before expiry.

What a good scope statement looks like

Scope is where many certificates mislead. A precise scope names the services, the organisation delivering them, and, where relevant, the customers and locations: for example "the SMS supporting the provision of managed hosting and 24x7 support services to external customers from the Pune and Dublin operations centres". A vague scope such as "IT services" is hard to audit and tells customers little. ISO/IEC 20000-3 gives guidance on scope definition, including how to deal with services that rely on suppliers or on other parts of the same company.

Self-assessment and maturity

Organisations not ready for certification often begin with a gap analysis against the requirements, or with a process capability assessment. The series once included a part for process assessment (ISO/IEC TR 20000-4:2010, now withdrawn); that work continues in the ISO/IEC 330xx process assessment family. Capability assessment and certification answer different questions: assessment tells you how mature a process is on a scale, while certification says yes or no on whether the requirements are met.

Qualifications for people

Several examination institutes offer personal qualifications in ISO/IEC 20000, typically at foundation, practitioner or implementer, and auditor levels. These certify an individual's knowledge. They do not make an organisation conformant, and a team full of qualified people can still fail an audit if the SMS is not running.

Regulation and contracts

ISO/IEC 20000-1 is voluntary. It is not a law in itself, but customers and public-sector buyers sometimes require certification in tenders, and regulators may accept it as evidence of operational control. Where certification is required by contract, check that the certificate's scope actually covers the service you are buying.

Lesson 6 – Worked example

This lesson follows a fictional company through a first certification. The names and numbers are invented for teaching.

The organisation

Northbridge Managed Cloud has 180 staff and offers managed Kubernetes hosting and 24x7 operations to about 60 business customers. The platform runs in two colocation data centres operated by a supplier. First-line support outside business hours is provided by an outsourced service desk partner. Two large banking prospects have asked for ISO/IEC 20000-1 certification within 15 months.

Step 1 – Context, scope and leadership

The leadership team runs a workshop on context. Internal issues include rapid growth, a small senior operations team and knowledge concentrated in a few engineers. External issues include customer demands for stronger evidence, rising energy costs at the data centres and, following the 2024 amendment, whether climate change is relevant: the team decides it is, because heat waves have already caused cooling alarms at one site. Interested parties include customers, users of customer applications, staff, the data centre supplier, the service desk partner and a banking regulator whose expectations reach Northbridge through customer contracts.

They set the scope as "the SMS supporting the managed Kubernetes platform and 24x7 operations services delivered to external customers". Internal finance systems are left out because they are not services to customers. The managing director signs a service management policy, appoints an SMS manager with real authority, and makes the monthly operations review a formal part of the SMS instead of creating a new committee.

Step 2 – Gap analysis and planning

A gap analysis shows strong incident handling but weak problem management (no root cause analysis for repeated outages), informal change approvals in chat channels, SLAs that differ for every customer, no capacity plan, and no review of the service desk partner's performance. The team records these as risks and opportunities and writes a service management plan with four objectives: reduce repeat priority 1 incidents by half, standardise SLAs into three tiers, record every production change with approval evidence, and run capacity reviews every quarter.

Step 3 – Designing the processes

Northbridge does not buy a new tool. It configures its existing ticketing system with separate types for incidents, service requests, problems and changes. The change management policy defines which CIs need approval: cluster configuration, network rules and the platform images. It sets criteria for major-impact changes, such as anything affecting more than ten customers or a data centre. Standard pre-approved changes, such as scaling node pools within limits, are automated through the deployment pipeline, which records who triggered them and the test results. Emergency changes need a senior engineer's approval and a review within two working days.

Configuration information comes from the infrastructure-as-code repository and the cloud inventory, linked to customer services in the service catalogue. A major incident procedure names an incident manager on every shift and requires a written review within five days. Problem management meets weekly to review incident trends.

Step 4 – Other parties

The team maps which other parties are involved. The colocation supplier provides power, cooling and physical security; its contract now includes availability targets aligned with Northbridge's SLAs and quarterly service reviews. The service desk partner operates part of incident management at night; Northbridge defines the partner's responsibilities, the handover rules, the reports it must provide and how performance is reviewed. Northbridge itself runs change, problem, capacity and the rest of the SMS, so it clearly keeps accountability and control. The SMS manager records all of this in the service management plan.

Step 5 – Running, measuring and auditing

For six months the SMS runs. Monthly service reports show availability per tier, incident and request volumes, SLA breaches and change success. Two internal auditors from the quality team, trained in the standard but independent of operations, audit the processes over three months. They find that a quarter of emergency changes have no review, and that the continuity plan for losing one data centre has never been tested. Both become corrective actions. A failover test is run on a weekend; it takes longer than planned, and the plan is improved. Top management holds a management review covering objectives, audit results, customer feedback, supplier performance and resources, and approves another senior engineer to reduce knowledge concentration.

Step 6 – Certification

The stage 1 audit finds the documentation sound but notes that the service catalogue does not show which services depend on the service desk partner. This is fixed. At stage 2 the auditor samples 25 changes, follows a major incident from detection through review to the resulting problem and permanent fix, interviews night-shift partner staff, and checks capacity reviews. One minor nonconformity is raised: two customers' SLAs had not been reviewed in the planned interval. Northbridge corrects it and is certified. In the first year, repeat priority 1 incidents fall by 40 %, short of the target, which management records honestly and keeps as an objective. Surveillance audits will check whether the improvements hold.

What the example shows

The example illustrates the main ideas of the standard: start from services and customers; set a precise scope; use existing tools; tie processes together; keep control of other parties; let audits and reviews drive improvement; and measure honestly rather than producing perfect-looking reports.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 20000-1 rarely stands alone. Most organisations that use it also use ITIL or another body of practice, and many run it alongside quality and security management systems. Understanding the differences prevents both duplication and confusion.

Standard or framework	What it is	How it relates to ISO/IEC 20000-1
ITIL 4 (PeopleCert / AXELOS)	A best-practice framework and body of guidance for service management, with practices, a service value system and value streams.	ITIL explains how you might do service management; ISO/IEC 20000-1 says what must be achieved and can be certified. ITIL itself is not certifiable for organisations. ISO/IEC TS 20000-11 describes the relationship between the two.
ISO/IEC 27001	Requirements for an information security management system (ISMS).	Same harmonized clause structure. ISO/IEC 20000-1 requires information security management for services; an ISMS can provide it. Many providers run an integrated system and certify to both.
ISO 9001	Requirements for a quality management system.	Same clause structure and a shared focus on customers and improvement. ISO 9001 is generic across products and services; ISO/IEC 20000-1 adds detailed service management processes.
ISO 22301	Requirements for a business continuity management system.	ISO/IEC 20000-1 requires service continuity for the services in scope; ISO 22301 covers continuity of the whole business and can supply the method.
COBIT (ISACA)	A framework for the governance and management of enterprise information and technology.	COBIT works at the governance and enterprise level and covers more than services; ISO/IEC 20000-1 can be the operational service management system beneath it.
ISO/IEC 38500	Principles for the governance of IT by an organisation's governing body.	From the same subcommittee (SC 40). It addresses the board's direction and oversight; ISO/IEC 20000-1 addresses managing the services that put those decisions into effect.

ITIL and ISO/IEC 20000-1 together

Because the standard grew out of a British standard influenced by ITIL, the two share vocabulary: incident, problem, change, release, configuration item and service level are familiar to anyone trained in ITIL. The difference is in purpose. ITIL 4 is a flexible body of guidance that encourages organisations to adapt practices to their own value streams. ISO/IEC 20000-1 is a short set of auditable requirements. A common pattern is to use ITIL guidance to design processes and the standard to check that nothing essential is missing and to prove it to customers. You do not need ITIL to meet ISO/IEC 20000-1, and you can use other methods such as DevOps, site reliability engineering or lean practices.

Integrated management systems

Since ISO/IEC 20000-1, ISO/IEC 27001, ISO 9001 and ISO 22301 share clauses 4 to 10, an organisation can run one integrated management system with a single document control process, one internal audit programme, one management review and one corrective action process, and add the specific requirements of each standard on top. Certification bodies often audit them together, which saves time and reduces duplicated evidence. The guidance once given in ISO/IEC TR 20000-7 on integrating with ISO 9001 and ISO/IEC 27001 has been withdrawn, but the shared structure still makes integration straightforward.

Agile, DevOps and SRE

Teams sometimes fear that the standard forces slow, bureaucratic processes. It does not. Its requirements are about outcomes and control: changes assessed and approved by the right authority, releases tested, incidents managed, problems analysed. Automated pipelines, peer review, feature flags, error budgets and blameless post-incident reviews can all provide that control and its evidence. ISO/IEC TS 20000-15 offers guidance on this combination.

Common pitfalls and best practices

Common pitfalls

Vague scope – certifying "IT services" without naming the services, customers and locations, which makes audits hard and certificates meaningless to customers.
Paper processes – writing long procedures that nobody follows while real work happens in chat channels, so auditors find a gap between documents and records.
Losing control of suppliers – assuming that a supplier's own certificate covers your obligations, or outsourcing so much that the organisation can no longer show accountability and control.
Problem management in name only – opening problem records that are never analysed, so the same incidents keep returning.
SLAs without matching supplier commitments – promising customers targets that the underlying contracts and capacity cannot support.
Reports nobody reads – producing service reports full of metrics that are not discussed in service reviews or management reviews and never lead to decisions.
A one-off project – treating certification as the finish line and letting the SMS decay until the next surveillance audit.

Best practices

Start from services – build the service catalogue and agree SLAs first, then design processes around them.
Use existing tools – configure the ticketing system, pipelines and inventories you already have so that evidence is created as a by-product of normal work.
Connect the processes – link incidents to problems, problems to changes and changes to configuration information, and check those links in internal audits.
Write a clear change policy – define which CIs are controlled, what counts as major impact and how standard and emergency changes work, then automate where you can.
Manage other parties actively – document their role, align their contracts with SLAs, receive their reports and review their performance regularly.
Keep leadership involved – make management review a real decision meeting about objectives, resources and risks, not a slide show.
Audit continuously – spread internal audits across the year and choose samples that follow work end to end.

Summary and key takeaways

ISO/IEC 20000-1:2018, with its 2024 climate amendment, is the current international requirements standard for a service management system, maintained by ISO/IEC JTC 1/SC 40.
It follows the harmonized structure of clauses 4 to 10, so it integrates easily with ISO 9001, ISO/IEC 27001 and ISO 22301.
Clause 8 organises the service management processes into six groups: service portfolio, relationship and agreement, supply and demand, design, build and transition, resolution and fulfilment, and service assurance.
No requirement in clauses 4 to 10 may be excluded; flexibility comes from the chosen scope and from how each requirement is met.
The organisation keeps accountability for services even when other parties do part of the work, and cannot show conformity if others run everything in scope.
Certification is done by accredited certification bodies through stage 1 and stage 2 audits, followed by yearly surveillance and recertification every three years.
ITIL and similar frameworks describe how to do service management; ISO/IEC 20000-1 states what must be achieved and can be independently certified.
The value comes from connected, evidence-producing processes and real management attention, not from documents written for the auditor.

Reflection questions

Think of one service your organisation provides. How would you describe it from the customer's point of view, and which service components and other parties does it depend on?
If your organisation sought certification next year, what scope would you propose, and what would you deliberately leave out and why?
Where do changes to production systems get approved today, and what evidence would an auditor find for a change made last week?
Which recurring incidents in your environment would benefit most from problem management, and who would own the analysis?
How would you show an auditor that you remain in control of a critical supplier whose own certificate you have seen?