The scope statement is a few sentences long and shapes everything else in the ISMS. It decides which risks you assess, which controls apply, which people are interviewed, how long the audit takes, and what your certificate says to a buyer. Teams often write it in a hurry and spend the next three years working around it.
Two opposite mistakes are common. A scope drawn too narrowly, around one team or one system, produces a certificate that buyers read and then set aside because it does not cover what they are buying. A scope drawn too broadly, around the whole company before the ISMS is ready, makes the first audit far harder than it needs to be.
This article covers what clause 4.3 of ISO/IEC 27001:2022 requires, how to draw the boundaries, how to write the statement itself, and how to deal with the parts of your service that other organizations run.
What clause 4.3 requires
Clause 4.3 requires you to determine the boundaries and applicability of the ISMS to establish its scope. When doing so, you must consider:
The external and internal issues identified under clause 4.1
The requirements of interested parties identified under clause 4.2
The interfaces and dependencies between activities performed by your organization and those performed by other organizations
The scope must be available as documented information.
The considerations are not optional context. If a customer contract requires a service to be covered, or a regulation applies to a particular location, and your scope leaves it out, you need a reason. The clause 4 article covers how to build the issue and interested party registers that this step draws on.
Three documents that are easy to confuse
People often mix up three things that refer to scope in different ways.
| Document | What it states | Who reads it |
|---|---|---|
| ISMS scope statement | The boundaries and applicability of the ISMS, with enough detail to audit against | Your auditor, your staff |
| Certificate scope | A concise wording the certification body issues, based on your scope | Buyers, partners |
| Statement of Applicability | Which Annex A controls apply within the scope, and why | Your auditor |
The ISMS scope statement is yours. The certificate scope is agreed with your certification body and usually shorter. The Statement of Applicability works inside the scope, deciding which controls apply. Excluding a control in the Statement of Applicability does not narrow the scope, and narrowing the scope is not a way to avoid controls.
Drawing the boundaries
A boundary answers "what is inside the ISMS". It helps to work through four dimensions in turn.
Organizational
Which legal entities, business units, and teams are in scope. Many small SaaS companies scope the whole organization, because the people building and running the product are most of the company.
Services and processes
Which products, services, and supporting processes are included. Name them as a buyer would recognize them. Supporting processes such as HR onboarding, procurement, and software development are usually inside, because the in-scope service depends on them.
Physical
Which offices, sites, and data centers. For a remote company with infrastructure in a cloud provider, the physical boundary may be one office, or none, plus the homes of remote staff as working locations. Say so plainly.
Technological
Which systems, networks, environments, and cloud accounts. Production is in. The question is usually how far the boundary extends into supporting systems: source control, the identity provider, CI pipelines, and support tooling that can read customer data are typically inside, because compromising them affects the in-scope service.
Say a hypothetical 80-person company sells two products. One handles customer data and drives the demand for certification. The other is a small internal tool with no customer data. Scoping the first product, with the supporting functions it depends on, produces a credible certificate. Excluding the shared identity provider or the engineering team that builds both products does not.
Writing the statement
A scope statement that works is specific, checkable, and readable by someone outside the company. It should cover:
The organization, by legal name
The products or services in scope, named as customers know them
The locations, including remote working if it applies
The key technology, such as the production environment and the cloud provider regions or accounts
Anything explicitly excluded, with a short reason
A reference to the Statement of Applicability version, which certification documents commonly cite
A hypothetical example:
The information security management system of Example Software, Inc., covering the development, operation, and support of the Example Scheduling platform, delivered from the company's office and by remote staff, and hosted in its production cloud environment. In accordance with Statement of Applicability version 3.
A detailed scope document can sit behind this sentence, listing systems, teams, and locations. The detail is what your auditor tests against. The sentence is what appears, in some form, on the certificate.
Interfaces and dependencies
Almost every SaaS service depends on other organizations: a cloud provider, an identity provider, payment processors, customer support platforms. Clause 4.3 requires you to consider these interfaces and dependencies when setting scope.
That does not bring the provider's operations into your ISMS. You cannot audit your cloud provider's data centers, and your certificate does not cover them. What the scope must show is that you understand where the boundary sits and that you manage the dependency from your side. Annex A covers this through the supplier controls in 5.19 to 5.22, and 5.23 for cloud services specifically.
Write the dependencies down, either in the scope document or a linked register. For each significant one, note what the provider does, what you remain responsible for, and how you oversee it.
Narrow first, or whole company?
There is no single right answer, and the standard does not prefer either. A narrower first scope can make sense when one product drives the demand for certification and the rest of the organization is not ready. A whole-company scope makes sense when the product and the company are effectively the same thing, which is often true for smaller companies.
The test is what a buyer will conclude from the certificate scope. If the scope covers what they are buying, including the people and systems that build and run it, a narrower scope is credible. If they would need to ask which parts of your service are actually covered, it is too narrow. Expanding later is possible, but each expansion is a change your certification body has to audit.
Weak scopes and what auditors do with them
Certification bodies review the scope at stage 1, and they can challenge it. ISO/IEC 27006 requires them to check that the scope is appropriate, including how interfaces with activities outside the scope are addressed. These are the patterns that draw questions.
Exclusions without reasons. A product or team left out with no explanation of why it is separate.
Missing dependencies. A scope that covers the product but excludes the shared systems it runs on.
Wording that overstates. A certificate scope that reads as company-wide when the ISMS covers one service. This misleads buyers and will be corrected.
Vague language. Phrases such as "all relevant systems" that cannot be audited because nobody can say which systems they are.
A stale scope. A new product launched, or an office opened, with the scope unchanged.
Scope changes after certification need to go to your certification body. An expansion may need additional audit time, or a special audit. Plan scope changes around your audit cycle where you can. The accreditation article explains why buyers read the certificate scope closely, and if you also hold or plan SOC 2, the guide to scoping a first SOC 2 report covers the equivalent decision there. The ISO 27001 framework page summarizes the standard.
How TrustLynce helps
TrustLynce keeps a versioned Statement of Applicability, so the version your scope statement references is always identifiable. Customer commitments are tracked against controls, which helps you check that what your contracts require sits inside the scope.