Building a service catalogue that satisfies ISO 20000-1 and customers

Defining the Service Hierarchy and Scope

The core error most firms make is treating the service catalogue as a static PDF or a simple spreadsheet. Under ISO 20000-1:2018, the service catalogue is a critical component of the Service Management System (SMS) that defines the scope of what you are actually certifying. If your catalogue is vague, your entire SMS sits on a foundation of sand, making it impossible to measure performance or manage risks effectively.

A high-performing service catalogue serves two masters: the internal technical teams and the external customer. Clause 8.2.2 specifically requires that the service catalogue be maintained and include information for the organisation to manage and provide services. This means you cannot just list 'Cloud Hosting'; you must define the service levels, the support hours, and the target reliability that the customer expects.

Transitioning from an ad-hoc list to a structured catalogue requires a shift in mindset from 'what we do' to 'what we deliver.' Start by identifying your primary services—those that provide direct value to your customers—and distinguish them from supporting services. This clarity is the first step toward a successful ISO 20000-1 audit and a more transparent relationship with your stakeholders.

The Anatomy of a High-Quality Service Entry

The 'standard' service catalogue often lacks the granular detail required for modern compliance. To satisfy Clause 8.2.2, you should enforce a mandatory data schema for every entry in your catalogue. This ensures consistency and makes the catalogue a functional tool rather than just a document. Without these specific fields, your service reporting will eventually fall out of sync with your contractual obligations.

Consider the 'Service Owner' as the most critical attribute. Every service listed must have a single point of accountability. This individual is responsible for ensuring the catalogue entry matches the current operational reality and that any changes to the technical stack are reflected in the business view. In my experience, service catalogues fail not because of technology, but because of a lack of clear ownership.

• Service Name and unique identifier.
• Service Description (written for a non-technical stakeholder).
• Service Level Targets (Availability, Response Times, Resolution Times).
• Internal and External Dependencies (who provides the underlying infrastructure?).
• Contact points for support and escalation paths.
• Security classification of the data handled within the service.

Mapping Dependencies and Technical Views

Clause 7.5.3 of the standard emphasizes the importance of understanding the relationships between the service and the components that support it. This is where the 'Technical Service Catalogue' comes into play. It acts as the bridge between your Configuration Management Database (CMDB) and your customer-facing service definitions. Mapping these dependencies allows you to perform accurate impact assessments during change management.

If a service is down, your service catalogue should tell you exactly which technical assets are at fault—be it a specific server, a third-party API, or a network segment. For firms seeking ISO 20000-1 certification, auditors will look for evidence that you understand these horizontal and vertical relationships. They want to see that you aren't just reacting to incidents, but managing them through a structured understanding of your service architecture.

This mapping also provides a strategic advantage during sales cycles. When a prospect asks how you ensure uptime, you can produce a service map that demonstrates a level of operational maturity far beyond your competitors. It proves that you understand your own complexity and have built the safeguards necessary to manage it.

Managing the Service Lifecycle

A service catalogue is a living entity, and its lifecycle must be governed by your Service Design and Transition processes (Clause 8.5). You cannot simply add a new service to the catalogue because a developer had a good idea; it must go through a formal vetting process to ensure it can be supported, secured, and delivered to the promised standards.

Every new service entry should trigger a series of checks. Does it have a backup plan? Is it covered by your Cyber Essentials or ISO 27001 controls? Does it meet the financial requirements for delivery? By embedding the service catalogue into your lifecycle management, you ensure that 'Shadow IT' doesn't creep into your operations and create hidden risks that emerge only during an audit.

Retiring a service is just as important as launching one. An 'outdated' service catalogue that includes decommissioned services is a red flag for auditors. It suggests a lack of control over the environment. Implement a 'Sunset' status in your catalogue to formally track services that are no longer offered but may still have legacy users transitioning to new solutions.

• Inquiry: Initial check to see if the service exists in the catalogue.
• Design: Defining the parameters and constraints of the new service.
• Transition: Moving the service from 'Pipeline' to 'Live' within the catalogue.
• Retirement: A formal process for removing services and notifying users.

Aligning the Catalogue with SLA Reporting

Ultimately, the service catalogue is the primary tool for Service Level Management (Clause 8.2.1). You cannot measure Service Level Agreements (SLAs) if you haven't clearly defined what those services are in the catalogue. Your monthly or quarterly service reports should map directly back to the entries in the catalogue, creating a coherent story of performance versus promise.

When you stand before an ISO 20000-1 auditor, they will ask for a list of your services and then ask to see the performance logs for a random selection. If your catalogue says '99.9% availability' but your monitoring tools only track the server uptime and not the end-to-end service, you have a non-conformity. The catalogue sets the expectation that the rest of your SMS must meet.

For founders and heads of security, the service catalogue is your 'trust manifest.' It is the document that tells your customers exactly what they are paying for and what they have a right to expect. By building it with ISO 20000-1 in mind, you are not just checking a compliance box; you are building a professional, scalable service delivery engine that justifies higher price points and longer contracts.

Frequently asked questions