ISO 27001 scope is the documented boundary that determines what your information security management system governs, what risks you assess, what controls you justify, and what evidence you need to produce. Not just a sentence in an ISMS manual.
A defensible scope is narrow enough to operate, but complete enough to reflect the real products, services, systems, people, locations, suppliers, and dependencies that affect the information you are protecting. The practical task is to make those boundary decisions explicit before you write the final scope statement.
What ISO 27001 Scope Means Under Clause 4.3
ISO/IEC 27001:2022 Clause 4.3 requires an organisation to determine the boundaries and applicability of its ISMS by considering relevant internal and external issues, relevant interested-party requirements, and interfaces and dependencies with activities performed by other organisations. The resulting scope must be maintained as documented information, according to the ISO/IEC 27001:2022 requirements.
In plain language, the scope answers:
- what part of the organisation the ISMS covers
- which products, services, business units, locations, systems, processes, and roles are inside the boundary
- which external or internal dependencies affect that boundary
- what is outside the boundary and why
ISO 27001 does not inherently require the whole legal entity to be inside one ISMS. ISO/IEC JTC 1/SC 27 guidance notes that an ISO/IEC management system may cover only part of a legal entity, so a narrower ISMS boundary can be possible if it still satisfies Clause 4.3 and is not misleading about what is protected or certified.
Scope matters because later ISMS activities depend on it, ISO/IEC 27001 ties information security risk identification to information within the ISMS scope, then requires the organisation to determine necessary controls, compare them with Annex A so controls are not overlooked, and record control inclusion and exclusion decisions in the Statement of Applicability.
Keep two ideas separate:
- ISMS scope exclusions: parts of the organisation, services, systems, locations, or processes outside the ISMS boundary.
- Annex A control exclusions: controls determined not to be necessary after risk treatment and Annex A comparison.
Both need defensible reasoning, but they are not the same decision.
The Decisions You Need to Make Before Drafting the Scope Statement
A strong scope statement is the output of a decision process. If you start by writing a paragraph, you will often end up with wording that sounds clear but is not clear, such as “the cloud platform” or “corporate operations” without knowing what those phrases include.
Before drafting, answer these questions.
ISO 27001 Scope Decision Worksheet
Use this as editorial guidance for a scoping workshop. ISO 27001 requires documented scope; it does not require this worksheet format.
| Decision area | Questions to answer | Scoping implication |
|---|---|---|
| Products and services | Which products or services are customers, regulators, contracts, or other interested parties relying on? | If the assurance need relates to a specific service, the scope should name it clearly. |
| Business units and teams | Which teams build, operate, support, sell, or administer the in-scope service or information? | Include teams whose activities materially affect the ISMS boundary; document limited interfaces for others. |
| Locations and delivery model | Which offices, data centres, remote-working arrangements, or service locations support the in-scope activity? | Avoid location language that is broader or narrower than operational reality. |
| Systems and assets | Which applications, cloud environments, networks, repositories, endpoints, identity systems, and data stores process or protect in-scope information? | Define the supporting environment at a level that supports risk assessment and evidence collection. |
| Processes | Which processes create, access, change, monitor, support, or retire in-scope information or systems? | Include operational and management processes that affect confidentiality, integrity, or availability. |
| People and roles | Which employees, contractors, administrators, support staff, and managers can affect in-scope information? | Include roles by responsibility, not only by department name. |
| Suppliers and outsourced services | Which third parties host, process, support, secure, or administer in-scope information or systems? | Record dependencies and how they are managed through the ISMS. |
| Shared services | Which corporate services — such as HR, finance, legal, procurement, corporate IT, identity, email, or support — affect the in-scope environment? | Do not automatically place the whole function in scope; identify the activities and dependencies that cross the boundary. |
| Evidence availability | Can the organisation produce evidence for what it places inside scope? | Evidence gaps do not by themselves justify exclusion, but they may reveal that the proposed boundary is not yet operationally mature. |
The outcome should be a set of boundary decisions, not just a list. For example, “identity provider included” is less useful than: “The corporate identity provider supports authentication and privileged access for the in-scope SaaS production environment; identity configuration, access review, and joiner-mover-leaver interfaces are included.”
How to Choose a Defensible Boundary: Broad, Narrow, Staged, Product-Only, or Organisation-Wide
Treat the following as practical decision patterns, not official ISO categories. The right boundary depends on your organisational context, interested-party requirements, and real interfaces and dependencies.
| Pattern | When it may fit | Main scoping risk to manage |
|---|---|---|
| Organisation-wide | The whole organisation operates under one coherent ISMS boundary, or external assurance needs apply across the business. | Evidence and control operation may need to cover many teams, processes, locations, and systems. |
| Product-only | Assurance is needed for one product and its supporting environment. | Critical shared services or dependencies may be hidden outside the named product. |
| Service-line | A defined managed service, consulting line, hosting service, or operational function needs certification. | Sales, delivery, support, and supplier boundaries must be clear. |
| Department or business unit | A distinct unit manages its own information, systems, and processes. | Corporate systems and cross-functional processes may still affect the unit. |
| Location-based | A specific site or delivery location is the meaningful operational boundary. | Remote work, centralised systems, and shared services can make a purely physical boundary incomplete. |
| Staged | The organisation starts with a narrower defensible boundary and plans later expansion. | The initial scope must not imply broader coverage than it has, and dependencies must be transparent. |
A broader scope may provide a wider assurance boundary, but it can also increase the practical work of implementing controls, gathering evidence, and maintaining consistency across teams. A narrower scope can be more manageable, but only if it basically reflects how the service is actually delivered and does not obscure important dependencies.
Use these decision criteria:
- Interested-party reliance
What do customers, regulators, contractual commitments, leadership, or other relevant parties actually need assurance over? - Information flow
Where is in-scope information created, received, processed, stored, transmitted, backed up, monitored, and deleted? - Operational control
Which teams can change, administer, support, or disrupt the in-scope service or information? - Shared-service impact
Which shared services materially affect confidentiality, integrity, or availability for the in-scope environment? - External representation
Would the scope wording cause a customer or other reader to believe a product, service, location, or function is covered when it is not? Accredited management-system certificates identify the scope of certification, described by ANAB as the product or service covered, along with the certified organisation’s name and geographic location. - Evidence feasibility
Can the organisation produce evidence for the boundary it claims? If not, either improve the operating model or narrow the boundary honestly; do not use vague wording to hide the gap.
A defensible narrow scope is not one that excludes inconvenient work. It is one that names a real operating boundary, explains its dependencies, and supports risk assessment and control decisions within that boundary.
How to Document Inclusions, Exclusions, Shared Services, and Dependencies
ISO 27001 requires the scope to be documented, but it does not prescribe a specific exclusion log, dependency map, or approval template. Those artifacts are practical ways to make the boundary easier to explain, review, and maintain.
ISO 27001 Scope Definition Pack
Use a lightweight pack around the final statement:
| Artifact | Purpose |
|---|---|
| Scope statement | The formal documented scope paragraph or section. |
| Inclusion list | A structured list of in-scope services, teams, locations, systems, processes, suppliers, and roles. |
| Exclusion rationale log | A record of what is outside the ISMS boundary and why. |
| Interface/dependency map | A view of how in-scope and out-of-scope teams, systems, suppliers, or processes interact. |
| Owner/sign-off record | Evidence of who owns and approved the scope decision. |
| Review/change-control log | A history of scope reviews, changes, rationale, and affected dependencies. |
Document inclusions specifically
Avoid relying on umbrella phrases unless you define them. “The platform” could mean the customer-facing application only, or it could include cloud infrastructure, CI/CD, monitoring, support tooling, backups, identity, and incident management.
A better inclusion entry names the operating components:
The ISMS includes the Acme Analytics SaaS production service, production cloud infrastructure, production data stores, CI/CD pipeline for production releases, monitoring and alerting, customer support processes that access production data, and the engineering and operations roles administering those environments.
Make exclusions specific, justified, and reviewable
Weak exclusions are usually broad labels without boundary logic.
| Weak wording | Stronger illustrative wording |
|---|---|
| “Corporate HR is out of scope.” | “Corporate HR is outside the ISMS boundary except for onboarding, access provisioning, role change, and termination activities that affect access to in-scope systems. Those interface activities are documented in the access management process and reviewed as part of the ISMS.” |
| “Finance systems are excluded.” | “Finance systems are outside the ISMS boundary because they do not process or administer in-scope service information. Any billing exports containing customer contact details are treated as an interface and covered by the data transfer and supplier/access controls defined for the in-scope service.” |
| “The parent company is excluded.” | “The parent company is outside the ISMS boundary except for corporate identity, legal approval, and procurement activities that support in-scope suppliers and access management. These dependencies are recorded in the interface map.” |
These examples are illustrative. Adapt them to your organisation’s context and confirm the approach with a qualified ISO 27001 reviewer or certification body.
Treat shared services as boundary interfaces
A shared function does not have to be treated as fully in scope just because it supports an in-scope service. The better question is: which bits of that function actually affect in-scope information, assets, access, evidence, or risk treatment?
For example:
- HR may affect background checks, onboarding, role changes, and termination.
- Corporate IT may affect endpoints, email, identity, networks, and device management.
- Procurement may affect supplier due diligence and contract flow-downs.
- Legal may affect customer, regulatory, or contractual requirements.
- Finance may affect billing data or customer records.
- Cloud platform teams may affect infrastructure configuration, logging, and availability.
Document the crossing point, owner, process, evidence source, and risk impact. That prevents two common errors: accidentally expanding the ISMS to every corporate function, or excluding a shared dependency that materially affects the in-scope environment.
What a Clause 4.3-Ready Scope Statement Should Include
A useful scope statement is concise, but it should be clear enough for someone outside the project team to understand the boundary. Or, more accurately, it should be clear enough that they can tell what is inside the boundary and what is not. It should usually identify:
- organisation or legal entity
- product, service, function, business unit, or location covered
- delivery model and relevant locations
- key systems, platforms, environments, or information assets
- key processes included
- important internal and external dependencies
- exclusions and where the rationale is documented
- relationship to relevant interested-party requirements, where applicable
- scope owner and approval status, if maintained in the same document
Use this template as a starting point:
The ISMS of [organisation/legal entity] applies to [product/service/business unit/function] delivered from [locations/delivery model], including [key systems, environments, information assets, processes, and roles]. The scope considers relevant internal and external issues, interested-party requirements, and interfaces and dependencies with [key internal/shared services/external suppliers]. Exclusions from the ISMS boundary are documented in [exclusion log/location] with supporting rationale. The scope is owned by [owner] and approved by [approver/body].
The following samples are illustrative only. Adapt them to organisational context and confirm them with your certification body or a qualified reviewer.
Product-only SaaS scope
The ISMS of Acme Software Ltd applies to the Acme Analytics SaaS production service, including its production cloud infrastructure, production data stores, release pipeline for production changes, monitoring, incident management, customer support access to production data, and engineering and operations roles administering the service. The scope includes remote delivery by personnel supporting the service. Interfaces with corporate HR, identity management, procurement, legal, and cloud service providers are documented in the interface and dependency map. Exclusions are recorded in the ISMS exclusion rationale log.
Service-line scope
The ISMS of Acme Managed Services Ltd applies to the managed endpoint monitoring service delivered to contracted customers from the London office and approved remote-working locations. The scope includes service delivery, service desk workflows, monitoring platforms, customer ticket handling, privileged access management, supplier-supported tooling, and management processes required to operate the service. Corporate systems and functions outside this service line are excluded except where documented as dependencies or controlled interfaces.
Department or business-unit scope
The ISMS of Acme Group applies to the Data Platform Business Unit responsible for operating the internal analytics platform and associated data processing environments. The scope includes the business unit’s cloud environments, data ingestion processes, analytics workspaces, platform administration, access management activities, and support processes. Shared corporate identity, HR, procurement, and security operations dependencies are documented as interfaces to the ISMS boundary.
Full-organisation scope
The ISMS of Acme Security Ltd applies to all information security management activities supporting the company’s software development, customer support, corporate operations, and managed service delivery across its approved office and remote-working environments. The scope includes the systems, processes, personnel, suppliers, and management activities used to protect information handled by the organisation. Specific third-party dependencies and any limited exclusions are documented in supporting ISMS scope records.
Staged scope
The initial ISMS scope of Acme Platforms Ltd applies to the Acme Payments API production service and its supporting engineering, operations, cloud infrastructure, monitoring, incident management, and customer support processes. Corporate shared services that affect the in-scope service are documented as controlled interfaces. Planned future review will assess expansion to additional products and business units; those areas are not represented as certified within the current ISMS boundary unless and until the scope is formally changed.
How to Approve, Review, and Change the Scope Over Time
Scope should not be treated as a one-time drafting exercise. When an organisation determines that its ISMS needs to change, ISO/IEC 27001 Clause 6.3 requires the change to be carried out in a planned manner. Because scope is documented information defining the ISMS boundary, scope changes should be handled as planned ISMS changes and their downstream effects assessed.
Consider reviewing the scope when there is:
- a new product, service, or major feature
- an acquisition, restructuring, or new business unit
- a major cloud, identity, network, platform, or data architecture change
- a new office, delivery location, or remote-working model
- a significant supplier, outsourcing, or support model change
- a customer or contractual requirement that relies on a broader boundary
- a material change to data types, processing, or risk profile
- a planned expansion from a staged or narrow scope to a broader one
Keep the governance proportionate. At minimum, a practical scope record should make it clear:
- who owns the scope
- who approved it
- which version is current
- what changed and why
- which inclusions, exclusions, interfaces, and dependencies were affected
- whether risk assessment, control selection, Statement of Applicability, evidence plans, or stakeholder communications need updates
The key is not bureaucracy. The key is preventing a stale scope from describing last year’s operating model while the actual service, systems, suppliers, or customer commitments have moved on. That is usually the thing to watch.
Final Scope Definition Checklist
Before using the scope statement internally, with customers, or in an initial certification discussion, check that:
- the scope reflects organisational context and relevant interested-party requirements
- covered products, services, units, locations, systems, roles, and processes are clear
- exclusions are specific, justified, and documented
- shared services are treated as defined interfaces where appropriate
- dependencies with other organisations are identified
- the boundary does not imply coverage for services, locations, or functions that are outside scope
- risk assessment and evidence collection can operate within the defined boundary
- owner, approval, version, and review triggers are recorded
- the scope can be explained plainly in a scoping workshop or certification-body conversation
A defensible ISO 27001 scope is not the broadest possible statement or the narrowest convenient one. It is the boundary you can explain, operate, evidence, and maintain as the organisation changes.