ISO 27001 Clause 4.3: how to set an ISMS scope that survives audit

The enterprise questionnaire asks which services your ISO 27001 certificate covers. Your draft scope says "the IT department". The deal waits while you rewrite it. This guide is for security and compliance leads at 25–250-person firms heading for certification. It explains what ISO 27001 Clause 4.3 requires, how to draw and defend the boundary, and how to keep it accurate.

Most of the work is decisions you have already made in your context and stakeholder analysis. What remains is writing the boundary down and defending it.

What does ISO 27001 Clause 4.3 require of your ISMS scope?

ISO 27001 Clause 4.3 requires you to decide where the information security management system begins and ends, and to keep that decision as documented information. The boundary follows from your Clause 4.1 context, your Clause 4.2 stakeholder obligations, and the interfaces with suppliers and cloud providers. Everything the certificate claims is bounded by it.

The clause is less a fresh task than a conclusion. Three inputs decide where the line falls:

• Context (Clause 4.1). The internal and external issues you identified, such as the services you sell and the markets you operate in.
• Stakeholder obligations (Clause 4.2). What customers, regulators and partners require of you, including contractual promises about their data.
• The joins. The points where what you run meets what suppliers and cloud providers run for you. Founders tend to underweight this input.

The scope statement is where the ISMS acquires physical, logical and geographical edges. It names the legal entities, services, sites, people and systems the management system governs, and where responsibility hands over to someone else.

Clause 4.3 is unusual among the context-setting clauses because its output must exist in writing. Clause 7.5 governs how that document is controlled.

Why does your ISMS scope wording decide enterprise deals?

Enterprise procurement teams read the scope printed on your certificate to learn what the certification actually covers. A certificate scoped to the IT department of a SaaS business fails diligence on sight, because the product platform sits outside it. Scope is the most commercially consequential sentence in the certification.

Scope errors cost you in both directions. Too narrow, and the assets clients care about sit outside governance, so the certificate reassures nobody. Too broad, and every audit cycle drags irrelevant systems through evidence collection. Reviewers compare the wording of your ISO 27001 scope of certification with the service they are buying, and any gap becomes a diligence question.

A scope drawn around the office network certifies the building, not the business.

The contractual dimension can settle the question before you start. A client contract that promises certified handling of their data decides the scope for you: whatever service touches that data belongs inside the boundary. Read each major client contract for the service it names before you draft a word. If two contracts name different services, the scope must cover both.

How do you draw the ISMS boundary along your data flows?

Start from the service the certificate must vouch for. Then work outward to everything it depends on: the platform, the corporate systems around it, and supporting functions such as people operations and finance. Trace where client and personal data actually lives and moves, and let those flows, not the org chart, place the boundary.

An org chart shows teams. It does not show that support exports ticket attachments into a SaaS helpdesk, or that a contractor's laptop syncs a customer folder. Ask about each place client and personal information lives or moves:

• Endpoints: laptops, phones and any personal devices that hold or sync client data.
• Cloud tenants: production accounts, plus staging and analytics environments that copy production data.
• SaaS tools: ticketing, CRM, file sharing, messaging and anywhere people paste data.
• Sub-processors: suppliers that handle client data on your behalf.
• Cross-border hops: places where data is stored, backed up or supported from outside the UK.

Supporting functions belong on the map too. People operations holds employee records and runs onboarding and leavers, finance pays suppliers, and facilities controls the physical sites. Each either sits inside the boundary or is separated from it on purpose.

Allow a few days of work once the outputs of Clauses 4.1 and 4.2 exist. The scope gates the risk assessment, because you cannot assess what you have not bounded. At certification, it is also what the auditor prices the audit against.

The certificate wording that comes out of this work is usually one sentence. For a 60-person SaaS firm it might read: "The information security management system supporting the development, hosting and support of the Example platform, operated from the London office and UK remote locations, in accordance with the Statement of Applicability version 3." Everything in the supporting detail exists to make that sentence true.

Where does your responsibility end and your cloud provider's begin?

Each cloud or supplier dependency needs a written responsibility split anchored in the contract. The provider runs its platform. As the NCSC shared responsibility model states, you remain responsible for meeting your security needs, configuring the services securely and deciding what data goes in. One simple split per major provider is enough at this scale.

The NCSC guidance on cloud security and the shared responsibility model makes the split a statement about your controls, not the provider's. The line moves with the service model, and a typical division looks like this:

• IaaS: the provider runs the physical estate and virtualisation; you run operating systems, patching, network rules, identity and data.
• PaaS: the provider runs the runtime and underlying platform; you own application code, configuration, access and data.
• SaaS: the provider runs the application; you own tenant configuration, user access and what data goes in.

Suppliers beyond the big cloud platforms need the same treatment. The NCSC supply chain security principles call for a common understanding with suppliers of each party's security responsibilities, including which subcontracting decisions you are happy to delegate. Your contract schedules are where that understanding is recorded.

A short table per major provider is the evidence. For each service, record:

• who configures it;
• who patches it;
• who monitors it;
• who responds to incidents;
• the contract clause behind each answer.

When the auditor asks where your responsibility ends for a given service, you hand over that table.

How should the scope treat remote work, BYOD and contractors?

Treat them as in scope wherever they touch in-scope information. Remote and hybrid working, personal and mobile devices, contractor access and cross-border data hops are the boundary cases auditors probe, not the tidy architecture diagram. Name each one in the scope supporting detail and state how its equipment and access are governed.

A sentence or two per case is usually enough:

• Remote and hybrid working: state that home working falls inside the boundary, and which device and network protections apply.
• Personal and mobile devices: say whether BYOD is allowed. If it is, record what access it gets and how data stays off it. If not, say so.
• Contractor access: record which contractors reach in-scope systems or data, on whose devices, under which agreement.
• Cross-border data hops: list the countries where in-scope data is stored, processed or supported from.

The scope only places these cases inside the boundary. The controls that govern them sit in Annex A: 6.7 covers remote working and 8.1 covers user endpoint devices. Point each paragraph at the control and the policy behind it, so an auditor can follow the line from boundary to control.

At 25–250 people, these edges are where much of the daily work happens. A few honest sentences here make the statement describe how your people actually work.

Should you scope the whole organisation or only part of it?

You can bound the ISMS to specific services or entities if dependencies and obligations still hold together. For a 25–250-person firm, whole-organisation scope is usually simpler and cheaper than policing an internal boundary, and reads better to buyers. Partial scope is a choice to justify, not a default.

An internal boundary has a running cost. Someone must keep in-scope and out-of-scope people, networks and tools apart, evidence the separation, and answer the auditor's question about what shares infrastructure. At this size, that effort usually exceeds the cost of bringing everyone under the same controls.

Partial scope holds together when all of these are true:

• A distinct service has its own platform, team and data.
• No in-scope information flows into the excluded part.
• The obligations you identified under Clause 4.2 still hold with the narrower boundary.
• A buyer can tell from the certificate wording which service is covered.

The opposite error is sweeping in every legacy system and dormant entity. You then pay for it in audit days and evidence load every year, for assets that add no assurance for your buyers. Retire or genuinely separate them first, then draw the line.

When is an exclusion from the ISMS scope defensible?

An exclusion is defensible only when you can show in writing that the excluded part neither touches in-scope information nor undermines the controls. That proof rests on genuine technical, physical or risk-based separation. Convenience is not a case. Unjustified exclusions are among the most common early-audit findings, and assessors treat them as a red flag.

A written exclusion case answers five questions:

1. What is excluded? Name the system, team, entity or site precisely.
2. Why does it hold no in-scope information? Point to the data flows.
3. What separates it? Network segmentation, separate accounts and identity, physical separation, or a risk-based argument.
4. What did you check? Show that nothing in scope depends on it, including shared infrastructure.
5. Who approved it, and when? Record the decision at management level.

An exclusion with no written case isn't a boundary decision. It's an undeclared risk.

Write the case for a hostile reader. They will look for the shared admin account, the common file share or the single identity provider that quietly joins the two sides.

The weakest exclusion is a department left out "because it's not technical". Its people still handle email, documents and customer details. One unreasoned exclusion makes an assessor doubt the reasoning behind the rest of the system.

What evidence and audit questions come with the ISMS scope?

Clause 4.3 requires the scope to exist as a written, controlled document. In practice that is an approved, versioned statement of a page or two, with data flows, architecture and responsibility splits behind it. Auditors then test it by sampling excluded systems and asking what has changed since approval.

Keep the statement and its supporting evidence together:

• The approved, versioned scope statement naming the entities, services, locations and technology estate covered.
• Written justification for each exclusion, backed by risk analysis or demonstrated separation.
• Data-flow and architecture diagrams showing where the line is drawn.
• Supplier and cloud responsibility splits, as contract schedules or RACI-style tables.
• Management approval records, plus the review and change history.

Expect these questions in the room:

• "Read me your scope. What is deliberately outside it, and how do you know nothing inside depends on it?"
• "Where does your responsibility end and your cloud provider's begin for this service?"
• "Your engineers work from home. How does the boundary treat their equipment and access?"
• "What has changed in the business since this statement was approved, and why hasn't the statement changed?"

The auditor will pick an excluded system or team and hunt for in-scope data or shared infrastructure inside it. They will also compare the certificate wording with what your sales materials claim is covered, so keep marketing copy and scope statement aligned.

In our reading of certification practice, findings against this clause grade in three ways:

• Major: no documented scope, or an exclusion that conceals unmanaged risk.
• Minor: vague boundary language, missing version control, or a statement left un-updated after a known change.
• Pattern risk: repeated minors aggregating into a major.

How do you keep the ISMS scope accurate as the business changes?

Treat scope as a live inventory. Derive the technology half of the boundary from your asset and cloud-account inventory. Then let a new cloud account, sub-processor or legal entity open a scope-review task automatically. Drift then becomes detectable continuously, instead of being discovered at audit two migrations later.

The inventory usually exists already, because cloud accounts, endpoints and SaaS subscriptions are tracked for security reasons. Comparing it with the scope statement turns a memory exercise into a routine check. Each task asks one question of the scope owner: in, or out with a written case?

Store the per-provider responsibility splits as structured records tied to contracts. The "who patches what" answer is then retrievable during an incident, not only at audit.

When the auditor asks what has changed since approval, the answer is already in your trigger log, along with the decision taken on each change.

At this scale, continuous drift detection satisfies auditors and enterprise buyers from the same record.

Frequently asked questions