Why Definitions Matter in ISO 20000
In any management system standard, precise terminology is the foundation on which requirements are built. When ISO 20000-1:2018 uses the word “service,” it has a specific meaning. When it refers to an “incident,” it means something distinct from a “problem.” When it specifies requirements for a “service management plan,” it means a particular type of document with particular content. Practitioners who approach the standard with informal, colloquial understandings of these terms frequently find that their implementation drifts away from what the standard actually requires — a disconnect that auditors reliably identify.
This article defines and explains the most critical concepts in ISO 20000-1:2018 terminology. The definitions are drawn from ISO/IEC 20000-10:2018 (the vocabulary standard) and ISO/IEC 20000-1:2018 itself, with practitioner context added to explain how each concept applies in implementation and audit situations. Understanding these terms precisely is a prerequisite for reading and implementing the standard correctly.
Service: The Foundational Concept
Everything in ISO 20000 flows from the concept of service. ISO/IEC 20000-10:2018 defines a service as a “means of delivering value to customers by facilitating outcomes customers want to achieve.” This deceptively simple definition contains three important elements: services deliver value, they do so by enabling customer outcomes, and the value is defined from the customer’s perspective, not the provider’s.
In practice, this means that what counts as a “service” under ISO 20000 is not necessarily everything an IT organization does internally. A service is something that a customer — an identified party with defined requirements — receives and derives value from. The email platform, the enterprise resource planning system access, the help desk capability, the cloud hosting environment — these are services because identifiable customers rely on them and derive business outcomes from them. Internal infrastructure components that support services — a SAN, a network switch, a monitoring tool — are service components, not services in the ISO 20000 sense.
| KEY CONCEPT | The distinction between a service and a service component is central to scope definition and Clause 8 practice design. Services have customers and SLAs. Service components support services and are managed through configuration management. Getting this distinction right at the scoping stage prevents significant rework later in implementation. |
Service Management System (SMS)
The SMS is the set of interrelated or interacting elements of an organization to establish policy and objectives, and to achieve those objectives, as they relate to the management of services. It is the management system infrastructure — the governance, policies, processes, procedures, documented information, resources, and controls — that enables an organization to plan, design, transition, deliver, and improve its services consistently and at a measurable quality level.
The SMS is not a software system or a tool. It is an organizational system. Tools (service desk platforms, CMDB software, monitoring systems) support the SMS, but they are not the SMS itself. An organization with sophisticated ITSM tooling but no governance infrastructure, no documented policies, and no management review process does not have an SMS in the ISO 20000 sense. Conversely, an organization with well-governed processes and clear accountability — even if its tooling is modest — may have a genuinely effective SMS.
Service Management Plan
The service management plan is a required documented output of Clause 6.3. It is the plan that describes the approach the organization will take to deliver and manage services in accordance with its service management objectives. It typically includes the scope of the SMS, the services being managed, the resources allocated, the roles and responsibilities for service management, the objectives being pursued, the timeline for achieving them, and the governance arrangements that will monitor progress.
The service management plan should not be confused with a project plan for implementing ISO 20000 (though project plans are useful during implementation). Once the SMS is operational, the service management plan is a living document that governs ongoing SMS operation — updated at planned intervals, reviewed at management review, and used as the baseline against which SMS performance is measured.
Service Level Agreement (SLA) and Service Level Objective (SLO)
A Service Level Agreement (SLA) is a documented agreement between the service provider and a customer that defines the services to be provided, the service levels to be achieved, and the responsibilities of both parties. SLAs are the primary mechanism through which service quality is formally committed to customers — they specify measurable targets for availability, response time, resolution time, and other performance parameters, and they define the consequences of non-achievement.
A Service Level Objective (SLO) is a measurable target within an SLA. Where an SLA is the overall agreement, an SLO is a specific metric commitment within it: for example, “priority 1 incidents will be resolved within 4 hours” or “the email service will be available 99.9% of measured time during business hours.” SLOs are what gets monitored, reported, and evaluated in service performance reporting. When an SLA is said to have been “breached,” it is usually a specific SLO that has not been met.
An Underpinning Contract (UC) is the contractual agreement with a supplier that supports the delivery of an SLA commitment to a customer — for example, a data center availability guarantee that underpins a cloud hosting availability SLA. Aligning SLAs, SLOs, and UCs is one of the core disciplines of service level management, covered in Article 5.1.
| Term | Definition | Example |
|---|---|---|
| SLA | Documented agreement between provider and customer defining service and service levels | "The email service will be available during business hours with response support within 4 hours for P1 issues" |
| SLO | A specific measurable target within an SLA | "P1 incident resolution within 4 hours" or "99.9% email availability" |
| OLA | Operational Level Agreement — internal agreement supporting SLA delivery | Agreement between service desk and server team: P1 escalation within 30 minutes |
| UC | Underpinning Contract — supplier contract supporting SLA delivery | Data center SLA: 99.95% power availability guarantee |
Customer and Interested Party
A customer is a person or organization that receives a service. In ISO 20000, customers are the parties who have agreed service level requirements with the service provider and to whom the service provider is accountable for service delivery. Customers may be external (organizations purchasing managed services) or internal (business units receiving services from a corporate IT department).
An interested party (also called a stakeholder) is a person or organization that can affect, be affected by, or perceive itself to be affected by a decision or activity of the organization. The interested party concept in Clause 4.2 is broader than customers: it includes regulators, suppliers, staff, shareholders, and others whose needs and expectations the SMS must consider. Understanding who the interested parties are and what they require of the SMS is foundational to scoping and designing the SMS correctly.
| KEY CONCEPT | The distinction between customers and interested parties matters for scope definition. The SLA-based service delivery relationship is with customers. The broader stakeholder landscape — including regulators like OJK or BSSN — represents interested parties whose requirements may shape SMS design without being customers in the strict sense. |
Incident, Problem, and Known Error
These three terms form the backbone of ISO 20000’s resolution practices and are among the most frequently misunderstood by organizations coming from an informal IT operations background.
An incident is an unplanned interruption to a service or reduction in the quality of a service. When a user cannot log in to the CRM system because the authentication service is down, that is an incident. When email delivery is delayed by 30 minutes due to a mail queue problem, that is an incident. The defining characteristic of an incident is that it directly affects service delivery to a user or customer. Incident management aims to restore normal service operation as quickly as possible — the goal is restoration, not necessarily root cause resolution.
A problem is the cause of one or more incidents. Problems may be identified reactively — by investigating a recurring incident pattern — or proactively, by analyzing trends before a major incident occurs. Problem management aims to identify and eliminate the root cause of incidents, reducing incident frequency and impact over time. Problem management is distinct from incident management: an incident can be closed (service restored) while the underlying problem remains open and under investigation.
A known error is a problem for which the root cause has been identified but a permanent fix has not yet been implemented. Known errors are important because they enable faster incident resolution: when an incident occurs that matches a known error, the workaround documented for that known error can be applied immediately without requiring a full investigation. The known error database is the repository of known errors and their associated workarounds.
| Concept | Definition | Goal | Record Type |
|---|---|---|---|
| Incident | Unplanned service interruption or quality reduction | Restore service quickly | Incident record |
| Problem | Root cause of one or more incidents | Eliminate root cause permanently | Problem record |
| Known Error | Problem with identified root cause, fix not yet implemented | Enable faster incident resolution via workaround | Known error record |
Change and Release
A change is the addition, modification, or removal of anything that could have an effect on services. Changes are controlled through the change management process to ensure that they are assessed for risk, approved by appropriate authority, implemented in a way that minimizes disruption, and reviewed after implementation. ISO 20000 recognizes different types of changes: standard changes (pre-authorized, low-risk, well-documented procedures), normal changes (require assessment and approval before implementation), and emergency changes (require urgent implementation — approval may follow implementation in some cases).
A release is a collection of one or more changes to a service that are built, tested, and deployed together. Release management covers the planning, testing, and controlled deployment of releases into the production environment. Not every change requires a formal release — small changes to configuration may be deployed individually — but significant service changes typically go through a release cycle that bundles multiple change components for coordinated testing and deployment.
Configuration Item (CI) and the CMDB
A Configuration Item (CI) is any component that needs to be managed in order to deliver a service. CIs include hardware (servers, network devices, end-user devices), software (operating systems, applications, licenses), services themselves, documentation (procedures, SLAs), and any other element that contributes to service delivery and needs to be tracked. The scope of what is defined as a CI is a key configuration management design decision — too broad a CI scope creates management overhead; too narrow a scope leaves important components untracked.
The Configuration Management Database (CMDB) is the repository that stores information about CIs and the relationships between them. A well-maintained CMDB enables effective incident management (identifying affected CIs when an incident occurs), change management (assessing the impact of proposed changes on related CIs), problem management (identifying CI patterns in recurring incidents), and availability management (tracking the reliability of critical CIs). The CMDB is also typically used to maintain the accuracy of the service portfolio by tracking which CIs support which services.
| IMPORTANT | A common implementation failure is treating the CMDB as a static asset inventory rather than a dynamic relationship map. The value of configuration management for ISO 20000 comes from CI relationship mapping — knowing that Server A supports Application B, which is a component of Service C — not just from knowing that Server A exists. Auditors routinely test whether CMDB data is accurate and whether it is actually used for incident, change, and problem management decisions. |
Continual Improvement
Continual improvement in ISO 20000 is not an aspiration — it is a requirement. Clause 10.2 requires the organization to continually improve the suitability, adequacy, and effectiveness of the SMS. This means that the organization must have a structured mechanism for identifying improvement opportunities, prioritizing them, implementing improvement actions, and verifying that improvements have achieved their intended effect.
The improvement register is the typical vehicle: a centralized record of identified improvements (drawn from management review outputs, internal audit findings, customer satisfaction data, incident trend analysis, and other sources), with priority ratings, assigned owners, implementation timelines, and outcome measurement. The improvement process should be visibly connected to SMS performance data — improvements should be identifiable as responses to specific performance gaps, not just ad-hoc initiatives.
Availability and Service Continuity
Availability refers to the ability of a service or service component to perform its required function at a stated instant or over a stated period of time. Availability is typically expressed as a percentage of agreed service time during which the service performs its required function without interruption. SLA availability commitments — for example, 99.9% availability — are underpinned by availability management: the practice of monitoring actual availability, analyzing trends, and taking action to maintain or improve it.
Service continuity management focuses on ensuring that the SMS has the ability to resume service delivery after a major disruption — one that cannot be resolved by normal incident management procedures within acceptable timeframes. Service continuity is distinct from availability: availability management deals with day-to-day service performance, while service continuity management deals with exceptional events (data center failures, major cyberattacks, natural disasters). ISO 20000’s service continuity requirements align with ISO 22301 business continuity management concepts, and Article 3.7 covers their integration.
Quick Reference Glossary
| Term | Definition in ISO 20000 Context |
|---|---|
| Service | A means of delivering value to customers by facilitating outcomes they want to achieve |
| SMS (Service Management System) | The management system through which an organization plans, delivers, and improves services |
| Service Management Plan | The required documented plan describing how service management objectives will be achieved |
| SLA (Service Level Agreement) | Documented agreement between provider and customer defining service and performance targets |
| SLO (Service Level Objective) | A specific measurable performance target within an SLA |
| Customer | A person or organization that receives and has agreed requirements for a service |
| Interested Party | Any person or organization that can affect or be affected by the SMS or its outputs |
| Incident | An unplanned interruption to or quality reduction of a service |
| Problem | The cause of one or more incidents; requires root cause investigation |
| Known Error | A problem with identified root cause for which no permanent fix has been applied |
| Change | An addition, modification, or removal of anything that could affect services |
| Release | A set of changes built, tested, and deployed to the production environment together |
| CI (Configuration Item) | Any component that must be managed to deliver a service |
| CMDB | The database storing CI information and relationships between CIs |
| Continual Improvement | Recurring activity to enhance SMS performance and effectiveness |
| Availability | Ability of a service to perform its function at a required time; expressed as a percentage |
| Service Continuity | Capability to resume service delivery following a major disruption |
| BITLION INSIGHT | Bitlion GRC Platform includes a pre-built ISO 20000 terminology reference integrated into the SMS policy and procedure templates. Each template uses ISO 20000 defined terms consistently, reducing the risk of terminology drift between documentation and audit evidence. The platform’s CMDB integration module supports CI relationship mapping directly aligned to ISO 20000 Clause 8.6 configuration management requirements. |
Applying These Concepts in Implementation
As you work through the clause-by-clause requirements in Section 2 and the implementation guidance in Section 3, these definitions will be the vocabulary you need. When you encounter “the organization shall establish a service management plan” in Clause 6.3, you now know precisely what that plan must contain. When Clause 8.6.3 requires you to “control the activities related to configuration management,” you know what a CI is and what a CMDB is expected to provide. When Clause 8.6.1 requires you to “manage incidents,” you know the precise difference between an incident, a problem, and a known error — and why all three records must be maintained separately.
Article 1.4 builds on these foundations to explore the relationship between ISO 20000 and ITIL in depth: how ITIL practices map to ISO 20000 requirements, where they diverge, and how organizations can use their ITIL knowledge base as a starting point for SMS implementation without conflating framework adoption with certified standard compliance.