One question that we are asked above everything else is how to define ISO 27001 scope correctly. While defining the scope may seem simple at first glance, especially if you understand the business and have consulted all stakeholders, it can cause a lot of questions and concerns.
So let’s take a look at common ISO 27001 scoping problems, how to approach defining the ISO 27001 scope and example ISO 27001 scoping statements.
ISO 27001 Scope Problems
Problems with defining the scope for ISO 27001 are primarily caused due to the nature of modern day businesses. As all organisations must interact with the outside world for one reason or another, drawing the line on what is under
the control of the management system and what is outside of it can sometimes be tricky.
As an example, imagine you operate a research company that runs from one location. While the scope may initially seem simple as you want to cover your operations from that location, it begins to get more tricky when you start to consider third parties, contractors, suppliers, temporary/permanent staff, customers and employees you deal with. Of course, this then begins to become even more complicated if you decide to scope your management system around one department within the business – the question that may keep coming up is where do we draw the line?
In ISO 27001, these complications of scope are referred to as boundaries and interfaces and must be defined as part
of the scope under ISO 27001:2013. Boundaries, as the name suggests, refers to where the scope ends and what is not included within the management system scope.
This may include a physical location or other logical/business unit that is not being included. Interfaces, again as the name suggests, refers to those entities that are out of scope but that the system relies on as part of its activities. For example, this may include HR that provide services to the entities within scope of the management system.
How to define ISO 27001 Scope
So, what is the best approach when defining the ISO 27001 scope? Should you include the entire organisation, or is it best to scope it around individual business units or locations? And what are the rules regarding how you scope the management system?
Well, firstly, the scoping of the management system should be informed by the requirements of relevant parties. For example, if the requirement for ISO 27001 has come from the need to protect customer data then all locations (both
physical and logical) where that customer data resides should be included. Similarly, all personnel that have access to or process that customer data should be included. It is always advisable to understand exactly where information that requires protection is when defining the scope for ISO 27001. This can be achieved through simple data flow diagrams and by gaining a full understanding of the business. An example of this is shown below:
Using diagrams such as the above can support the organisation is starting to understand the scope, and relevant boundaries/interfaces with the outside world (or rest of the business). These should be defined, documented,
understood and signed off by management. The scoping document should include a scoping statement defining exactly what is in and outside of scope, and should consider the internal/external issues identified as part of the ISMS.
What can be included/excluded from ISO 27001 Scope?
This is a question that only the organisation can answer. Scoping around the entire organisation within modern businesses is sometimes not practical – you have to remember that the system must be able to successfully govern a set of policies, procedures and security practices which would be difficult to achieve for a large organisation. For smaller organisations with limited locations, this could be a feasible approach in which case the scope becomes easier to define.
For larger organisations, where scoping around the entire business is not possible from a cost and effort perspective, scoping around a specific business unit or process would be a recommended approach. Those business units that are more independent i.e. have less interactions with the rest of the business or externals, are generally
easier to contain as boundaries and interfaces are easier to define. When scoping around a specific business unit, the rest of the business must be treated as an interface – even though they are sometimes contained within the same physical location! It is important to keep the reason you are doing this at the back of your mind – to protect information. If the information you are trying to protect is within your business unit only, you must be able to demonstrate that controls are in place to protect it from personnel outside of this scope – including internal employees!
However the scope is defined, this must be made clear through the scoping statement. The scoping statement describes the management system scope in a short, succinct paragraph and specifies those entities that are explicitly
within/outside of scope. So let’s look at ISO 27001 scope examples:
ISO 27001 Scope Examples
We have now looked at how to define ISO 27001 scope, and looked at what should or shouldn’t be included. Let’s finish this article by looking at a few ISO 27001 scope examples.
1. The Information Security Management System (ISMS) applies to the control of our entire business, premises and
resources from the UK. Premises and resources outside of the UK are excluded from the ISMS scope. The ISMS shall be operated in accordance with the Statement of Applicability version x.xx dated xx/xx/xxxx.
2. The ISMS is scoped to include all business processes conducted by the IT department at XYZ motors. All other
business units are excluded from scope. The ISMS shall be operated in accordance with the Statement of Applicability version x.xx dated xx/xx/xxxx.
3. The ISMS shall protect the confidentiality, integrity and availability of XYZ motors customer data at all times
while in UK offices. This includes IT department, call centres and XYZ office locations. The ISMS shall be operated in accordance with the Statement of Applicability version x.xx dated xx/xx/xxxx.
Conclusion
So that is how to define ISO 27001 scope effectively and efficiently. The scope must be available as documented information and reviewed periodically in line with business changes. While it can be tempting to rush through scope definition and you may feel you already know exactly how it will be scoped, it is imperative that the business
considers all aspects of the scope including boundaries, dependencies and interfaces. Ensuring all parties are aware of what is included/excluded from scope enables a focus for implementation and on-going measurement so communicating the scope to all parties is also imperative.
