How to Write Your ISMS Scope Statement (With Examples)

An ISMS scope statement defines the boundaries and applicability of your information security management system: which services, locations, legal entities, and technology it covers — and, just as importantly, where your responsibility ends. It is usually one paragraph long, it is printed on your ISO 27001 certificate, and it is the first thing an auditor reads about your organization.

That combination — very short, very consequential — is why so many teams get it wrong. This guide covers what Clause 4.3 actually asks for, what a usable scope statement names, three worked examples you can adapt, and the boundary mistakes that make certification harder than it needs to be.

What ISO 27001 Clause 4.3 Requires

Clause 4.3, "Determining the scope of the information security management system," asks you to determine the boundaries and applicability of the ISMS. In doing so, the standard requires you to consider three specific inputs:

• The external and internal issues from Clause 4.1 — the context you operate in: your market, your regulatory environment, your technology choices, your size.
• The requirements of interested parties from Clause 4.2 — what customers, regulators, investors, and employees expect of you. (Since the 2024 amendment, this explicitly includes considering whether climate change is a relevant issue — see the amendment nobody told you about.)
• Interfaces and dependencies between activities you perform and activities performed by other organizations — your cloud providers, your subprocessors, your outsourced help desk.

The clause then requires that the scope "be available as documented information." That is the whole requirement. There is no prescribed template, no minimum length, and no mandated format — which is precisely why teams stare at a blank page.

That third input is the one most often skipped. A scope statement that never mentions your cloud provider or your outsourced support desk tells the auditor you haven't thought about where your control ends and someone else's begins — and that is the first thing they will probe.

What a Usable Scope Statement Names

A scope statement that survives contact with an auditor names six things. Not all six need to be in the sentence that goes on the certificate, but all six need to be determined and documented somewhere:

1. The products and services covered. What you actually sell, in the words your customers use.
2. The organizational units and legal entities. Which companies, which teams. If you have subsidiaries, name them or exclude them explicitly.
3. The locations. Offices, data-centre regions, and — for distributed teams — the fact that personnel work remotely, which brings home-working controls into play.
4. The technology and infrastructure. The platform, the cloud regions, the supporting corporate IT.
5. The interfaces and dependencies. Where you hand off to a provider, and what remains your responsibility on your side of that line.
6. The exclusions, with reasons. Anything a reader would reasonably assume is in scope but isn't.

Three Worked Examples

Adapt these to your own facts rather than copying them — an auditor who reads a scope statement that doesn't match what they see in your systems will start the audit sceptical.

Example 1: Whole-company SaaS

The ISMS covers the design, development, operation, and support of the [Product] software-as-a-service platform, including all supporting corporate IT and business processes, delivered by [Company Ltd] from its registered office in [City, Country] and by personnel working remotely. The platform is hosted on [Cloud Provider] infrastructure in the [region] region. Interfaces with, and dependencies on, [Cloud Provider] and the subprocessors listed in the ISMS supplier register are managed through the supplier management process; responsibility for the underlying physical infrastructure rests with those providers.

This is the right shape for most startups. Everything the company does is in scope, which sounds expansive but is actually the cheapest option when the company only does one thing.

Example 2: Business-unit scoped

The ISMS covers the provision of the [Payments] service by the [Payments] business unit of [Group Ltd], including the engineering, operations, and customer support functions supporting that service, at the [City] office and on [Cloud Provider] infrastructure in [region]. Other business units of [Group Ltd], including [Marketing Services] and [Consulting], are outside the scope of the ISMS. Shared corporate services (HR, finance, corporate IT) are within scope to the extent that they support the [Payments] service.

The last sentence is the one that saves you. Shared services are where business-unit scoping usually breaks down: if corporate IT issues the laptops your in-scope engineers use, corporate IT is in scope for that purpose whether you wanted it to be or not.

Example 3: With an excluded entity

The ISMS covers the development and operation of the [Product] platform by [Company Ltd] ([City, Country]). [Company GmbH] ([City, Country]), acquired in [Month Year] and operating a separate product on a separate infrastructure stack with no data flows to or from the [Product] platform, is excluded from the scope of the ISMS.

Exclusions are legitimate — but the justification has to be a fact about isolation, not a statement of convenience. "No data flows to or from" is a fact an auditor can test. "Not yet integrated" is a plan, and a plan invites a follow-up question at every surveillance visit.

Scope Exclusions Are Not Control Exclusions

This is the single most common confusion, and it costs teams time in the first certification audit.

Scope exclusions are boundaries: entities, locations, services, or systems that the ISMS does not cover. They belong in the scope statement under Clause 4.3.

Control exclusions are Annex A controls you have determined are not applicable — physical media controls when you hold no physical media, for instance. Those belong in your Statement of Applicability, where Clause 6.1.3 requires a justification for each one.

Putting control exclusions in the scope statement makes your certificate look narrower than your business actually is — which is exactly the outcome a customer's procurement team will notice. Keep the two documents doing their own jobs.

Too Broad Versus Too Narrow

Both failure modes are expensive, in different currencies.

Too broad costs you audit effort. Every system inside the boundary needs an owner, a risk assessment, evidence, and internal audit coverage. Teams that scope "the whole group" before they have a working ISMS end up evidencing marketing tooling and dormant subsidiaries that no customer ever asked about.

Too narrow costs you the point of the exercise. A certificate scoped to "the information security function at the head office" is technically valid and commercially useless — a customer reading it cannot tell whether the product they are buying is covered. If your scope statement doesn't name the thing you sell, expect the certificate to keep failing procurement reviews.

The test worth applying: hand your scope statement to someone in sales and ask whether a customer reading it would believe the product they are buying is covered. If the answer is no, the boundary is in the wrong place.

Scope Drift and When to Revisit

Scope is not written once. It is documented information subject to change control, and it should be revisited when the business changes shape. Concrete triggers worth writing into your ISMS:

• A new product line, or a material change to an existing one
• An acquisition, a new legal entity, or a new office
• A new cloud region or a migration between providers
• A new class of customer data, or a new regulatory obligation
• Outsourcing something you previously ran yourselves — or bringing it back in-house

Scope changes are also a standing input to management review under Clause 9.3. If your scope statement is a year old and your architecture isn't, that gap will surface at your next surveillance audit — and a scope that no longer matches reality is a finding, not a formality.

The Takeaway

Write the scope statement your business can actually defend: name the services in the words customers use, name the entities and locations, be explicit about where your providers' responsibility begins, and justify exclusions with facts rather than intentions. Then keep it current, because it is the one ISMS document your customers will read.

Next: the full Clause 4–10 walkthrough for how scope feeds the rest of the ISMS, how to write a Statement of Applicability for the control-level document that follows it, or the asset register that turns your boundary into a list you can actually evidence.