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:
- Take into account internal and external issues defined in clause 4.1 – this article explains the details: Explanation of ISO 27001:2013 clause 4.1 (Understanding the organization).
- Take into account all the requirements defined in clause 4.2 – this article explains how: How to identify interested parties according to ISO 27001 and ISO 22301.
- Consider interfaces and dependencies between what is happening within the ISMS scope and the outside world.
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:
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 interfaces through 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.
Click here to see a sample of ISMS Scope document.
