The ISMS scope statement is one of the first documents you need to produce when implementing ISO 27001 — and one of the most consequential. Get it right and your certification effort stays focused and proportionate. Get it wrong and you either spend the next year trying to certify things that did not need to be certified, or you discover during your Stage 1 audit that key services and processes are not included and the scope needs to be rewritten.
Clause 4.3 of ISO 27001 requires organisations to determine the boundaries and applicability of the ISMS in order to establish its scope. The standard’s language is deliberately broad — it does not prescribe a scope format or tell you how large or small your scope should be. What it does require is that the scope is documented and that certain factors are taken into account when defining it. This guide explains what those factors are and how to produce a scope statement that is accurate, defensible, and useful.
What the Standard Actually Requires
Clause 4.3 states that when determining the scope of the ISMS, the organisation shall consider:
- The external and internal issues referred to in Clause 4.1 (the context of the organisation)
- The requirements of interested parties referred to in Clause 4.2 (stakeholders and their expectations)
- Interfaces and dependencies between activities performed by the organisation and those performed by other organisations
This is a much richer set of considerations than “list the systems that are in scope”. The scope must be defined in the context of your operating environment, your stakeholder obligations, and the real boundaries of where your information security decisions apply.
The standard also requires that when any requirement within the standard can be applied, it must be applied — and if anything is excluded from scope, that exclusion must be justified. You cannot simply exclude parts of your business to make the audit easier without a credible rationale.
Understanding Scope Boundaries
Before writing your scope statement, you need to understand what “scope” actually means in this context.
ISMS Scope: What's In, What's Out, and What Must Be Managed
Clause 4.3 requires you to define boundaries and consider interfaces with activities outside the scope
Organisational boundaries
Which parts of the organisation are within scope? For a company pursuing certification for its entire operation, the answer is all departments and all locations. For a company seeking certification for a specific division or service line, the scope may be limited to that part of the business — but only if meaningful boundaries can be drawn around it.
Organisational scope exclusions are legitimate where different business units genuinely operate independently. They are not legitimate where the excluded parts share infrastructure, systems, data, or people with the in-scope parts in ways that affect information security. If your finance team is excluded from scope but the in-scope teams rely on finance-operated systems, the exclusion will not hold up to scrutiny.
Physical boundaries
Which physical locations, offices, or data centres fall within scope? A company with multiple offices may include all of them, or may limit scope to headquarters and specific sites where relevant processing occurs. Cloud-hosted infrastructure may not have a physical location per se, but the service provider and your contractual relationship with them are within scope considerations.
Technology and systems boundaries
Which information systems, applications, and infrastructure are covered? This does not mean listing every system individually in the scope statement — that creates a maintenance burden every time a system changes. It means defining the category of systems clearly enough that there is no ambiguity about what is in and what is out.
Service and process boundaries
What business processes and services does the ISMS cover? This is particularly relevant for organisations pursuing certification for a specific service (such as a SaaS platform or managed IT service) rather than for the whole business.
Writing the Scope Statement
A good scope statement does three things: it defines what is included, it defines what is excluded (and why), and it accurately reflects the actual operating environment. It should be specific enough to be meaningful, but not so granular that it needs updating every time a system or process changes.
Most scope statements cover the following elements:
The organisation and its activities. A brief description of what the organisation does and the primary purpose of the ISMS.
The locations covered. The physical and/or geographic locations included within scope.
The systems, services, or processes covered. The category of information processing activities or services covered.
Explicit exclusions (if any) and their justification. If parts of the organisation or specific activities are excluded, these should be named and the rationale for exclusion given.
Example scope statements
Example 1 — Full organisational scope (SME):
The ISMS covers all information security activities of Acme Technologies Ltd in support of its software development, managed IT services, and internal business operations. The scope includes all staff, contractors, and third-party suppliers who process or have access to Acme’s information assets. Physical locations: Acme’s principal office at [address]. Cloud infrastructure: Microsoft Azure (UK South region) and Microsoft 365 tenancy. No activities are excluded from scope.
Example 2 — Service-specific scope:
The ISMS covers the design, development, hosting, and support of the ClientPortal SaaS platform, operated by Acme Technologies Ltd. The scope includes the ClientPortal development team, operations team, and support team, and the cloud infrastructure supporting the service (AWS eu-west-1). Business functions not involved in the ClientPortal service — including the internal finance and HR systems and the separate Legacy Support division — are outside the scope of this ISMS.
Example 3 — Managed service provider:
The ISMS encompasses the information security management of Netcore IT Services Ltd’s managed IT support and security monitoring services, delivered to external clients. The scope includes all personnel involved in service delivery, the network operations centre at [address], and supporting infrastructure. Sales and marketing activities are outside the scope of this ISMS.
ISMS Scope Statement: What Good Looks Like
The most common scoping errors — and how to fix them
Common Scoping Mistakes
Scoping too broadly without the evidence to support it
Claiming a full organisational scope when large parts of the business genuinely have minimal information security relevance creates pressure to document and evidence controls across a much larger footprint than necessary. Broader scope means more controls to evidence at audit.
Scoping out critical interfaces
Excluding a business function that provides shared services (IT infrastructure, HR systems, cloud platforms) to the in-scope part of the business is a common and problematic mistake. If those shared services affect the confidentiality, integrity, or availability of information within scope, they cannot simply be excluded.
Writing a scope that doesn’t match reality
The scope statement should accurately describe how the business actually operates. A scope written to sound impressive — or written at implementation and not updated as the business grows — that does not match the organisation an auditor walks into is a finding. Scopes get reviewed at every audit visit.
Using vague language that creates ambiguity
“All information systems” is too vague. “The customer data platform and associated administrative tools” is specific. Vague scope language means uncertainty about what is in and what is out — which creates audit risk in both directions.
Treating scope as permanent
Your scope should be reviewed as part of your regular ISMS review process. As the organisation changes — new services, new locations, acquisitions, outsourcing decisions — the scope may need to be updated to reflect the new boundaries.
Interfaces and Dependencies
One of the most commonly overlooked scoping requirements is the obligation to consider interfaces and dependencies between in-scope activities and activities outside the scope. This does not mean everything a third party does must be in scope — it means the interfaces need to be managed.
If your in-scope service relies on a cloud provider for hosting, the cloud provider is not in scope, but the contractual and security controls governing that interface are within scope. You need to demonstrate that you have assessed the supplier, have appropriate contractual clauses in place, and review the relationship at appropriate intervals.
Clause 4.3 requires that dependencies are considered when drawing the scope boundary — not just ignored because they are performed by external parties.
The Scope Statement and Your SoA
Your scope statement connects directly to your Statement of Applicability.
The SoA must address all 93 Annex A controls and justify their applicability (or non-applicability) in the context of your scope.
Controls that are not applicable typically rely on a scoping argument — for example, physical security controls for a second site may be inapplicable if that site is excluded from scope.
The SoA and scope statement should be consistent. Discrepancies — controls marked inapplicable in the SoA but covering areas within scope, or vice versa — are a finding.
What Auditors Look For
At the Stage 1 audit, the scope statement is one of the primary documents reviewed. Auditors are assessing whether:
The scope is realistic. A very narrow scope for a business with a large information footprint will prompt questions about whether important processes have been improperly excluded.
Exclusions are credible. Any parts of the business excluded from scope need a rationale that makes sense. “We didn’t want to include it” is not a credible justification. “This division operates entirely independently with its own systems and staff and shares no information assets with the in-scope operations” is.
The scope matches observable reality. If the scope says two locations and the auditor finds staff at a third processing in-scope data, the scope is inaccurate.
Interfaces are addressed. Key dependencies on third parties, cloud providers, and outsourced functions should be reflected in the scope statement or clearly managed through supplier controls.
Common Mistakes
Writing the scope for what you wish was true, not what is. Aspirational scope statements — covering things you plan to include but have not yet implemented controls for — create gaps at audit. Define scope based on what the ISMS actually covers today.
Changing the scope mid-certification without re-evaluating controls. Scope changes require re-evaluation of which controls apply. Adding a new location or service to scope after implementation without reviewing whether the existing controls extend appropriately is a risk.
Copying scope language from a template without customising it. Generic scope statements that clearly do not describe the actual organisation undermine credibility. Auditors read a lot of scope statements — a generic one is immediately obvious.
FAQs
Can we scope out certain departments to make certification easier?
Yes, but only if those departments can be genuinely separated from the in-scope operations without creating unmanaged interfaces. If your excluded HR department manages identity and access for in-scope systems, the exclusion is not sustainable. Partial scoping works best where a distinct division, service line, or entity can be separated cleanly.
Does the scope statement need to be a standalone document?
It can be embedded in another document — a broader ISMS Policy document, for example — or maintained as a standalone document. What matters is that it is explicitly documented, clearly worded, and available for review. Most organisations maintain it as a short standalone document for convenience at audit.
How long should the scope statement be?
There is no prescribed length. Most effective scope statements are one to two paragraphs — specific enough to be meaningful, concise enough to be read. A very lengthy scope statement often indicates uncertainty about what should or should not be included.
What is the difference between the ISMS scope and the scope of certification?
They are typically the same, but can differ. The ISMS scope defines what the ISMS covers internally. The scope of certification is what your certification body will attest to on your certificate. Some organisations maintain a broader internal ISMS scope but certify only part of it — though this is less common and requires careful management.
Do cloud services need to be listed in the scope?
Not individually, but the categories of cloud services used to process in-scope information should be reflected. Saying “the ISMS covers operations supported by cloud infrastructure including [provider names]” or referring to a separate asset/system register is reasonable. Listing every cloud service in the scope statement creates unnecessary maintenance overhead.
