ISO 27001 scope statement: products, sites, vendors

On day one of a certification audit, the ISO 27001 scope statement is usually the first document an auditor opens. Everything after that gets read against it: your context analysis, your risk assessment, your Statement of Applicability. If the boundary you wrote down does not match how the business actually operates, the inconsistency shows up quickly.

This guide walks you through defining scope before a first audit, with a practical method for mapping products, locations, systems, and third-party interfaces. It draws on what certification auditors say they look for in the ISO 27001 webinars Secfix hosts with certification auditors, plus the themes discussed in those sessions.

What you'll need before you start

Scope is not a drafting exercise you can finish in an afternoon. Before you write a single line, pull these together:

• Your clause 4.1 output: the internal and external issues that affect information security, such as your market, regulatory exposure, and technology stack.

• Your clause 4.2 output: the interested parties and their requirements, including customers, regulators, investors, and key suppliers.

• A clear list of what customers actually buy from you, product by product.

• An inventory of offices, cloud regions, core systems, and the vendors that process data on your behalf.

• A named owner for the ISMS scope requirement in clause 4.3, usually whoever runs the compliance program.

If you are a small team without a full-time CISO, assign one person to hold the pen and a second to sanity-check it against sales commitments. That is enough.

Step 1: Identify your organization's context and interested parties

Start where the standard tells you to start. Clauses 4.1 and 4.2 are the designated inputs to scope, and auditors check them for consistency with the boundary you declare.

Write down what each interested party expects. Enterprise buyers usually expect the product they license to be covered. A regulator cares about a specific data category. An investor doing security diligence cares that the certificate is not cosmetic. Then capture the contractual obligations already in your agreements, because those commitments constrain the scope whether you acknowledge them or not.

The output of this step is a short list: parties, their requirements, and the processes that satisfy those requirements. That list is what you scope around. Starting instead from an internal org chart is a common way first-time programs go wrong, and it is a well-documented pitfall in frequent ISO 27001 implementation mistakes.

Step 2: Map products, services, and supporting functions

Scope follows your core business. Map the functions that develop, run, and support what customers pay for: engineering, infrastructure operations, customer support, and the HR and access processes that govern the people doing that work.

Auditors are clear about the failure mode: a development company that scopes only its HR department leaves out exactly the development work its customers care about.

If you run two distinct products, the question is not whether certifying one is technically allowed. It is whether your buyers will read the certificate as covering both. Let customer expectations decide. Where both products share an engineering organization, a deployment pipeline, and an identity provider, including both usually costs little extra effort. Where the second product is a separate codebase with a separate team and no enterprise customers asking about it, a single-product scope is defensible as long as the certificate text says so clearly.

Step 3: Document locations, systems, and third-party interfaces

List every physical and logical location that supports in-scope services: offices, co-working arrangements, cloud regions, and remote working as a mode of operation. If you are fully remote and cloud-hosted, say so. Physical security of an office may not be part of the scope if there is no office, and auditors would rather see that stated than invented.

Cloud dependency is now the default rather than the exception. According to Eurostat, 52.7% of EU enterprises used paid cloud computing services in 2025, up 7.4 percentage points from 2023, with 85.2% using them for email, 71.7% for office software, and 71.5% for file storage (Eurostat). Those services hold in-scope information, so name them.

Hosting is rarely uniform, either. In 2025 to 2026, 31% of UK businesses handling digitized data used a public cloud provider, 27% used servers on business premises, and 19% used a private cloud, according to the UK Department for Science, Innovation and Technology (UK Business Data Survey 2026). If you run a hybrid setup, the scope statement should reflect both halves.

Finally, document the interfaces: which vendors receive or process in-scope data, and where your responsibility ends and theirs begins.

Step 4: Draft the scope statement

A workable scope statement is short, specific, and readable by a buyer. Include:

1. The legal organization name and any subsidiaries covered.

2. The locations, including remote working and named cloud regions.

3. The products and services as customers recognize them.

4. The supporting processes: development, operations, support, HR, access management.

5. The key systems and the interfaces to third parties such as cloud providers.

Then calibrate the breadth. Too narrow, and customers question what the certificate really covers. Too wide, and you pay for controls and audit days you do not need. Auditors also warn against stretching the boundary over things that are not live yet: it adds controls and audit effort without value, so only include what is actually running.

Your top-level information security policy should describe the same boundary in the same words. Two documents, one story.

Step 5: Verify consistency across scope, risk assessment, and Statement of Applicability

Auditors review the scope statement, context, interested parties, risk assessment, and Statement of Applicability as a single set. Inconsistencies between them get flagged immediately, which is why what the certification auditor checks is worth rehearsing internally before Stage 1.

Run a simple cross-check. For each in-scope service, location, and vendor, confirm there is at least one corresponding entry in the risk register. Then reverse the test: for every control marked applicable in the Statement of Applicability, confirm the scope actually contains something it applies to. Physical security controls in a scope with no premises, or a critical cloud provider absent from the supplier risk assessment, are two common mismatches.

Fix the document that is wrong, not the one that is convenient. If the risk assessment reveals a dependency you forgot, widen the scope statement rather than quietly dropping the risk.

Troubleshooting: common scope mistakes

The scope is too vague. "All IT operations" names nothing a buyer can verify. Replace abstractions with named services, locations, and systems.

A product customers expect is missing. If your sales team has been answering security questionnaires about a product that sits outside the boundary, the certificate will create friction instead of removing it.

Vendor interfaces are undocumented. Third-party oversight is thin in the UK data: only 15% of UK businesses formally reviewed cybersecurity risks posed by immediate suppliers, and only 6% assessed their wider supply chain. The same survey found 70% of medium-sized UK businesses used an external cybersecurity provider, compared with 64% of small businesses (UK Department for Science, Innovation and Technology). Outsourced security work belongs in your scope's interfaces and in your risk assessment.

Documents were written in isolation. Context and interested parties drafted by one person, scope by another, and the two contradict each other. Review them together before submission.

Next steps

Circulate the draft to engineering, sales, and leadership before it reaches the certification body. Engineering confirms the systems are real, sales confirms the boundary matches what buyers were promised, and leadership approves the audit effort that comes with it. Keeping your scope, risk register, and Statement of Applicability in one place in Secfix, the compliance automation platform, makes these cross-checks easier to manage.

Key takeaways

• Derive your boundary from clauses 4.1 and 4.2, and discard any scope drafted from the org chart.

• Include the functions that build and run what customers buy, even when a narrower boundary would pass.

• Decide multi-product inclusion by asking what your enterprise buyers assume the certificate covers.

• Cross-check scope, risk assessment, and Statement of Applicability against each other before Stage 1, not after a finding.

• Name offices, cloud regions, and vendor interfaces explicitly rather than describing them generically.

Frequently asked questions

Can I exclude a product or location from the scope?

Yes. Exclusions are permitted, but they must be deliberate, justified, and documented. Auditors will question any gap that conflicts with what customers reasonably expect the certificate to cover, and a weak justification invites a finding.

Does a narrow scope make the certificate less valuable?

It can. The certificate is only as useful as the alignment between its stated boundary and what buyers assume it covers. A tight scope around your core product is credible; a scope that omits the service a customer is buying is not.

Can the scope be extended after certification?

Yes, and extensions are routine. Scope extensions are agreed with your certification body, which may add an extra audit or cover the change at the next scheduled audit. Prepare the risk assessment and Statement of Applicability updates in advance.

What is the minimum a scope statement must contain?

ISO 27001 clause 4.3 does not prescribe a fixed template. The scope must consider the issues from clause 4.1, the requirements from clause 4.2 and the interfaces and dependencies to other organizations. In practice, a good scope statement names the organization, locations, products and services, supporting processes and third-party interfaces such as cloud providers.