Start by defining what information must be protected, where it is stored, and who or what can access it. Then set clear in-scope and out-of-scope boundaries across products, locations, people, technology, and networks. A usable scope keeps the ISMS auditable, avoids overreach, and ensures controls map to real business and information risks.
Why This Matters for Security Teams
isms scope is not a paperwork exercise. In iso 27001, scope defines what the organisation actually commits to protect, which means it shapes audit evidence, control selection, risk treatment, and management accountability. For complex organisations, a vague scope often hides shared services, outsourced platforms, legacy estates, and cloud workloads that still process sensitive information. That creates false confidence: the certificate may look complete while critical systems sit outside the management system.
Current guidance in ISO/IEC 27001:2022 Information Security Management is to define scope in relation to the organisation, its interfaces, and the information security boundaries that matter to business risk. The practical challenge is that “organisation” rarely maps neatly to legal entities, brands, business units, or technical environments. Shared identity platforms, central logging, SaaS estates, and third-party-operated services can all be relevant even when they are not owned end to end.
Security teams also underestimate non-human access. Service accounts, API keys, automated workflows, and AI agents can all sit inside the scope if they can read, write, or move protected information. In practice, many security teams encounter scope weaknesses only after an audit challenge, incident, or major platform integration has already exposed the gap, rather than through intentional boundary design.
How It Works in Practice
Scope should be built from information flow, control responsibility, and operational reality, not from a simplistic org chart. Start by identifying the business services, processes, and information assets that fall under the ISMS, then trace where data is created, processed, stored, transmitted, and deleted. That includes internal systems, cloud tenants, remote endpoints, managed services, and third-party platforms where the organisation still retains risk ownership.
A workable scope statement usually answers three questions: what is protected, where are the boundaries, and which interfaces are included. That makes it easier to show auditors why certain facilities, business units, or systems are excluded, and what compensating controls exist where exclusions create dependency risk.
- List the products, sites, legal entities, and shared services that support the defined information set.
- Map access paths, including privileged users, contractors, integrations, and machine identities.
- Document assumptions for outsourced operations, SaaS, and hosting layers.
- Confirm that risk owners and control owners are identified for each in-scope boundary.
For identity-heavy environments, scoping should explicitly include privileged access, service accounts, and secrets management because those are often the shortest path from a minor control gap to a material breach. The OWASP Non-Human Identity Top 10 is useful here because it highlights how machine identities become part of the trust boundary, not just a technical detail. Best practice is evolving, but current guidance suggests treating non-human access as part of scope whenever it can affect confidentiality, integrity, or availability of in-scope information.
Implementation breaks down when the organisation has highly decentralised IT, rapid M&A activity, or heavily outsourced operations because the evidence for ownership, access, and control operation becomes fragmented across multiple teams and providers.
Common Variations and Edge Cases
Tighter scope often reduces audit burden and control sprawl, but it can also leave out shared dependencies that still create real risk, so organisations must balance certifiability against operational completeness. That tradeoff is especially visible in groups with multiple subsidiaries, regional data centres, or mixed regulated and non-regulated businesses.
Where there is no universal standard for this yet, practitioners should be explicit about boundary logic. For example, some organisations scope a single business unit first and then expand through phased certification, while others include enterprise-wide shared services from day one because those platforms materially influence every in-scope process. Both approaches can be defensible if the exclusions are justified and the residual risk is understood.
Scope also becomes tricky when cloud services, DevOps pipelines, and AI-enabled tooling are used across teams. If those tools can access in-scope data, generate outputs used in business processes, or create or change credentials, they should be assessed as part of the ISMS boundary. The relevant control question is not who bought the tool, but who can influence protected information through it. For structure and control mapping, ISO/IEC 27002:2022 Information Security Controls remains the practical reference point for turning scope into implementable safeguards.
Complex groups should also revisit scope after acquisitions, major outsourcing changes, platform migrations, or identity redesigns, because those events often change the actual trust boundary faster than policy documents do.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.SC-1 | Scope depends on understanding business context and critical dependencies. |
| NIST SP 800-63 | Identity assurance matters where people and machine identities access in-scope data. | |
| OWASP Non-Human Identity Top 10 | Non-human identities can sit inside the ISMS trust boundary and drive risk. | |
| NIST AI RMF | GOVERN | AI tools and agents used in scope need governance and accountability. |
| ISO/IEC 27001:2022 | 4.3 | The scope clause requires boundaries and applicability to be clearly defined. |
Map business services and dependencies first, then set ISMS boundaries around actual risk.
