Defining the scope for ISO 27001
The scope of your ISMS describes what ISO 27001 applies to: which parts of your organisation, which locations, services and systems. The scope is the first thing the auditor assesses and the basis for everything that follows. A scope that is too broad makes the process unnecessarily complex. A scope that is too narrow produces a certificate that customers do not find convincing. You can buy the standard from NEN , which covers the scope in clause 4.3.
A good scope is logical, defensible and aligned with what your customers expect from you. This article explains how to define the scope, which mistakes to avoid and what a scope statement looks like.
What is the scope of an ISMS?
The scope is the officially documented area of application of your management system. What falls under it, and what does not? ISO 27001 requires you to document the scope and make it available to the auditor and to interested parties.
You determine the scope based on three questions from clause 4 of the standard:
- In what context does the organisation operate? (internal and external factors)
- What do interested parties expect, especially customers?
- Which boundaries are logical given the activities and interfaces?
The scope must include boundaries. State what is inside it and what is outside it. “The ISMS applies to all activities” is not a usable scope. “The ISMS applies to the development and delivery of our SaaS platform, including the related infrastructure and support processes” is.
How do you set the boundaries of the scope?
You can define a scope along four dimensions: locations, services or products, processes and systems. Combine them in the way that suits your organisation.
| Dimension | Example: small IT company | Example: logistics company |
|---|---|---|
| Locations | Office in Amsterdam, remote working environment | Distribution centre in Utrecht, branch in Rotterdam |
| Services/products | SaaS platform for HR software | Transport and storage of goods for third parties |
| Processes | Software development, customer support | Order processing, warehouse management |
| Systems | Production environment in AWS, ticketing system | Warehouse management system, transport planning software |
Scope for the whole company versus one department
You can choose a narrow scope (one product or department) or a broad scope (the whole organisation). Both are valid, as long as they are consistent and defensible.
A narrow scope makes sense if:
- You want to get certified quickly for a specific customer request
- Your organisation has large, complex parts that are not yet ready
- You want to learn from a first certification before expanding
A broad scope makes sense if:
- Customers expect the whole organisation to be certified
- Your information flows cannot be separated cleanly between departments
- You already have a good security level across the whole organisation
What can you exclude?
You may exclude parts, but only if they have no effect on the information security of what is in scope. If you leave customer service out of scope while those staff have access to sensitive customer data that is in scope, that is not defensible. The auditor tests this critically.
Examples of scope statements
The table gives scope statements for different types of organisation. Use them as inspiration, not as a template.
| Type of organisation | Example scope statement |
|---|---|
| SaaS company (15 FTE) | “The scope covers the development, testing and delivery of the cloud platform, including the supporting infrastructure in AWS eu-west-1 and the related support processes.” |
| IT service provider (60 FTE) | “The scope covers all managed services delivered from the Amsterdam office and the production environment in Azure, excluding internal HR and financial administration.” |
| Accountancy firm (30 FTE) | “The scope covers the processing and storage of client data for audit and advisory services, including the related digital workplaces and cloud storage.” |
| Manufacturing company (200 FTE) | “The scope covers the IT infrastructure of the Operations department and the production systems connected to it at the Tilburg site, excluding the Den Haag office location.” |
Common mistakes with the scope
Starting too broad
A scope that covers “the whole organisation” while you are just starting is ambitious but risky. Every department, system and location then falls within scope. This increases complexity and costs dramatically.
Ignoring logical boundaries
The scope must be logical. If customer service staff process customer data but customer service is “out of scope”, the auditor will ask how you guarantee the security of that data. You cannot point to your ISMS, because it does not apply to that department.
Ignoring interfaces
Systems and processes connect to systems and processes outside the scope. How do you secure that boundary? If your cloud platform is in scope but the VPN connection to it is not, how do you protect access? Describe these interfaces in your scope document.
Not keeping the scope up to date
You start with a scope for a specific platform. Two years later you have launched a new product and completed a takeover. The scope still describes the situation from two years ago. The auditor finds that the scope no longer matches reality.
Review your scope after every significant change in the organisation. A takeover, a new product or a move can be reasons to update the scope.
Documenting interfaces and exclusions
ISO 27001 requires you to describe interfaces (boundaries with the outside world) and exclusions in the scope document. These are the points where information enters or leaves the scope.
Typical interfaces:
- Suppliers that have access to systems in scope
- Customers that supply data to systems in scope
- Systems outside the scope that exchange data with systems in scope
For each interface, briefly describe how you ensure security. Use the measures from your risk assessment and refer to the relevant policy or procedure.
Defining the scope and the step-by-step plan
You set the scope in phase 1 of the implementation project, before you start the baseline measurement and gap analysis. Without a defined scope you do not know which processes, systems and risks fall within it, and therefore you also do not know what gap exists with the standard.
Do not change the scope carelessly once the project is under way. Extending the scope halfway through increases the workload and can mean restarting the gap analysis.
More information
- Requirements of the standard: clause 4.3 on the scope
- Baseline measurement and gap analysis: follows directly after the scope
- Step-by-step plan: the scope in the overall project
- Risk assessment: you determine risks within the scope
- The ISMS: the scope as the starting point of the ISMS
- ISO/IEC 27001:2022 : clause 4.3 (ISO.org)