ISO 27001/ISO 22301 Knowledge base

Dejan Kosutic

How to define the ISMS scope

Author: Dejan Kosutic

ISMS scope is probably one of the hottest topics since the 2013 revision of ISO 27001 was published, because it introduces some new concepts like interfaces and dependencies. But, when thinking about the scope in a structured way, it is actually not too difficult to set it correctly.

What is the purpose of the ISMS scope?

The main purpose of setting the ISMS (information security management system) scope is to define which information you intend to protect. Therefore, it doesn’t matter whether this information is stored within your company offices, or somewhere in the cloud; it doesn’t matter whether this information is accessed from your local network, or through remote access. The point is that you will be responsible for protecting this information no matter where, how, and by whom this information is accessed.

So, for example, if you have laptops that your employees carry out of your office, this doesn’t mean these laptops are outside of your scope – they should be included in your scope if through these laptops the employees can access your local network and all the sensitive information and services located there.

Of course, the scope is also important if you go for the certification – the certification auditor will check if all the elements of the ISMS work well within your scope; he won’t check the departments or systems that are not included in your scope.

The requirements of ISO 27001 regarding the scope

Basically, ISO 27001 says you have to do the following when defining the scope:

Another thing you should include in your ISMS scope document is a short description of your location (you could use floor plans to describe the perimeter) and organizational units (e.g., org charts) – this is not strictly required by the standard, but certification auditors like to see them included.

ISO 27001 requires you to write a document for the ISMS scope – you can merge this document with some other (e.g., Information security policy), keep it as a separate document, or have one document with references to others (e.g., interested parties and their requirements, context of the organization, etc.).

Now, the key question is how to deal with these interfaces and dependencies.

Interfaces and dependencies

Let’s start with dependencies – it is probably easiest to describe them graphically. You can draw your processes that are included in your ISMS scope, and then outside of this circle draw the processes that are provided from outside of your scope. By processes, I don’t mean only security or IT processes – I mean the main business processes within your scope; if you already implemented ISO 9001, you probably have a similar process chart. Here’s an example:

ISMS process chart

Once you know the dependencies, you have to identify the interfaces. They are important for a company to understand its ISMS boundaries, and to understand which inputs and outputs will be going through these interfaces in order to protect them better.

There are a couple of approaches to identify interfaces:

  • You can try to identify all the end points you control – e.g., in your local network that could be the router (because after that point you usually have no control of the link – the telecom company does), for your offices the interface could be the entrance doors, etc.
  • Perhaps a better approach would be to define high-level characteristics of interfacesthrough these three factors: (1) people, (2) processes, and (3) technology. So, in the example displayed in the above diagram, people in the company A would be all the users of the software, while in the IT company providing software development and maintenance that would be the main software developer; processes would be support (resolving problems with the software bugs) and development of new software functionalities; technology would be Help desk application, email, VPN, FTP, etc.

The biggest myths about the ISMS scope

When setting the scope, you should be careful with these issues:

Smaller scope does not mean an easier job. When leaving some parts of your company out of the scope, this means you have to treat them as an “outside world”: you have to limit their access to the information within the scope, which could create more problems than initially anticipated. Limiting the scope is usually feasible for larger companies, but not for smaller ones – see also this article: Problems with defining the scope in ISO 27001.

Exclusion of controls has nothing to do with the ISMS scope. You cannot say something like “we will exclude controls x, y, and z from the scope because we don’t want them”; you can exclude the controls only if there are no risks nor requirements which would require the implementation of those controls. In other words, if there are risks and/or requirements, you cannot exclude related controls. See also this article: The basic logic of ISO 27001: How does information security work?

Benefits of defining the ISMS scope

The definition of scope might sound complicated, but once you go through this process, you’ll start to appreciate it – not only will you better understand the environment in which your company operates and realize which security requirements you need to fulfill, you will also be able to focus much better on your most sensitive information. This is exactly why you need to define (and document) your ISMS scope before you start writing any other security documents.

To learn more about identifying the ISMS scope see this free ISO 27001 Foundations Online Course.

If you enjoyed this article, subscribe for updates

Improve your knowledge with our free resources on ISO 27001/ISO 22301 standards.

You may unsubscribe at any time.

For more information on what personal data we collect, why we need it, what we do with it, how long we keep it, and what are your rights, see this Privacy Notice.

One response to “How to define the ISMS scope”

  1. Rajat Gupta says:

    I am working in a company which has build one of its business process on AWS IaaS whereas rest is still in traditional datacenter. Can you please help me understand below things.

    1. How the ISMS scope for this process will be changed since the underlying infrastructure is now with AWS and we are building our web applications on top of it.
    2. The IaaS service provider is already ISO 27001 certified then do I need to get that business process ISO 27001 certified as well.
    3. If answer to question 2 is yes then how the risk management exercise will be changed at my company side?
    4. Can this business process alone qualify for ISO 27001 certification?

Leave a Reply

Your email address will not be published. Required fields are marked *



  • Advisera is Exemplar Global Certified TPECS Provider for the IS, QM, EM, TL and AU Competency Units.
  • ITIL® is a registered trade mark of AXELOS Limited. Used under licence of AXELOS Limited. All rights reserved.
  • DNV GL Business Assurance is one of the leading providers of accredited management systems certification.