ISO 27001 Clause 4.3: How to Define and Document Your ISMS Scope

Of all the decisions you'll make on the road to ISO 27001:2022 certification, few carry as much weight as your ISMS scope. Clause 4.3 requires you to determine the boundaries and applicability of your information security management system — and the scope statement you write will ultimately be printed on your certificate for every customer, partner and auditor to see. Get it right and you focus your effort where it matters; get it wrong and you're paying to protect things nobody asked about, or leaving critical assets outside the fence. This guide walks through what the clause actually demands and how to approach it in practice.

What Clause 4.3 Actually Requires

The standard's wording is short, but each part of it does real work:

Determine boundaries and applicability. You must decide which parts of the organisation — which legal entities, locations, products, services, systems and people — sit inside the ISMS.
Consider Clause 4.1 (internal and external issues). Your scope must respond to the context you've already documented. If remote work is a permanent feature of your operations, a scope that stops at the office perimeter won't stand up.
Consider Clause 4.2 (interested party requirements). If customers, regulators or contracts demand certification over a particular service, that service belongs in scope.
Consider interfaces and dependencies. Modern businesses run on third parties — cloud platforms, managed service providers, outsourced payroll. You must identify where your responsibility ends and a supplier's begins.
Document it. The scope must exist as documented information. Verbal understandings don't count at audit.

---

How to Define Your Scope: A Practical Approach

1. Start with Products and Services

Why It Matters: Certification is ultimately about what you deliver. Customers read your certificate to see whether the service they're buying is covered.
How to Approach It: List everything your organisation offers, then ask two questions of each: do customers expect this to be certified, and does it process information worth protecting? Check existing contracts — many enterprise agreements now specify ISO 27001 coverage explicitly.

2. Map the Supporting Functions

Why It Matters: A product is only as secure as the people, premises, technology and suppliers behind it.
How to Approach It: For each in-scope service, trace the dependencies: which offices, which teams (IT, HR, engineering, support), which systems, which cloud regions and which vendors keep it running. These become part of your boundary.

3. Decide What to Exclude — and Justify It

Why It Matters: Exclusions are legitimate and often sensible. A narrow, well-justified scope keeps costs and bureaucracy down, especially for smaller organisations.
How to Approach It: Document every exclusion with its rationale, and test each one against risk. You cannot exclude something simply because it's inconvenient, and you can't exclude a function whose compromise would undermine the in-scope services.

4. Define Your Third-Party Interfaces

Why It Matters: Auditors routinely probe the demarcation between you and your suppliers. Saying "we use AWS" is not an answer.
How to Approach It: For each critical supplier, record how data flows between you (APIs, portals, file transfers), which controls you operate and which they operate, and what evidence you hold of their security — such as their own ISO 27001 certificate or SOC 2 report. Make sure contracts reflect the split of responsibility you've documented.

---

Writing the Scope Statement

Keep it short and specific. The scope statement is a summary, not an essay. Aim for under 100 words and cover four things:

The legal entity being certified — the exact registered name that will appear on the certificate.
The products and services covered, described plainly (for example, "the design, development and operation of the X platform").
The key locations and infrastructure that support them, where this adds clarity.
A reference to the Statement of Applicability and its version, tying the scope to your control selection.

Avoid vague language like "all information security activities across the business." Auditors treat sweeping statements as an invitation to dig, and they're almost impossible to defend. If your governance and compliance program spans multiple entities, state exactly which ones are in and which are out.

Getting Approval and Keeping It Current

Scope is a leadership decision, not an IT decision. Clause 5.1 requires top management to demonstrate commitment, and the auditor will test it.

Present the draft scope to senior leadership, walking through what's included, what's excluded and why. If they can't explain the exclusions, they haven't really approved them.
Record the approval formally — in board or management review minutes, with a versioned sign-off on the document itself.
Control the document properly. Clause 7.5 applies: your scope statement needs a version history, an owner, and controlled distribution. A stray Word file on someone's laptop is a finding waiting to happen.
Review it when things change. New products, office moves, acquisitions, cloud migrations and new regulations can all invalidate your boundary. Build a scope review into your management review cycle, and revisit it before every surveillance audit. An internal audit is a good forcing function for this.

---

Common Scoping Mistakes We See

Scoping too broadly. Certifying "everything" sounds safe but multiplies audit effort, control overhead and cost — often for parts of the business no customer cares about.
Scoping too narrowly. Shrinking the boundary to dodge hard problems (like a messy legacy environment that still touches customer data) will be unpicked at Stage 1.
Ignoring the golden thread. If an issue raised in Clause 4.1 or a requirement in Clause 4.2 has no reflection in the scope, the auditor will ask why. The three documents must tell one consistent story.
Forgetting interfaces. Critical suppliers missing from the scope usually means they're missing from your risk assessment too — and that's where real exposure lives. Our Risk Register Builder can help you capture those dependencies systematically.

---

Clause 4.3 looks like a paperwork exercise, but it's really a strategy decision: what are we protecting, for whom, and where does our responsibility stop? Invest the workshops, get leadership genuinely across the boundary, and document it tightly. Everything downstream — risk assessment, the Statement of Applicability, audit logistics — becomes easier when the scope is solid. If you'd like hands-on help, our vCISO service guides Australian organisations through exactly this process.

Assess your ISMS readiness with our FREE ISO 27001 Gap Assessment Tool — instant results, no sign-up required.