The ISMS scope is the boundary of what you certify: which services, teams, locations and systems the management system governs. Clause 4.3 requires you to set it from the issues and interested parties identified in clauses 4.1 and 4.2 and from the interfaces and dependencies with everything outside it, and to keep it as documented information. It is examined at Stage 1 and printed on the certificate as the scope statement that buyers read. A good scope is specific about the service and the sites, excludes nothing a customer would assume is included, and names the dependencies it inherits, such as the cloud provider. Scope can be widened at a later audit, so a narrow, honest first scope is normal.
Scope is the first decision in an ISO 27001 programme and the one most often revisited after the certificate exists, because buyers read it. This article covers what clause 4.3 requires, how to decide what is in, how to write the statement, and the traps on both sides of the table.
What clause 4.3 requires
The organisation determines the boundaries and applicability of the ISMS to establish its scope, considering 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 activities it performs and those performed by other organisations. The scope is kept as documented information. That is the whole clause; the judgement is in applying it.
Deciding what is in
- Services and products: the ones customers and regulators ask about. One product is a legitimate first scope.
- Organisational units and people: the teams that build, run and support those services, and the management above them. Everyone inside is interviewed and trained; everyone outside is an interface.
- Locations: offices, data centres, home working where it is the norm. Each site inside the scope is subject to the physical controls and to audit sampling.
- Systems and information: the platforms, repositories, identity systems and data that the services depend on, which the asset inventory then lists.
- Suppliers and shared services: outside the scope, but their interfaces inside it: what you receive, what you rely on, and how you control the boundary.
Interfaces and dependencies
Most scope problems are boundary problems. A cloud provider hosts the service but is not in your ISMS; the interface is the shared-responsibility model, the provider's own certification and the controls you run on top, documented under A.5.23. A group IT function runs the identity provider; the interface is the agreement that defines what they do and the evidence they give you. A contractor develops a module; the interface is A.8.30 and the contract. Each dependency is named in the scope document with how it is controlled, so the auditor sees a boundary rather than a gap.
Writing the scope statement
| Scope statement | What a buyer learns | The problem |
|---|---|---|
| "Information security management at Example AB." | Nothing about which services, sites or systems are covered | Too vague to assess; auditors push back, buyers ask again |
| "The development, hosting and support of the Example platform for business customers, delivered from the Stockholm office and cloud infrastructure in the EU, in accordance with the Statement of Applicability version 3.1." | The product, the activities, the location, the hosting region and the control set | None; this is the shape to aim for |
| "The IT operations department of Example AB." | That the product teams, and therefore the product, are outside the scope | The service the buyer purchases is not covered, however good the certificate looks |
| "All information assets of Example Group worldwide." | Everything, apparently | If the audit sampled one site and one business, the statement overstates what was tested; reputable bodies will not issue it |
Scope traps buyers check
- The service they buy is not named, or a sister entity holds the certificate.
- The location that delivers the service, such as a support centre in another country, is not in the scope.
- The certificate references a Statement of Applicability version older than the one in use, or none at all.
- The scope covers a department rather than a service, which usually means the product is outside it.
- The certificate has lapsed or is suspended, which the certification body or IAF CertSearch can confirm.
Write your own scope so that each of those checks passes, because the buyer's security reviewer runs them in that order.
Changing the scope later
A scope extension, adding a product, a site or a team, is assessed by the certification body at a surveillance audit or a special visit, with audit time added for the new areas, and the certificate is reissued with the new statement. A reduction happens at your request or when part of the scope persistently fails the requirements. Because extension is routine, the first scope should be what customers need now, not everything the company might ever do.
Scope and the Statement of Applicability
The two documents are read together. A control excluded in the Statement of Applicability because there are no premises needs a scope document that says the sites are serviced or the data centre is the provider's. A scope that includes a second office needs the physical controls applied there. When either changes, check the other. The checklist places the scope first for that reason, and the startup article shows what a narrow first scope looks like in practice.