Define your ISMS scope by looking at internal and external issues, the needs of interested parties, and the interfaces and dependencies at the edge of your control. Then write down the processes, units, locations and exclusions in scope. Scope follows access to information, not where a device sits.
Start with three inputs
The scope document is short, but the thinking behind it is not. Three inputs shape the boundary:
- Internal and external issues that affect your ability to protect information.
- The needs and expectations of interested parties, such as customers, regulators and partners.
- Interfaces and dependencies between what you control and what others do.
Choosing a scope before you have worked through these is a common early mistake. It usually gets reopened when the auditor asks why a key system is outside the line.
A five step method
- Identify which issues point to areas that must be inside the scope.
- Check whether interested parties can force something in. One example is a privacy law that requires personal data to be covered.
- Look at interfaces and dependencies. Departments that share an office and systems are hard to separate on paper.
- Define exclusions, for example private devices.
- Write the scope document.
Interfaces and dependencies in plain terms
For dependencies, draw the processes inside your scope, then draw the processes supplied from outside. For interfaces, mark the endpoints you control. A router is a typical example: your control ends there and the telecom provider's begins.
What to write down
Record the processes and services in scope, the departments or organisational units, the physical locations, and the exclusions. Floor plans and org charts help, though the standard does not strictly require them. The scope can be a standalone document, part of the information security policy, or a document that points to others.
Two traps for software teams
The first trap is scoping by device location. A laptop that leaves the office is still in scope if it can reach internal systems and sensitive information.
The second is treating cloud as automatically out of scope. One practical guide describes it by service model:
- IaaS: software and data are in scope.
- PaaS: data and application software are in scope.
- SaaS: only your data is in scope.
- Private cloud in your own data centre: facilities, hardware, software and data are in scope.
Your auditor may read this differently, so confirm with your certification body before you fix the wording.
Quick check
Can I leave my production environment out to make certification easier?
You can write any scope you can defend, but customers who ask for the certificate usually expect the systems that hold their data to be inside it. A scope that skips production may not satisfy them.
Is a scope statement mandatory?
Yes. The scope of the ISMS is a mandatory document under clause 4.3.
Sources
Last reviewed: 19 October 2026.
