How should organisations scope an ISO 27001 information security management system before certification?

What “scope” means before an ISO 27001 certification audit

Scope is not just a box-ticking document. It defines the information security management system as the audited management system, so it has to match how the business actually operates. The scope statement should describe the services, processes, supporting technology, people, sites, and third parties that create or influence information security risk. That is why auditors will look for consistency between the scope, the risk assessment, and the Statement of Applicability.

A practical scope should also be defensible. If the organisation leaves out a business-critical process, facility, or supplier dependency that affects confidentiality, integrity, or availability, the scope can look artificially narrow. If it is written too broadly, the team may struggle to evidence controls, ownership, and operational boundaries during the audit.

One useful anchor is the ISO 27001 certification journey itself, because scope is the point where certification effort becomes concrete. NHIMG’s ISO 27001 Certification Guide covers scope, risk assessment, the Statement of Applicability, Annex A, and the stage 1 and 2 audits, which are the exact moving parts that have to line up before certification.

How to define the boundaries without under-scoping or over-scoping

Start from the business service or operating model, then work outward to the assets and dependencies that support it. In practice, that means identifying the applications, infrastructure, identities, suppliers, facilities, and people that are in-scope because they store, process, transmit, or administer information. A scope statement that only names a legal entity but ignores the operational reality is usually too vague to be useful.

For many organisations, the hardest part is deciding how far to extend the boundary around outsourced or shared services. If a vendor hosts a critical platform, manages privileged access, or handles backups, that dependency needs to be visible in the ISMS even if the provider is not being certified itself. The same logic applies to shared cloud tenancy, remote administration, and hybrid estates where control ownership is split.

This is where a structured control view helps. NHIMG’s ISO 27002 Controls Guide is useful because scope decisions should be made with the 93 Annex A controls in mind, not in isolation from them. The boundaries you choose should allow the relevant organisational, people, physical, and technological controls to be applied and evidenced coherently.

Scope is also the place to decide whether adjacent compliance obligations are part of the same operating environment. If you already map controls across frameworks, NHIMG’s Control Mapping Guide can help teams avoid building a scope that is inconsistent with other control sets, especially where evidence reuse or common control ownership matters.

What good scope evidence looks like in practice

Auditors do not just want a paragraph, they want a management decision that can be defended. Good scope evidence usually includes the rationale for inclusion and exclusion, the list of sites and systems covered, the services delivered from those boundaries, and the material dependencies that could affect security risk. If exclusions exist, they should be explicit and consistent with the risk assessment rather than left implicit.

Scope should also line up with policy, roles, and governance. The ISMS cannot be scoped to one team’s environment if security decisions, change control, incident handling, or supplier management are actually shared across several teams. A cleaner scope statement is usually the one that reflects real accountability rather than the most convenient org chart.

When teams are still working out how to present that boundary, NHIMG’s Information Security Policy Template is a useful companion because it shows how scope, roles, exceptions, and review sit inside the wider policy structure. For certification, the scope statement and the policy should reinforce the same operating boundary, not tell different stories.

Risk and Threat Considerations

A weak scope is a common source of certification friction because it can hide real security exposure rather than define it. The main risks are incomplete control coverage, missing supplier dependencies, and audit findings when the organisation cannot show that the scoped environment reflects how information actually flows.

Failure mechanism: The organisation defines a narrow or convenience-based boundary, then cannot demonstrate that key systems, locations, vendors, or privileged administration paths were considered in the ISMS risk treatment and control selection.

Impact: The audit may uncover scope gaps, the Statement of Applicability may not match operational reality, and the certification evidence can appear inconsistent even where individual controls are well designed.

Practitioner Guidance

What to prioritise: Lock the business services and high-risk dependencies first, then work downward into applications, infrastructure, facilities, and third parties. If you cannot explain why a component is outside scope, treat that as a scoping problem rather than an audit note.

What to verify: Check that the scope statement, asset inventory, risk assessment, and Statement of Applicability all describe the same operating boundary. The fastest way to fail a readiness review is to have one document that is broader, narrower, or differently worded than the others.

Practitioner takeaway: The best ISO 27001 scope is not the smallest possible scope, it is the smallest scope that still matches operational reality and can be evidenced end to end.

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 security teams scope an AI management system for ISO 42001 certification?
• How should organisations structure an ISO 27001 information security policy for auditors and management alike?
• What are the signs that an ISO 27001 management system is losing effectiveness after certification?