Clause 4.3 of ISO 27001:2022 requires you to determine the boundaries and applicability of the ISMS to establish its scope. This single document sets the perimeter for everything that follows — every policy, every control, every piece of evidence must relate to something inside the scope boundary.
Scoping is the first major decision in any implementation, and it has consequences that are difficult to reverse. A scope that is too wide creates unnecessary audit exposure and increases implementation cost. A scope that is too narrow may not satisfy enterprise customers who want their specific data environment covered. Getting it right at the start saves months of rework.
What a Scope Statement Must Address (Clause 4.3)
Which services, products, or activities are included in the ISMS
Which locations, offices, or data centres are in scope
Which business units, teams, or functions fall within the boundary
Which IT systems, cloud environments, or networks are included
What is explicitly excluded — with written justification for each
How in-scope systems connect to out-of-scope systems or third parties
What the Standard Actually Requires
Clause 4.3 specifies that when determining scope you must consider: external and internal issues from Clause 4.1 (your operating context), the requirements of interested parties from Clause 4.2 (customers, regulators, staff), and interfaces and dependencies between what you do and what other organisations do.
In practice this means: your scope must be informed by who cares about your information security (customers requiring ISO 27001, regulators like the ICO, GDPR obligations) and what those parties need covered. If your enterprise customers are sending you personal data through a specific platform, that platform and its infrastructure must be in scope — or you must explain convincingly why it is not.
The scope must be documented and retained as documented information. It appears in your SoA, on the certificate issued by the certification body, and is typically published on your website when you display your certification mark.
Scope Statement Examples
A scope statement is typically one to three paragraphs. It should be precise but readable. Here are examples for different organisation types:
SaaS Company (Product Scope)
"The ISMS covers the design, development, operation, and support of [Product Name], a cloud-based [description] platform. The scope includes the production infrastructure hosted on AWS (eu-west-1 and eu-west-2), the development and staging environments, customer support operations, and all staff and contractors with access to customer data. The scope excludes [Partner Company] who provide payment processing services under a separate PCI DSS compliance programme."
Professional Services Firm
"The ISMS covers the provision of [service type] consulting services to enterprise clients, including all project delivery activities, client data handling, and internal supporting systems. The scope includes the London head office, remote working staff, and the IT systems used to store and process client information. It excludes the firm's internal HR systems which do not interact with client data."
Managed Service Provider
"The ISMS covers the management and operation of IT infrastructure services for external clients, including network management, cloud hosting, helpdesk, and security monitoring. The scope includes all three UK office locations, the primary NOC, and all staff and subcontractors involved in service delivery. Client-owned infrastructure is excluded from the scope but subject to agreed security requirements through supplier agreements."
How to Handle Exclusions
You can exclude parts of your organisation from scope — but you cannot exclude an Annex A control simply because it is inconvenient. The standard distinguishes between:
✓ Valid scope exclusions
- — A subsidiary that operates independently with no shared systems
- — A business unit that handles no information assets within your defined scope
- — A location not involved in your defined services
- — Shared services provided by a parent company with their own certification
✗ Not valid as exclusions
- — Annex A controls you find difficult to implement — must be justified in SoA instead
- — Systems that process in-scope data but are inconvenient to certify
- — Third-party developers with access to production — they are an interface, not an exclusion
- — Cloud providers — they are a dependency; your use of them is in scope
When you exclude something, you must document why it is not relevant — for example, that it does not affect your ability to provide information security, or that it is covered by a separate management system. Vague exclusions ("out of scope by business decision") will generate observations in Stage 1.
The Most Common Scoping Mistakes
⚠ Scoping out the production environment
Some companies try to certify their "ISMS" while leaving the actual systems that process customer data out of scope. Certification bodies and enterprise customers will both reject this. If you process customer data on a system, it belongs in scope.
⚠ Forgetting third-party access
If contractors, offshore developers, or outsourced support teams have access to in-scope systems, they are an interface that must be addressed in scope — through supplier controls and agreements, not by pretending they do not exist.
⚠ Not referencing your context analysis
Clause 4.3 explicitly links scope to Clause 4.1 (context) and 4.2 (interested parties). Auditors will verify that your scope was informed by these analyses. Write your scope after you have completed your context analysis, not before.
⚠ A scope so broad it is impossible to evidence
Including "all information across the entire organisation" sounds impressive but creates an audit problem — every system, every office, every process is now fair game. A tighter scope with clear justification is better than an ambitious scope you cannot evidence.
When to Revisit Your Scope
Scope must be reviewed whenever there is a significant change — a new product line, a new data processing activity, a new office, or a change in what customers require. Clause 10.2 of the standard requires continual improvement, and scope changes are one of the triggers for ISMS updates.
Material scope changes after certification require notification to your certification body and may require an additional audit day. Document scope change decisions formally and update your ISMS accordingly.