ISO/IEC 20000:2018 Scope Formulation: Tips and Tricks

Having an ISO certificate on a company wall is always a matter of pride. You know, the show-off client facing rooms where present and future clients are received as part of the corporate enchantment. A wall full of formally looking framed one pagers with the appropriately illustrious stamps and signatures. “We have ISO this-and-that” is a company jargon. In fact, it is nothing but a popular expression. 

Behind it we have something else: there is nothing like “an overall ISO certified company”.

When you certify something, you certify a certain scope.

In a nutshell, the essential part of your processes, activities, business units, whatever, which is actually compliant with the requirements of s certain standard. And note that with the process management systems standards such as the most popular ISO 9001 (Quality Management Systems), including also ISO/IEC 20000 (Service Management Systems - SMS), we actually look to certify processes that do something for your clients. Not products or tools.

And with ISO/IEC 20000's 2018 release things have changed a tiny bit with regards to definition of a certification scope. A good definition of a certification scope can save you many troubles. Or the other way round - a bad scope definition can be a huge stopper to a certification project. Or even can miss entirely the intended benefit. Usually we certify because certain clients want us to. Well, if we do not certify the proper scope, then a certificate is meaningless. 

But how do we approach the scoping exercise?

The ISO standards can be a funny thing in case you have taste for abstractions.

In some aspects they can be quite rigorous (hence the impression of being a bureaucracy overkill); in other, however, they could be quite allowing. This is on purpose - a certain ISO standard framework defines only the essential components of a process management system while giving space for multiple business setups to certify.

You might be a small IT department in a provincial university serving mainly internal clients (other departments, academic staff and students), where everything is done by the proverbial one man show type of a guy. You might be an IT team of a supermarket chain doing maintenance of ERPs and logistics software, at the same time renting infrastructure from a third party supplier. You might also be a huge IT outsourcing giant running IT services and maintenance of IT infrastructure for an airplane/financial/insurance/whatever company which would not like to bear the risks of handling IT on its own. You might be an IT cloud services provider buying cloud infra services on which you build and run financial applications for your customers. Or a printing products maintenance entity, selling and maintaining printer hardware across the globe. 

Scenarios seem to be endless and hence proper definition of certified scope looms essential. 

Let’s take a look into the previous version of the standard, the one from 2011. 

Yes, until 2018 this was the certifiable version. Business wise, things have changed a lot since. The ISO organization is like a dinosaur sometimes - they have a period of mandatory cycle of review of the ISO standards, say, every 5 years we are to expect a new release. But for the IT services domain 5 years might be a lot of time. Moreover, the ISO organization is releasing stuff like the Annex SL. Have you heard about it? No, I assume. But it was a substantial game changer in the area - a meta-standard that defines a common skeleton for all subsequent ISO standards. This was not the case. Each of them was a very distinct animal species, if we use a zoology metaphor, just like my favorite Aristotle. He was obsessed with zoology, you know, especially the hidden life of bees.

Now the ISO animal species have been forcefully converged

All ISO standards from Clause 4 through to Clause 7 have a common structure. That makes a lot easier to integrate different certified management systems. 

Well, with ISO/IEC 20000 from 2011 this was not the case until the 2018 release.

Scope there, we used to read (and memorize it almost by heart, like a Qur’anic hafiz), was defined as follows within Clause 4.5 (“Establish and Improve the SMS"):

4.5.1 Define scope

4.5.1 The service provider shall define and include the scope of the SMS in the service management plan. 

4.5.1 The scope shall be defined by the name of the organizational unit providing the services, and the services to be delivered.

4.5.1 The service provider shall also take into consideration other factors affecting the services to be delivered including: 

a) geographical location(s) from which the service provider delivers the services; 

b) the customer and their location(s); 

c) technology used to provide the services.

Ok. Let’s summarize 

In the 2011 version with which we worked for many years in the IT Service Management domain, it was mandatory that the scope is defined (written down, formulated clearly, articulated) not only on the first page of certificate that you gain and eventually show to customers but also appears into the so-called "Service Management Plan". You know, the backbone of your Service Management System. It is one of the few mandatory documents within this standard. As I said, ISO standards can be quite permissive - you can maintain whatever document you need. A toilet visitation procedure. An instruction of what T-Shirts employees are allowed and not allowed to. A guidance on “how not to reboot the server every day because of the janitor cleaning the office”. Whatever. 

But ISO/IEC 20000 mandates the existence of few absolutely shall-have documentation deliverables - and one of them is the Service Management Plan. The primary guidance of how you implement and operate your SMS/ITIL processes.

Well, the scope shall be part of it. There all starts.

Now. The mandatory components for a formulation of scope, we knew, are:

1. The name of the organizational unit providing the services, and the 
2. Services to be delivered.

That name might be documented through a couple of approaches. For sure, we have the name of the legal entity of a company on the front page of the certificate appearing through a formally registered address, say, the headquarters of it. Then, in addition to this, we can take another approach to refine the scope by including the “organization unit” internal to a company - bear in mind sometimes we certify only a certain department in a company which might not be an IT company at all. E.g. “The IT Service Excellence [put whatever org unit there to undergo certification] Organization of Company X”.

And then, the high level definition of services is a second must. Try to be succinct and precise. You might be a huge infra services provider. Or a big telecom. But in fact, only a part of your IT services might be in the certified scope - say, the data storage and back-up. Or only IT services management processes provided as a service to your customer. Or only the monitoring and remote maintenance for a certain type of product. Business need is king here: if you stay too broad, this will explode your initial certification project and drag you into non-desired investment without a guarantee of success. If you stay too narrow, on the other hand, in case you change your services offering, you would have to undergo communication and change of certification scope surveillance audit and activities with your Certification Body. 

Now these were the mandatory elements, remember - company name plus main address, then org unit name (might be the same as the company or internal business unit name), and services description. 

There is a disclaimer that sometimes allows for your flexibility - many companies would not like to live a life of such a service restriction and often add the generic “services as per the latest version of the Service Catalogue”. Yes, a Service Catalogue was (and still is) a mandatory document describing the services of a certain organization and allowed (and still allows) for space to manoeuvre.

Additionally, the 2011 version included several other “considerations”

These were the geographical locations from which your certified entity delivers the services - yes, the ISO/IEC 20000 is still based on locations!, also locations of your customers and technology used to deliver the services. Now, all these, the norm used to postulate, were not mandatory to be included in the actual formulation. But one of the first things you for a certification project to consider, is still the breakdown of locations from which you deliver your IT services. Say, hypothetically, that we are a small IT services company, we have a management team of 3 people in Berlin, Germany, we have a Data Center in Frankfurt, Germany, staffed by 10 people, we deliver onsite IT infra support to Client X in London, UK, by 3 field engineers, and our Call Center service desk is in Sofia, Bulgaria where we have 2 people. 

This already gives a structure of the future certificate, even without explicitly listing it in the scope. Some companies play safe and restrictive on this part as well, listing the locations from where they deliver IT services.

For example look at Dell’s certified scope below:

The service management system supporting the provision of Application maintenance, support and monitoring services to its customers and shared services operating from its Bangalore and Noida locations, India.

Or others who include in the scope in indication of their customers, say UKCloud Ltd (“public sector clients”):

The UKCloud IT service management system supporting the provision of management and operation of UK based cloud services (Infrastructure as a Service, Software as a Service, Platform as a Service) provided to public sector clients for the hosting of their information.

That automatically means that in case the company IT services start delivering to something different than public sector clients, it would need to be negotiated by the certification body, as long as all scopes are agreed with the company that is supposed to audit you, in advance. After all, the scope also defines what will be examined by those who provide the certificate to you after the assessment audit. 

Now, there is a further way to refine scope and drill down in a more detailed manner. As we see, a scope is defined by:

1. Name - mandatory;
2. Services - mandatory;
3. Locations (of service provider and customer) and technology - optional for the very scope formulation, a must to be considered, though.

This goes to the one pager. 

But a certificate is much more than that

Usually on the next pages of it contains a list of: 

1. Locations breakdown and the 
2. “Registered activities” associated with them.

In our hypothetical example above we might have the 4 locations (Berlin, Frankfurt, London, Sofia), as to each of them we describe the “registered activities” - might be in the form of business processes, functions or even services. E.g. “Berlin - Governance of IT services, Financial and Procurement services”, “Frankfurt - Data center services and maintenance of critical applications” etc.

This detailed information of the various certified entities, locations and activities is not what you officially display but is essential part of the certificate, and might be requested or made available, as per one’s business needs, security restrictions and clients’ requirements. This also serves as the auditable base of your organization throughout the usual 3 years’ certificate validity life cycle. 

And what about 3rd parties, do they show on the scope formulation?

In short - absolutely not. 

And managing 3rd parties is essential for ISO/IEC 20000. Practically, you can have all but the management processes for an IT Service Management System, or parts of them, delivered by other parties. In terms of the 2011 and the 2018 versions these other parties are three: an internal unit (say, a financial department outside of the certified scope), a supplier (say, a provider of copd infra on which we run our apps), or even a client (e.g. a call center owned and managed by the client as entry point to us). 

Regardless of who that other party is, says the 2018 version, and regardless of what process they operate, we as the certifiable service provider, need to demonstrate that we are accountable for these processes, part of processes or operations. We cannot certify what we do not own, or processes that we are not able to control and be held accountable for. That is why our third parties are subject to the requirements of clauses such as the ones relating to Service Level Management (if they are an internal group) or Suppliers’ Management (in case of Suppliers). 

Now for ISO/IEC 20000:2018: how have scoping requirements changed?

Broadly said - not much. Stay cool. 

What has been formulated as a certifiable scope under the 2011 release, remains a certified and compliant scope formulation under the 2018 version. Take a look, however, at the new requirements below: 

4.3 Determining the scope of the service management system

The organization shall determine the boundaries and applicability of the SMS to establish its scope. When determining this scope, the organization shall consider:

the external and internal issues referred to in 4.1;

the requirements referred to in 4.2;

the services delivered by the organization.

The definition of the scope of the SMS shall include the services in scope and the name of the organization managing and delivering the services.

The scope of the SMS shall be available and be maintained as documented information.

NOTE 1 ISO/IEC 20000-3 provides guidance on scope definition.

NOTE 2 The SMS scope definition states the services which are in scope. This can be all or some of the services delivered by the organization.

The definition, again, is based on the 2 primary components - name of the organization and the services in scope.  

What has changed, is the “shall be considered” components

We have a much more expanded list beyond the 2011 mention of locations (of customer and service provider), and technology. Obviously, there has been a growing understanding that not only locations and technology affect the scope. The 2018 version is making reference to the preceding Clauses of 4.1. and 4.2, respectively “Understanding the organization and its context” and “Understanding the needs and expectations of interested parties”. 

They are much broader than the 2011 version, come as part of the Annex SL unification effort, and stipulate consideration of the “external and internal issues” (both positive and negative impact ones), as well as the “interested parties” and their requirements. 

Again, just as 2011, Part 3 of the ISO/IEC 20000 standard contains guidelines for proper scope definition.

And then, the scope requirements capture the mandatory treatment of the scope definition as a documentation artifact as part of the must have documentation deliverables to be in place for an org. This same requirement is reinforced in the list of all mandatory documents in 7.5.4 (“Service management system documented information”), and curiously enough, was not found in the 2011 version. No need to include it as part of the SM Plan mentioned here, but you shall maintain it as a "documented info" (the expression which appeared in the 2018 version to signify what was previously just "documents").

In case need some more examples of certified scopes, you can take a look at the APMG ISO/IEC 20000 certified bodies register or the one of the British Standards Institution (BSI) directory of certified clients, from where the examples above have been taken.

And good luck with all your scope definitions dilemmas!