Service catalogue management

ISO/IEC 20000-1 Clause 8.2.4 requires you to create and maintain a service catalogue (or catalogues) as documented information, and make it available to appropriate parties. Operationally, you must define each service with a consistent minimum data set (name, description, owner, service levels, supporting services, status) and keep it current through change control and periodic review. ¹

Key takeaways:

• Build one authoritative catalogue with required fields, clear ownership, and a controlled publishing process.
• Tie catalogue entries to SLAs/targets and to the internal and third-party components that support each service.
• Auditors look for currency, completeness, access controls, and evidence that the catalogue matches reality in operations.

Service catalogue management is a “basic hygiene” requirement that becomes a major audit issue when it’s incomplete, out of date, or disconnected from how services are actually delivered. ISO/IEC 20000-1:2018 Clause 8.2.4 is specific: you need one or more service catalogues that include service names, descriptions, owners, service levels, supporting services, and status, and you must make the catalogue available as documented information to appropriate parties. ¹

For a Compliance Officer, CCO, or GRC lead, the work is less about writing a policy and more about making the catalogue operational: assigning accountable owners, forcing consistency in service definitions, and embedding updates into change management so the catalogue stays accurate after reorganizations, platform migrations, and third-party transitions. In practice, the catalogue becomes the control “source of truth” that links service commitments (service levels) to delivery dependencies (supporting services), which is also where third-party risk, continuity planning, incident management, and customer communications converge.

This page translates the requirement into a build-and-run checklist you can execute quickly, with specific artifacts to retain and the exam questions you should expect.

Regulatory text

Requirement (Clause 8.2.4): “The organization shall create and maintain one or more service catalogues that include service names, descriptions, owners, service levels, supporting services, and status. The service catalogue(s) shall be available as documented information to appropriate parties.” ¹

What the operator must do:

1. Create at least one catalogue that covers the services in scope for your service management system.
2. Include the mandatory fields for every service entry:
   • Service name
   • Service description
   • Service owner
   • Service levels
   • Supporting services
   • Status ¹
3. Maintain the catalogue so it stays accurate (not a one-time inventory exercise).
4. Make it available as documented information to “appropriate parties,” meaning the people who need it to request, deliver, support, govern, or consume services. ¹

Plain-English interpretation (what this means in the real world)

You need a single, controlled list of services your organization provides (internally, externally, or both), written in a standard format, with named accountability and clear service commitments. The catalogue must show what each service is, who owns it, what performance/availability/support commitments apply, what other services/components it depends on (including third parties where relevant), and whether it’s active, deprecated, or retired. Then you must publish it to the right audiences in a controlled way and keep it current through operations.

A catalogue that exists in a slide deck or an abandoned wiki page fails the “maintain” test. A catalogue that lists services but omits owners, service levels, dependencies, or status fails the “include” test. ¹

Who it applies to

Entities: Any organization or service provider implementing ISO/IEC 20000-1 service management requirements. ¹

Operational context (where this shows up):

• Internal IT delivering end-user, infrastructure, or platform services to business units.
• External/customer-facing services where the catalogue functions as a service offer, order guide, or customer reference.
• Hybrid environments where services rely on internal teams plus third-party providers (cloud, managed services, SaaS).

If you have multiple lines of service (for example, internal IT and a customer product), multiple catalogues are allowed. Auditors still expect consistent minimum fields and coherent governance across them. ¹

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

1) Define catalogue scope and governance

• Set scope: Which services must be catalogued (all services in the service management scope; avoid “only top-tier services” unless you can justify exclusions).
• Assign an accountable owner for the catalogue process: Usually the service management lead; they own quality control and publishing, not each service’s content.
• Define “appropriate parties” and access model: Examples include service desk, incident/problem/change managers, service owners, relationship managers, and customers where applicable. Document who can view vs. edit. ¹

2) Standardize the service record (minimum required fields + your extensions)

Create a service record template that enforces the required fields:

• Service name: Unique and stable naming convention.
• Description: What outcomes the service provides; what is explicitly out of scope.
• Owner: A role and a named person (or position) with accountability for service definition and performance.
• Service levels: Reference the SLA or service level targets; include support hours where meaningful.
• Supporting services: The upstream/downstream dependencies that enable delivery; include key third parties if they are supporting services in practice.
• Status: Active, in design, deprecated, retired, or similar lifecycle states. ¹

Add optional fields only if you can maintain them (common adds: criticality tier, data classification, major dependencies, recovery expectations). The catalogue fails if it becomes so complex that people stop updating it.

3) Build the initial catalogue from reality, not org charts

• Start from operational signals: service desk categories, monitoring/service maps, customer-facing product list, CMDB service models where they exist.
• Run service-owner workshops: confirm service definitions, boundaries, and dependencies.
• Normalize duplicates: “Email,” “Messaging,” and “O365” may be the same service with different labels. Decide the canonical record and map synonyms in your request portal.

4) Tie catalogue maintenance to change control (this is where most programs fail)

Set explicit triggers that require catalogue updates:

• New service launch
• Material service change (scope, owner, service levels, key dependency change, third-party change)
• Deprecation/retirement
• Major incident postmortem identifying incorrect dependency mapping

Make the catalogue update a required step in your change workflow: the change is not “complete” until the service record is updated and republished.

5) Publish as documented information (controlled, accessible, auditable)

• Choose a system of record: ITSM tool, controlled wiki with versioning, GRC-controlled repository, or service portal catalogue.
• Control editing: limited to service owners and the catalogue process owner; everyone else gets read access appropriate to their role.
• Record version history: preserve evidence of changes to service definitions and service levels over time. ¹

If you use Daydream for compliance operations, treat the catalogue as a governed “control dataset”: you can assign ownership, attach SLAs and dependency evidence, and keep approvals and change history together so audits become document retrieval instead of archaeology.

Required evidence and artifacts to retain

Auditors typically ask for proof of existence, completeness, availability, and maintenance. Keep:

• Service catalogue export or read-only view showing all services and required fields. ¹
• Service record template / data standard (required fields and definitions).
• Ownership evidence: named service owners; RACI for catalogue process.
• Service level references: link each service to its SLA or documented service level targets. ¹
• Dependency mapping evidence: supporting services documented per service entry; where third parties are supporting services, include the referenced third party and the contract/SLA pointer.
• Access and publication evidence: who can view/edit; screenshots or system permissions reports.
• Change history: approval records, change tickets, or version history showing ongoing maintenance.
• Periodic review logs: meeting minutes, review attestations by service owners, or quality checks.

Common exam/audit questions and hangups

Expect questions like:

• “Show me the current service catalogue and how you ensure it stays current.” ¹
• “Pick three services at random; prove the owner is accountable and the service levels are defined.”
• “Where are supporting services captured, and do they match your incident and change records?”
• “Who are the ‘appropriate parties’ and how do they access the catalogue?”
• “What happens when a service is deprecated or replaced; how is status managed?”

Hangups that create findings:

• Catalogue exists but is not treated as documented information (no control, no versioning, unclear access).
• Service levels are listed but not traceable to any SLA/target document.
• Supporting services are vague (“cloud”) and don’t identify the actual internal platform or third party dependency. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Confusing a request portal with a service catalogue

A request portal may list “things you can order,” not “services you deliver.” Fix: ensure every request item maps to a catalogue service, and every catalogue service has the required fields. ¹

Mistake 2: No single accountable service owner

If “the team” owns a service, nobody updates it. Fix: assign a named owner; back them up with a delegate, but keep accountability singular.

Mistake 3: Dependencies don’t include third parties

Teams often stop at internal components. Fix: if a third party is a supporting service in reality (cloud hosting, managed SOC, payment processor), list it as such and point to the governing contract/SLA.

Mistake 4: Status is present but meaningless

Everything is “active” forever. Fix: define lifecycle criteria (what triggers “deprecated” vs. “retired”) and connect them to change control.

Mistake 5: Overbuilding the schema

Adding too many fields makes maintenance impossible. Fix: start with the ISO minimum plus a small set of fields you can sustain; expand only after you see stable upkeep. ¹

Risk implications (why auditors care)

An inaccurate service catalogue drives control failures across service management:

• Incident response delays because support teams can’t identify the real owner or dependency chain.
• SLA breaches and customer disputes because service levels are unclear or inconsistent across documents.
• Third-party risk blind spots because critical external dependencies aren’t recorded as supporting services.
• Change-related outages because changes land in the wrong place due to poor service boundaries.

Clause 8.2.4 is short, but it becomes the backbone for how you prove governance over what you deliver. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Appoint catalogue process owner and confirm scope.
• Choose the system of record and define edit/view access.
• Publish the service record template with required ISO fields. ¹
• Draft naming conventions and status definitions.
• Pilot with a small set of high-visibility services to validate the template and publishing workflow.

Days 31–60 (Near-term)

• Complete first-pass population for in-scope services.
• Validate each service has a named owner and a service level reference.
• Add supporting services mapping for each service; capture key third-party dependencies where applicable.
• Implement change workflow hooks that require catalogue update on service-impacting changes.
• Train service owners and service desk on how to use the catalogue.

Days 61–90 (Operationalize)

• Run a quality review: duplicates, missing fields, unclear descriptions, stale owners.
• Prove maintenance: show updates flowing from recent changes into the catalogue.
• Establish recurring review cadence and owner attestations.
• Prepare an audit packet: export, access control evidence, change history, review logs.
• If using Daydream, centralize evidence links and approvals per service entry so audit requests can be answered with a single service record view.

Frequently Asked Questions

Do we need one catalogue or can we have multiple?

ISO/IEC 20000-1 allows “one or more service catalogues,” so multiple is acceptable if governance is consistent and each service entry includes the required fields. Keep cross-catalogue naming and ownership rules aligned. ¹

What counts as a “supporting service”?

Any internal or external service your service depends on to deliver its outcomes can be a supporting service, including platforms and key third parties. Document the dependency in a way support teams can use during incidents. ¹

Can we reference service levels instead of embedding full SLA language in the catalogue?

Yes. The requirement is that service levels are included; operationally, that can be a pointer to an SLA document or a defined target in your service management repository. Keep the reference stable and auditable. ¹

Who are “appropriate parties” for catalogue availability?

It depends on your operating model, but usually includes service owners, service desk, incident/change/problem managers, and stakeholders who consume or govern services. Document the rationale and control access for sensitive services. ¹

How do we prove the catalogue is “maintained”?

Show a traceable update mechanism: change records tied to catalogue edits, version history, and periodic reviews with service-owner attestations. Auditors want evidence that reality changes and the catalogue follows. ¹

We have a CMDB. Is that enough?

A CMDB can support the catalogue, but it often focuses on configuration items rather than service definitions with owners, service levels, and status. Confirm your CMDB service model explicitly contains the required catalogue fields and is available to appropriate parties as documented information. ¹

Footnotes

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