Determining the Scope of the Information Security Management System Under ISO 27001

ISO 27001 Clause 4.3

This sub-clause requires the organisation to determine and document the boundaries and applicability of the ISMS - which information, sites and activities are covered.

ISO 27001 Clause 4.3 - Determining the Scope of the Information Security Management System

The scope statement is one of the most read documents in any ISMS. It tells customers, regulators, certification bodies and staff exactly what the management system covers. Get it right and the rest of the system has clear boundaries. Get it wrong and the audit gets messy fast.

What ISO 27001 Clause 4.3 Requires

The clause requires the organisation to determine the boundaries and applicability of the ISMS, taking into account the external and internal issues from Clause 4.1, the requirements of interested parties from Clause 4.2, and the interfaces and dependencies between the organisation's activities and those carried out by other organisations. The scope must be available as documented information.

The boundaries can be drawn in several different ways - by site, by business function, by service, by product line, by legal entity, by location, or by some combination of these. What matters is that the boundaries are clear, defensible and traceable to the inputs from 4.1 and 4.2.

Writing a Useful Scope Statement

A good scope statement is short. It identifies the legal entity or entities involved, the services or products covered, the locations included, and any significant exclusions. It does not need to list every system, every process or every control. The detail of what is in and what is out lives in the Statement of Applicability and the supporting documentation.

The scope statement also needs to recognise the interfaces and dependencies on other organisations. If the organisation runs its email and file storage on a cloud platform, that platform sits at the edge of the scope. The scope statement does not put the cloud provider inside the ISMS, but it does need to acknowledge the dependency, which is then managed through the supplier controls.

What Goes Inside Versus Outside the Scope

Excluding parts of the organisation from the scope is allowed, but the exclusions need to make sense. Carving out a department or location to avoid difficult work is not a defensible exclusion. Carving out an entirely separate business that runs on different systems and serves different customers might be. The test is whether the exclusion makes the management system clearer and more focused, or whether it just hides things.

Where parts of the organisation are excluded, the scope statement is explicit about what is excluded and why. Customers and certification bodies will look at this carefully because it tells them what the certificate actually covers.

The scope statement is the first thing I read. It tells me what I am auditing and what I am not. If the wording is vague or contradicts the rest of the system, the audit slows down. Clear, short, accurate. That is what I want from a scope statement.

If you are starting from scratch, draft the scope wide rather than narrow. Cutting parts out later is easy. Adding parts in later means going back through every register, every risk assessment and every set of records to extend them. A wide initial scope saves rework.

Practical Compliance Guidance

The scope statement usually lives in the IMS1 Integrated Management System Manual, where it sits alongside the policy and the system description. Some organisations also publish the scope statement on their website so customers can see what their certification covers.

The documents below support the scope statement and the manual that holds it.

alphaZ document How to use it
ISO 27001 Toolkit Complete documentation set including the IMS1 Manual where the scope statement is recorded.
Information Security Management System Manual Template Standalone information security manual template covering scope, structure, roles and the management system overview, for organisations not using the integrated IMS1 manual.

Note - all the above files can be downloaded with an alphaZ subscription.

Frequently Asked Questions

Yes. The scope can cover a single business unit, a single site, a single service or a single product line. The boundaries need to be clearly drawn and the exclusions need to be defensible. Customers and certification bodies pay close attention to what is excluded.
A few sentences in most cases. The scope statement identifies the entity, the services or products, the locations and any exclusions. The detailed description of what is in and what is out belongs in the Statement of Applicability and the supporting documentation.
Outside the scope of the organisation's own ISMS, but treated as an interface and a dependency. The scope statement acknowledges the dependency, the supplier controls assess and manage the risk, and the cloud provider's own certifications are normally relied on for evidence of their security arrangements.

UK Legislation

No UK legislation directly prescribes how the scope of an information security management system should be drawn. However, the following typically influence what needs to be inside the scope.

Further Resources

payment logos