How to Write an ISO 27001 ISMS Scope Statement (Clause 4.3 Template + Example)

Scope is the first decision in an ISO 27001 project you cannot undo cheaply. Everything that follows — the risk assessment, which of the 93 Annex A controls actually apply, how much audit evidence you have to produce every year, how many staff need security training records — is sized against whatever boundary you draw in the scope statement. Get it right and every later document is proportionate to the problem you actually have. Get it wrong in either direction and you pay for it: either in wasted implementation effort now, or in a re-scope and re-audit later.

That is why clause 4.3 of ISO/IEC 27001:2022 sits near the front of the standard rather than buried in an annex — it treats scope as a formal, documented decision with specific required inputs, not a paragraph you dash off before the “real” work starts. This guide covers what clause 4.3 actually requires the scope statement to address, the practical scoping patterns real organisations use, how that boundary compares to the entity-level scope a NIS2-covered organisation already has under Article 3, and a worked example you can adapt. For the full clause-by-clause structure of an ISO 27001 project, see our ISO 27001 compliance guide.

Why Scope Is the First Real Decision — and the Costliest to Get Wrong

Scoping mistakes run in two directions, both expensive on different timelines.

Too broad costs you now. If the scope statement says “the whole company” but your actual customer promise only touches one product, every business unit and legacy IT asset swept in has to participate in risk assessment, control implementation, internal audit, and management review — whether or not it touches what customers actually rely on. Annex A has 93 controls across four themes; a scope twice as large as it needs to be doesn’t make you twice as secure, it means twice the evidence to produce and a longer, pricier path to a certificate for coverage nobody asked for.

Too narrow costs you later, at a worse moment. Scoping tightly to “the production environment” gets you certified faster, but if a customer’s due-diligence team notices the support tooling or the office handling their onboarding data sits outside the certified boundary, the certificate doesn’t answer their question. Expanding scope after certification isn’t a quick amendment under most certification body rules — it typically means a fresh gap analysis, a Stage 1 readiness review of the expansion, and often a Stage 2 audit covering exactly the part left out the first time. That’s close to re-running the project, on a schedule set by a customer’s deadline instead of your own.

Both failure modes trace back to the same cause: scope decided by instinct, instead of by working through the inputs clause 4.3 actually asks for.

What ISO 27001 Clause 4.3 Actually Requires

Clause 4.3 requires the organisation to determine the boundaries and applicability of the ISMS in order to establish its scope, and in doing so to consider three specific inputs: the internal and external issues referred to in clause 4.1 (the organisation’s context), the requirements of interested parties referred to in clause 4.2, and the interfaces and dependencies between activities the organisation performs and those performed by other organisations. [1][2]

In practice, that breaks down into questions a first-time scope owner can work through:

• Internal and external issues (4.1). What’s happening around and inside the business that a security programme needs to account for — regulatory environment (NIS2 obligations, sector rules, data protection law), business model, technology stack, and how the organisation is structured.
• Interested party requirements (4.2). Who is actually asking for this, and what do they need covered — customers requiring the certificate to cover the specific service they buy, regulators, insurers pricing cyber cover, or investors doing due diligence.
• Interfaces and dependencies with other organisations. The piece first-time scoping exercises miss most often. If production runs on a cloud provider, payroll runs through a third-party processor, or development is partly outsourced, the scope statement has to acknowledge those dependencies explicitly — not by pulling the third party inside the ISMS boundary, but by naming the interface and pointing to how it’s managed through supplier security controls. [1]

Two further requirements sit alongside the three inputs. First, the scope has to be retained as documented information — a controlled document, not a verbal understanding among the project team. [1][2] Second, any exclusion from scope must be explicitly justified, and that justification can’t simply be cost or inconvenience: an excluded system or process must not affect the organisation’s ability to meet the standard’s requirements or protect the information that is in scope. [2] A payment system handling in-scope customers’ card data, for instance, can’t be excluded just because securing it is expensive.

Practical Scoping Patterns — and Their Tradeoffs

Once you’ve worked through the clause 4.3 inputs, the boundary usually lands in one of three shapes. None is objectively “correct” — each is a proportionate answer to a different set of drivers.

Pattern	Fits when	Main tradeoff
Whole-company scope	The organisation is small enough, or homogeneous enough, that there’s no meaningful line to draw — e.g. a single-product SaaS company where every employee touches the system that matters	Simplest to explain to customers (“everything is certified”), but every unit, including ones unrelated to the actual service sold, now carries the full weight of risk assessment, controls, and audit evidence
Business unit / product line scope	The organisation sells one specific product or service that customers ask about, alongside other activities that don’t touch the same data or systems	Proportionate cost and the most common pattern for a single SaaS product, but shared services — a shared helpdesk, shared HR system, shared office network — must be explicitly treated as interfaces and dependencies, not silently left out
Specific site / data centre scope	The sensitive processing genuinely happens in one physical location and the certificate exists to satisfy a specific contractual or colocation requirement	Narrowest and fastest to certify, but rarely answers what a customer means by “are you ISO 27001 certified” for a cloud or SaaS product — it says nothing about the application layer or staff access if those sit elsewhere

If your organisation already has NIS2 obligations, it’s tempting to assume the ISO 27001 scope should mirror your NIS2 scope. Don’t assume it either way. NIS2 applies at the level of the entity as a whole: essential and important entity status under Article 3 of Directive (EU) 2022/2555 attaches to the legal entity operating in an Annex I or Annex II sector, not to a single product line within it. [3] Your ISO 27001 scope, by contrast, is your own business decision under clause 4.3 — it can legitimately be narrower than your NIS2 entity-level obligation, covering just the product or service your B2B customers actually ask about in due diligence, while your NIS2 compliance work continues to cover the whole organisation as the Directive requires. That’s a defensible split, but it needs to be a conscious decision recorded in the scope statement’s own reasoning, not something a customer’s security team discovers mid-deal. For the full technical mapping between the two frameworks and where the 70–80% control overlap lands, see our NIS2 vs ISO 27001 comparison.

Whichever pattern you choose, weigh it against realistic certification cost and timeline first — a broader scope doesn’t just mean more controls, it stretches the project across the ranges covered in our ISO 27001 certification cost guide.

A Worked Example: Scope Statement for a Hypothetical SME

Take a hypothetical company, Northbridge Ledger, a 60-person EU-based B2B SaaS provider selling accounts-receivable automation software to mid-market finance teams. It runs its production application on a single public cloud provider’s EU region, uses a third-party payroll processor for staff payroll, and maintains a small head-office network used only for corporate email and laptops, which never touches customer data. Northbridge is also an important entity under NIS2, but its ISO 27001 project is driven by a narrower, recurring blocker: enterprise prospects’ procurement teams keep asking for a certificate before they’ll sign.

A scope statement addressing clause 4.3 for Northbridge might read, in substance:

“The scope of the Information Security Management System covers the design, development, hosting, and operation of the Northbridge Ledger SaaS application and the customer data it processes, including the production and staging environments hosted in [cloud provider]’s EU region, and all Northbridge employees and contractors with access to those environments or to customer data. This scope was determined considering: the competitive requirement, raised repeatedly by prospective enterprise customers during procurement, to demonstrate independently certified information security practices (interested party requirement, clause 4.2); Northbridge’s existing obligations as an important entity under the NIS2 Directive, which apply at the whole-entity level and are addressed separately (external issue, clause 4.1); and the organisation’s dependency on its cloud infrastructure provider and third-party payroll processor, neither of which falls within this ISMS but both of which are managed through the Supplier Security Policy (interfaces and dependencies, clause 4.3). The corporate head-office network, used solely for internal email and administrative systems with no access to customer data or production environments, is excluded from scope; this exclusion does not affect the ISMS’s ability to protect in-scope information, as confirmed by the risk assessment.”

Notice what the example does: it names the boundary in concrete terms, ties it to a specific interested party requirement rather than a vague “security is important” statement, surfaces the cloud and payroll dependencies instead of ignoring them, and justifies its one exclusion on the substantive grounds clause 4.3 requires — not on cost.

What Comes After Scoping

Once the boundary is fixed, two things become possible. A gap analysis can measure your actual distance from compliance, because it needs a fixed boundary to measure against — running one before scope is settled just means re-running it later. And a Statement of Applicability can be built, working through which of the 93 Annex A controls apply inside that boundary and which are justifiably excluded, using the same discipline as scope exclusions. Both documents inherit their shape from the scope statement, which is why getting this one right first matters more than it looks like it should.

FAQ

Does the ISMS scope have to match my company’s full legal entity structure?
No. Clause 4.3 allows scope to cover a subset of the legal entity — a product line, a business unit, a single site — provided the boundary is documented, exclusions are justified, and the scope doesn’t misrepresent what’s covered to interested parties relying on the certificate. [1][2]

Can I exclude a system just because securing it would be expensive or slow?
No. An exclusion must be justified on the basis that it doesn’t affect the organisation’s ability to meet the standard’s requirements or protect in-scope information — cost or convenience alone isn’t a valid clause 4.3 justification. [2]

If my organisation already has NIS2 obligations, should my ISO 27001 scope match my NIS2 scope?
Not necessarily. NIS2 applies to the entity as a whole under Article 3. [3] ISO 27001 scope is a separate decision under clause 4.3 and can legitimately be narrower — as long as that’s deliberate and documented, not an oversight found during a customer’s due diligence. See our NIS2 vs ISO 27001 comparison for the fuller mapping.

How often does the scope statement need to be revisited?
Whenever something changes the underlying 4.1, 4.2, or 4.3 inputs — a new product line, a major new supplier, an acquisition, or a new customer segment with different requirements. Sources describing clause 4.3 treat scope as documented information reviewed at planned intervals and after significant change, not a one-time decision. [1][2]

Who should own the scope statement inside the company?
Because every later ISMS document inherits its shape from scope, ownership usually sits with whoever is accountable for the overall ISMS project, with sign-off from a senior leader who can speak for the commercial drivers behind the boundary chosen.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] ISO 27001 Clause 4.3: Determining the Scope of the ISMS, ISMS.online
• [2] ISO 27001 Clause 4.3: How to Determine the Scope of Your ISMS, DataGuard
• [3] Directive (EU) 2022/2555 (NIS2 Directive), Article 3 — Essential and important entities, EUR-Lex