ISO 27001 Requirement 4.3 – Determining The Scope Of The ISMS

How to set the scope of the ISMS

The in-scope activity will be much more logical to consider once you have completed the work for 4.1 and 4.2. You’ll probably consider the organisation, subsidiaries, divisions, departments, products, services, physical locations, mobile workers, geographies, systems and processes for your scope as the information assurance and risk assessment work will be following those parts of your organisation that need to be protected.

Remember to also think about what the powerful stakeholder interested parties will expect too. If you did look at leaving any part of the organisation out of scope, what would the impact be for those powerful interested parties? Would you also have to run multiple systems and end up confusing staff about what was in and out of scope in the way they worked?

What parts of the business need to create, access or process the information assets you see as valuable? These would almost certainly need to be in scope if the pressures were driven externally by customers for satisfying their information assurance needs. For example, you might focus on your product development and delivery but would still have to look at the people, processes etc around it too. Also think about what you can and can’t control or influence.

It could be minutes of effort to get this work done or might take considerably longer in a larger enterprise where it can be politically and practically challenging to determine a controllable scope. ISO certification bodies like UKAS are pushing more towards ‘whole organisation’ scope too and powerful customers will generally expect that as well.

How to document ‘out-of-scope’

You should also carefully note the ‘out of scope’ areas for the ISMS too, wrapped up alongside the key interfaces and dependencies between activities performed by the organisation and those that are performed by other organisations. At a simplistic level, let’s imagine you are a software developer and rely on outsourcing of the datacentre for hosting of the service to customers.

You’d probably clarify that the scope for your 4.3 is that within your organisation for the people and the software itself, but would put the boundaries and activities of the data centre out of your controlled scope – after all you would expect them to also maintain their own trusted ISMS.

It is the same for physical property – if there is a reliance on a landlord for certain work (e.g. loading, barriers and reception control) that might form a boundary where the physical location security itself is out of scope for your control and you’d work your ISMS activity within that property. You would however still be expected to manage the supplier as part of your supplier policies in Annex A 15 and ensure their practices at least met the requirements for your ISMS and risk appetite but that’s for another time.

Other points to consider

• Building on the point above, if you did leave parts out of scope, what would the impact be for staff? Would some of their work be in scope and some out of scope? If so are there additional risks and complications where they might confuse practices (say), not protect work, and cause more threat from following two different approaches?
• Are there opportunities to describe things differently e.g. treat some satellite offices as tele/remote workers, not as physical premises or locations in scope?
• Simplifying or constraining scope early could make sense if you can effectively segment the information boundaries and demonstrate the risks are being addressed. However, if you have a goal of adding in something later then keep in mind that a material change in scope might trigger a need for another audit, depending on what, when, how and whether driven by internal goals or external pressures.