ISO/IEC 20000-1 scope statement: a worked example (scope services, not departments)

A service management system scoped by department fails the first question an auditor asks. “Which services does your SMS cover?” has an answer. “The IT operations team” is not it.

The scope statement is the shortest document in an ISO/IEC 20000-1 implementation and the one every other document leans on. The service catalogue, the service level agreements, the supplier controls, the audit programme and the management review all inherit its boundary. Get it wrong and you rewrite all of them later. This article shows how to write one, with a worked example from the free SMS Starter Kit for ISO/IEC 20000-1, and ends with a five-question test you can run on your own draft today.

What a scope statement has to say

Clause 4.3 of ISO/IEC 20000-1:2018 asks the organisation to set the boundaries of its service management system and to state its scope in terms of the services it covers and the organisation that provides them. In practice, a scope that holds up answers four questions.

Which services? Name them, exactly as they appear in your service catalogue.

For whom? The customers or service users who receive them: external clients, internal business units, or both.

From where? The locations, sites or platforms the services are delivered from.

By whom? The organisation that runs the SMS, and the other parties involved in delivering those services: suppliers, internal teams outside the SMS, a parent group.

Departments appear nowhere on that list. A department is how you organise people; a service is what a customer receives. One service desk team may support three services, and one service may need five teams. Scope by department and the boundary cuts straight through the middle of your services. This is the most common scope mistake in IT service management (ITSM), and this week’s ISO 20000 Short is about exactly that.

Suppliers and other parties: inside the boundary, under control

The second most common mistake is trying to scope out what a supplier does. If a cloud provider hosts the platform behind a service in scope, that hosting is part of the service. You do not exclude it; you control it. ISO/IEC 20000-1 expects the organisation to keep accountability for the processes and service components that other parties operate (clause 8.2.3 sets out how), so the scope names those parties and the supplier agreements carry the controls.

What you can leave out is a whole service, a customer group or a location, as long as the boundary is clear and the reason is written down. What you cannot leave out is requirements: clauses 4 to 10 apply in full to everything inside the boundary.

A worked example: Falcon Ridge IT Services

Falcon Ridge IT Services is the fictional organisation used across the Brivellis kits: the shared IT services company of a group, serving the group’s business units. Its first draft scope read the way many first drafts do: “The SMS applies to the IT Operations and Service Desk departments.”

Here is a rewrite written for this article from the kit’s worked scope statement (file 01b), which carries Falcon Ridge’s full version:

Read it against the four questions. Services: three, named, with their catalogue IDs. Customers: the group’s business units. Locations: two sites, plus a colocation data centre run by a third party. Other parties: the suppliers, inside the boundary and under control. One exclusion, a whole service, with a reason and a review point.

The kit’s version adds a table of the other parties, each with what it provides and how it is controlled, including an internal team outside the scope; a second, reasoned exclusion; the interfaces with the ISO/IEC 27001 information security management system run alongside; and an annex recording the issues and interested-party requirements the scope takes into account.

Five questions to test your draft

Run these against your own scope statement. Each “no” is a finding waiting to happen.

1. Could a customer read it and know whether their service is covered?
2. Does every service it names appear, with the same name, in the service catalogue?
3. Is every supplier or other party that operates part of a covered service named, with the agreement that controls it?
4. Is every exclusion a whole service, customer group or location, with a reason someone could challenge?
5. Does the management review agenda ask “is the scope still right?”

If the answer to question 2 is no, fix the catalogue or the scope before anything else. Auditors often start at the scope, pick one service and trace it into the catalogue, the service level agreement, the supplier agreement and the incident records. The trace breaks at the first name that does not match.

Where AI helps, and where it must not

An AI assistant is good at turning a list of departments into a first list of services, or at spotting a service name that appears in an SLA but not in the catalogue. It must not decide what is in scope. The boundary is a management decision with contractual consequences, so a named person approves it and the AI-use log records what the assistant drafted. The kit’s prompt pack (05) labels every output DRAFT for that reason.

The free resources

The SMS Starter Kit for ISO/IEC 20000-1 has 17 files built around the Falcon Ridge worked example, including the scope statement and its worked example (01, 01b), the service catalogue in the SMS workbook (04) and the AI prompt pack (05). These free templates need no sign-up. Lessons 2.1 to 2.3 of the free course SMS in Practice: Implementing ISO/IEC 20000-1 walk through the scope, its other parties and exclusions, and the worked example on screen, on YouTube and on Udemy.