Is Scope the First Structural Decision of the ISMS?
The Clause 4.3 of ISO 27001:2022 requires determining and documenting the scope of the ISMS, taking into account the organization’s internal and external context (clause 4.1), the requirements of interested parties—customers, shareholders, regulators (clause 4.2)—and the interfaces with other organizations, notably providers and subcontractors.
This scope sets the boundaries of everything the auditor will examine. A site, an application, or a process left out of the scope without written justification becomes a non-conformity in the audit, even if the company governs it well in practice.
Specialist firms like FeelAgile intervene at the framing stage before the ISMS deployment, using a method that distinguishes what must enter the initial scope from what can be addressed in a later phase.
-> GDPR and ISO 27001 compliance
The Four Dimensions to Cover to Map the ISMS Boundary
The scope of an ISMS is built across four dimensions that must all be examined before drawing the boundary:
- Sites and premises: which offices, warehouses, or data centers are physically covered by the ISMS?
- Information assets: which data, applications and infrastructures host the information to be protected?
- Business processes: which company activities create, handle, or move these information assets?
- People and entities: which teams, subsidiaries or legal entities are included within this scope?
Here is a table that shows, for each dimension, the decision question to answer and a concrete example of an auditable justification that would be acceptable.
| Element of the scope | Decision to make | Example of justification |
| Sites and premises | Which offices, data centers, or physical spaces are covered? | Headquarters in Lyon included; Paris commercial office with 2 staff excluded, with no access to information systems |
| Information assets | Which data, applications and infrastructures are included? | CRM, ERP, production cloud environment included; accounting outsourced workstation excluded |
| Business processes | Which business activities does the ISMS cover? | Software development and hosting included; HR recruitment excluded, with no link to the protected assets |
| Subsidiaries and entities | Does the scope cover a site, a subsidiary, or the entire group? | French subsidiary certified first; German subsidiary in scope deferred, phase 2 |
| Subcontractors and interfaces | Which external dependencies lie outside the direct scope? | Cloud hosting provider excluded from the direct scope, but mapped as an interface with its own ISO 27001 certification |
One area warrants particular vigilance: interfaces with third parties.
-> If the company outsources hosting, Clause 4.3 requires explicitly documenting this boundary. The auditor does not expect the client’s ISMS to cover the provider’s data center, but does expect this dependency to be identified and its risk addressed, for example via the hosting provider’s own ISO 27001 certification.
Broad Scope or Narrow Scope: Choosing Based on the Organization’s Maturity
Two strategies compete when setting the scope, and neither is universally the right choice.
A Narrow Scope for a Rapid First Certification
Beginning with a limited initial scope—restricted to a product, service, or a specific legal entity—enables a first certification in 6 to 9 months rather than 18 to 24 months. This approach is especially suitable for SaaS vendors aiming to demonstrate the security of a flagship product quickly to B2B customers, with the possibility of expanding the scope to other activities in the next certification cycle.
A Broader Scope to Cover the Entire Organization
Conversely, a scope that encompasses the whole organization avoids ongoing questions from customers or auditors about what is “in the certificate” and what is not. This option requires more upfront resources but simplifies commercial communications and responses to procurement processes that demand organization-wide certification rather than a partial scope.
Documenting the Scope: What the Auditor Needs to Read Clearly on Paper
Clause 4.3 requires the scope to be documented, available, and verifiable. Practically, the auditor expects a distinct scope document that contains:
- The exact wording of the scope, in one or two precise sentences, reproduced verbatim on the final certificate
- The list of sites, activities, and assets covered, with their geographic and organizational scope
- Explicit exclusions, each justified: why this site, process, or entity remains outside the scope
- Interfaces and dependencies with third parties: hosting providers, subcontractors, technology partners
- The date of the last review and the designated owner of the document
Be mindful of a common confusion: the scope document is not the Statement of Applicability (SoA).
-> The scope answers the question, “which part of the organization is affected?” The SoA answers, “which of the 93 controls in Annex A apply, and why?” The SoA is built once the scope is fixed, never the other way around.
Scope Errors that Cause ISO 27001 Certification Audits to Fail
Consultants who support ISO 27001 certifications observe a small set of recurring mistakes:
- Excluding a site or activity without written justification, becoming a non-conformity at the first auditor question
- Defining a scope that does not reflect operational reality, for example by excluding a team that accesses the same systems as the stated scope
- Confusing the ISMS scope with the scope of the SoA, resulting in an SoA built on a fuzzy scope
- Failing to document interfaces with external providers, even though Clause 4.3 explicitly mentions them
- Never reviewing the scope after a structural change: new offering, acquisition, cloud migration
Evolving the Scope Over Time Without Starting from Scratch
A ISMS scope is never set in stone. It should be revised at every structural change: the opening of a new site, the launch of an offering, migration to a new hosting provider, the acquisition of a company. The annual management review, required by the standard, is the natural moment to raise the question, but a major mid-year change justifies an earlier revision.
Extending an already certified scope is generally faster than obtaining a first certification: governance processes, security policy, and part of the risk analysis already exist. The work focuses on gaps specific to the new scope: new assets, new risks, additional controls required by the SoA.
Frequent Questions About ISO 27001 Scope
Must the ISMS scope cover the entire company?
No. The standard does not impose a minimum or maximum scope. A company can certify a single product, a single subsidiary, or the entire group, provided the chosen scope is documented, justified, and aligned with the real risks of the activity covered.
What is the difference between the ISMS scope and the Statement of Applicability?
The scope defines which parts of the company are covered by the ISMS: sites, activities, assets, entities. The Statement of Applicability (SoA) comes afterward and specifies, among the 93 Annex A controls, which apply to that scope and why. A coherent SoA cannot be drafted without a stabilized scope.
Can a third-party provider be excluded from the ISMS scope?
Yes, provided it is documented as an external interface rather than ignored. If a cloud provider manages the underlying infrastructure, the organization may exclude that infrastructure from its own scope but must identify the dependency and rely on the provider’s guarantees, for example through the provider’s own ISO 27001 certification or a SOC 2 report.
Can the scope evolve after certification is achieved?
Yes, and this is expected as the organization grows. Any extension or reduction of the scope must be documented and will be verified during the annual surveillance audit or the 3-year renewal audit. An undeclared scope change is a common reason for non-conformity found during audits.
