Start by defining the boundaries of the information security management system around the applications, systems, processes, people, and locations that support the business. Then map which Annex A controls are applicable to that scope. A good scope is specific enough to be auditable, but broad enough to cover the real operational environment and the data, vendors, and facilities that affect security risk.
Scope the ISMS Around How the Business Actually Operates
An ISO 27001 scope should describe the real operating environment, not just the neatest organisational chart. Define which applications, systems, processes, people, sites, and third parties are necessary to deliver the services you want certified. That means including the locations and dependencies that can affect confidentiality, integrity, availability, and the evidence you will need to defend the scope during audit.
A practical scope statement is usually built from service boundaries first, then organisational boundaries. Start with the business services being protected, identify the assets and teams that support them, and only then decide where exclusions are justified. If a vendor, shared platform, or remote facility materially affects the security outcome, it belongs in the scoping exercise even if it sits outside the legal entity.
For the control baseline that sits behind this scoping work, organisations commonly use ISO/IEC 27001:2022 Information Security Management alongside ISO/IEC 27002:2022 Information Security Controls to translate the scope into applicable controls.
Why Scope Discipline Matters Before the Audit Starts
Scope is not just a documentation exercise. If it is too narrow, you create a false sense of compliance and risk omitting systems, facilities, or suppliers that can break the security model. If it is too broad, the ISMS becomes hard to operate, hard to evidence, and difficult to maintain because teams start treating every asset as equally in scope.
The right scope balances auditability with operational reality. Auditors want a boundary they can test, but practitioners need a boundary that reflects how data flows, how access is granted, and how work is actually performed. A strong scope statement therefore needs to be explicit about inclusion criteria, exclusions, interfaces, and shared responsibilities.
That is why control selection should follow the scope, not define it. Once the boundary is set, Annex A applicability becomes a mapping exercise, not a discovery exercise. If you reverse that order, you risk shaping the ISMS around what is convenient to certify rather than what is necessary to secure the business.
What Good Scope Decisions Look Like in Practice
A defensible scope usually names the service or business function, the supporting technology estate, the people and operational processes involved, and any physical or hosted environments that influence risk. It should also identify important dependencies such as managed service providers, cloud platforms, shared identities, or external facilities where those dependencies affect the security posture.
Good scoping also distinguishes between ownership and operation. A system may be owned by one team, run by another, and support a service delivered elsewhere. The ISMS should capture that arrangement clearly so responsibilities for risk acceptance, control operation, incident handling, and evidence production are not ambiguous during certification.
When the environment is highly distributed, it helps to document the boundary in layers: core in-scope assets, dependent services, shared services, and explicitly excluded items with the reason for exclusion. That structure makes the scope easier to maintain as the business changes and gives auditors a transparent view of what is covered and why.
For organisations that have significant identity and secret-management dependencies inside that environment, NHIMG’s Ultimate Guide to NHIs is useful context because it shows how service accounts, API keys, and related operational dependencies can materially affect the security boundary.
Practitioner Guidance
What to prioritise: Anchor the scope to the business service first, then test whether the supporting systems, locations, vendors, and processes are actually needed to deliver that service. If you start from the asset inventory alone, you will usually miss shared services and external dependencies that matter to the audit.
What to verify: Make sure every exclusion has a written justification and that every material interface has an owner. The easiest scope to challenge is one that cannot explain how data enters, leaves, or is administered across the boundary.
Common mistake: Treating the scope as a one-time certification document instead of a living boundary. Mergers, cloud migrations, outsourced operations, and new delivery models can invalidate yesterday’s scope long before the next surveillance audit.
Practitioner takeaway: A good ISO 27001 scope is not the smallest certifiable boundary, it is the smallest boundary that still reflects real operational risk and can be evidenced without hand-waving.
Related resources from NHI Mgmt Group
- How should organisations implement ISO/IEC 27001 when they are building a formal information security management system?
- How should organisations structure an ISO 27001 information security policy for auditors and management alike?
- How should security teams govern non-human identities for ISO 27001?
- Why do organisations need an ISO 27001 information security policy beyond passing an audit?
