ISO 27001 Scope: The Complete 2026 Guide to Defining Your ISMS

Your ISO 27001 scope is the single decision that shapes everything else in your certification project: how many controls you have to implement, how many audit days you pay for, and what your customers actually read on the certificate you send them. Get it right and a lean, defensible ISMS carries you through Stage 2. Get it wrong and you either buy months of unnecessary work or hand a prospect a certificate that does not cover the product they are buying.

This ISO 27001 scope guide covers what Clause 4.3 requires, the three scoping models real companies use, a worked scope statement you can adapt, and the exclusions auditors reject.

What ISO 27001 scope means under Clause 4.3

Clause 4.3 of ISO/IEC 27001:2022 requires you to determine the boundaries and applicability of the information security management system in order to establish its scope. It is one of the shortest clauses in the standard and one of the most consequential. In setting those boundaries you must consider three things:

• The external and internal issues you identified under Clause 4.1 — your market, your regulators, your technology estate, your org structure.
• The requirements of interested parties from Clause 4.2 — customers, regulators, investors, staff.
• The interfaces and dependencies between what your organization does and what other organizations do on your behalf. This forces you to be explicit about where your responsibility ends and your cloud provider’s or outsourced NOC’s begins.

Clause 4.3 then adds one hard requirement: the scope shall be available as documented information. In practice that means a short written scope statement, approved by management, that an auditor can read on day one. Turning up to Stage 1 without one is a fast route to a major finding, because the auditor has nothing against which to plan the assessment.

One confusion is worth clearing up early. ISO 27001 scope defines which parts of the organization the ISMS covers. It is not the same thing as deciding which Annex A controls apply — that judgement belongs in the Statement of Applicability under Clause 6.1.3(d), where each of the 93 Annex A controls is marked applicable or not with a justification. Scope draws the fence. The SoA decides what you build inside it.

Why your ISO 27001 scope drives cost, timeline and sales

Scope is not an administrative formality. It is a budget lever with three distinct effects.

Audit days. Accredited certification bodies size audits using IAF MD 5, which bases the calculation on the effective number of personnel — and critically, only personnel inside the certification scope, adjusted for locations and complexity. A scope covering 40 people in one product team costs materially fewer auditor days than one covering 300 people across four offices. At typical US auditor rates in the region of $1,400 to $2,500 a day, every avoidable day is real money.

Implementation effort. Every system, location and team inside the boundary needs risk assessment, control implementation and evidence. A tight ISO 27001 scope means fewer asset owners to chase and a shorter path to closing out your ISO 27001 gap analysis.

Commercial value. The scope statement is printed on the certificate, and procurement teams read it. If your certificate says “corporate IT services” and you sell a SaaS platform, it does not answer the question the buyer asked, and you will still be filling in security questionnaires. This is the most expensive scoping mistake, because it surfaces only after you have paid for the audit.

For context, the ISO Survey 2024 reported 96,709 valid ISO/IEC 27001 certificates covering 179,877 sites — roughly two sites per certificate, which suggests most organizations scope to a slice of the business rather than the whole entity. That survey switched to IAF CertSearch data rather than voluntary reporting, so comparisons with earlier years are not like-for-like.

Three ISO 27001 scope models compared

Almost every scoping conversation lands on one of three patterns. Choose deliberately rather than by default.

Model	What it covers	Best for	Trade-off
Product or service scope	One platform, its supporting infrastructure, and the teams that build and run it	SaaS and tech companies where one product drives revenue and customer security reviews	Shared functions such as HR, finance and IT support sit on the boundary and need clean interface documentation
Business unit scope	A named division, its people, sites and systems	Larger groups certifying one regulated or customer-facing unit first	Group-level services are dependencies you do not control, so expect scrutiny of the interfaces
Whole-organization scope	All entities, sites, people and systems	Smaller companies under roughly 150 staff, or firms whose customers demand entity-level assurance	Highest audit day count and longest implementation; every acquisition and new office lands inside the boundary

A practical rule from the audit side: if a system, team or location is materially involved in delivering the service customers are asking about, put it in. If you are excluding something purely because it looks like work, you have found a control gap, not a scoping decision.

What belongs in an ISO 27001 scope statement

A defensible scope statement is short, usually 100 to 250 words, but it must answer five questions without ambiguity:

1. Organizational boundary. Which legal entity, division or teams. Name them.
2. Physical boundary. Which offices, data centres or cloud regions. Include remote workers explicitly if your workforce is distributed, because auditors will ask.
3. Logical boundary. Which products, systems, networks and information types. Be specific enough that someone could draw the line on an architecture diagram.
4. Interfaces and dependencies. The outsourced or shared services you rely on, and who owns security for each. This is the Clause 4.3 requirement most people skip.
5. Exclusions. What is deliberately outside, and why it does not undermine the security of what is inside.

Keep it in a versioned, management-approved document. Most toolkits ship this as a combined context and scope document, so the Clause 4.1, 4.2 and 4.3 outputs stay consistent, which is how an auditor will read them.

A worked scope statement example

Here is the shape of a statement that survives audit at a mid-sized SaaS business:

The information security management system covers the design, development, hosting and support of the Acme Analytics Platform, including all customer data processed by the platform. It covers the Engineering, Site Reliability, Customer Support and Information Security teams, the London head office at [address], and remote workers in the UK and Ireland. Production infrastructure is hosted in AWS eu-west-1 and eu-west-2 under the AWS shared responsibility model, with Acme responsible for configuration, access management, data and application security.

Payroll processing is performed by [provider] under contract and is outside the scope of the ISMS; no customer data is shared with the payroll provider. The corporate marketing website is a static site hosted separately, holds no customer or personal data beyond contact form submissions, and is outside the scope. Version 2.1, approved by the ISMS Steering Group on [date].

Notice what that does: it names teams, locations and cloud regions, states the split of responsibility with the hosting provider, and gives a reason for each exclusion. An auditor reading it knows exactly what to sample.

Exclusions auditors accept and the ones they reject

ISO 27001:2022 does not contain a formal “justify your exclusions” requirement in the way ISO 9001 does for non-applicable clauses. What Clause 4.3 does demand is that you have considered interfaces and dependencies. In practice, auditors test exclusions by asking one question: does information inside the scope flow through the excluded thing? If it does, the exclusion fails.

Exclusions that hold up:

• A static marketing site with no customer or sensitive data.
• Facilities management performed by a landlord under a lease, where physical security responsibilities are contractually defined.
• A legacy product with a published end-of-life date and no shared infrastructure with in-scope systems.
• A subsidiary in a different market with fully separate systems, staff and network.

Exclusions that get challenged:

• Excluding the development team while certifying the product they build. The build pipeline is an attack path into production.
• Excluding HR while relying on Annex A people controls such as screening, terms of employment and the disciplinary process.
• Excluding a whole office where in-scope staff actually work.
• Excluding “the cloud” on the basis that the provider is certified. Their certificate covers their layer, not your configuration, identities or data.
• Excluding a system because it is due to be replaced, with no decommissioning date.

Five steps to setting your ISO 27001 scope

1. Start from the commercial question. Write down the sentence a prospect needs to read on your certificate, then work backwards rather than forwards from your org chart.
2. Map the information flows. Follow customer data from ingestion to deletion. Every system, team and third party it touches is a candidate for inclusion.
3. Draw the boundary and list the crossings. Anything that crosses the line is an interface. Document who owns security on each side and what contract backs it.
4. Pressure-test the exclusions. For each one, answer in writing why removing it does not weaken security inside the boundary. If the answer is uncomfortable, move the boundary.
5. Get it approved and put it under change control. Scope changes when you add a product, office or acquisition, and your certification body needs to know. An unreported change is a finding at surveillance.

Do this before risk assessment, not after. Scoping late means re-running the risk assessment, and that is where projects lose a month. For the full sequence from context to certification, our ISO 27001 implementation guide lays out the order of work, and the ISO 27001 certification guide covers what Stage 1 and Stage 2 auditors look for.

Scoping mistakes that cost an extra audit

Four patterns show up repeatedly in delayed or failed certifications.

Scope written after the risk assessment. The risk assessment then covers assets the scope excludes, or misses assets it includes, and the inconsistency is obvious in documentation review.

Scope statement that contradicts the SoA. If you have excluded physical premises but marked the 14 physical controls as applicable without explanation, the auditor will pull that thread.

Vague wording. “Information security across the business” tells a buyer nothing and gives the auditor no sampling boundary. Name the product, the teams, the locations.

Scope that never changes. Companies grow. If your certificate still describes a single office two acquisitions later, your ISO 27001 scope is inaccurate and the certificate is arguably misleading.

ISO 27001 scope questions buyers ask

Can I certify only part of my company?

Yes. Partial scope is normal and legitimate, provided the boundary is coherent and the interfaces with the rest of the business are documented and controlled. What you cannot do is claim the certificate covers more than it says.

Does a smaller scope mean a cheaper audit?

Generally yes, because certification bodies size audits on the effective number of personnel inside the scope, plus locations and complexity, under IAF MD 5. A narrower ISO 27001 scope reduces audit days and implementation effort. It also reduces the commercial value of the certificate, so the saving is only real if the scope still covers what customers are asking about.

Do I have to include remote workers?

If they handle in-scope information, yes. Remote and hybrid working is a boundary condition, not an exclusion. State it explicitly and support it with a remote working policy, endpoint controls and access management.

Can I change the scope after certification?

Yes, but tell your certification body. Extending scope usually requires an extension audit; reducing it is normally handled at surveillance or recertification. An undeclared change is a nonconformity waiting to happen.

Does the scope statement appear on the certificate?

Yes. The wording on your certificate is derived from your documented ISO 27001 scope statement, which is why the drafting deserves real attention. It is the sentence your customers will read.

Getting the documentation right

The scope statement is one document, but it only works when the context analysis, risk assessment, Statement of Applicability and policies line up behind it. Our ISO 27001 Toolkit includes 162 editable ISMS templates — context and scope, risk assessment, an SoA covering all 93 Annex A controls, policies and audit checklists — for $99, so you start from a structure that already matches how a certification audit is run rather than drafting from a blank page.

Scope well, document it plainly, and keep it current. Time spent on your ISO 27001 scope is the cheapest hour of the whole project.