How to Write an ISO 27001 Scope Statement (With Examples)

An ISO 27001 scope statement defines the boundaries of your information security management system (ISMS): which parts of the organization, which products and services, which locations and which systems it covers. It is required by clause 4.3 of ISO/IEC 27001:2022, and it is the first thing a certification auditor reads. A clear scope keeps your project focused and makes your certificate meaningful to customers.

Related guides: ISO 27001 for small businesses · ISO 27001 Statement of Applicability template · ISO 27001 Annex A controls

Key takeaways

• The scope statement says what the ISMS covers: organizational units, products and services, locations, assets and technology.
• Clause 4.3 requires you to consider internal and external issues, interested party requirements and interfaces and dependencies with others.
• The scope appears on your certificate, so customers read it. Make sure it covers what they buy.
• A narrow scope is faster to certify, but too narrow a scope can fail to satisfy customers.

---

What does ISO 27001 clause 4.3 require?

Clause 4.3 asks you to determine the boundaries and applicability of the ISMS. When doing so, you must consider:

1. The external and internal issues identified under clause 4.1, such as market, legal, technology and organizational factors
2. The requirements of interested parties identified under clause 4.2, such as customers, regulators and investors
3. The interfaces and dependencies between activities you perform and those performed by other organizations, such as your cloud provider or outsourced support

The scope must be available as documented information. In practice that means a short scope document, usually one or two pages, approved by leadership.

What to include in an ISO 27001 scope statement

Element	What to write	Example
Organization	Legal entity and units in scope	Acme Software Ltd, product, engineering, support and security teams
Products and services	What the ISMS protects	Development, operation and support of the Acme SaaS platform
Locations	Offices and remote working	London office and remote employees in the UK and EU
Information and assets	Main data and asset types	Customer data, source code, production infrastructure, corporate devices
Technology	Key platforms	Production hosted on AWS eu-west-2; Google Workspace; GitHub
Interfaces and dependencies	Outside parties you rely on	AWS for hosting, Stripe for payments, outsourced penetration testing
Exclusions	Anything left out and why	Marketing website hosted by a third party, as it holds no customer data
Standard version	Which edition	ISO/IEC 27001:2022, Statement of Applicability version 1.2

ISO 27001 scope statement examples

Example 1: early-stage SaaS company

"The information security management system of Acme Software Ltd covers the development, operation, maintenance and support of the Acme customer analytics SaaS platform, including the people, processes and technology used to provide it, performed by staff working from the London office and remotely, with production services hosted on AWS. This is in accordance with the Statement of Applicability version 1.2."

Example 2: company with several products

"The ISMS covers the design, development, hosting and support of the Acme Payments and Acme Reporting platforms, provided by the product, engineering, operations and customer success teams of Acme Inc. in New York and Berlin. The Acme Labs research division is excluded, as it does not process customer data or connect to production systems."

Example 3: certificate wording

Certificates usually show a short version, such as: "Information security management system for the development, hosting and support of the Acme SaaS platform."

How to write your scope in five steps

1. Start from what customers buy. List the products and services named in your contracts and security questionnaires.
2. Map the people and systems behind them. Include every team and tool that touches customer data or production.
3. Identify interfaces and dependencies. List cloud providers, critical SaaS tools and outsourced services, and how you manage the risk they bring.
4. Decide on exclusions carefully. Exclude only what has no meaningful connection to the in-scope service, and document why.
5. Review with leadership and your certification body. Agree the scope before Stage 1 so there are no surprises.

Common scoping mistakes

• Scope too narrow: certifying only "the security team" or one office does not help customers who buy your whole product.
• Scope too broad: including every department and legacy system at once can double the effort for a first certification.
• Missing dependencies: forgetting the cloud provider or a critical subprocessor leaves gaps in supplier controls.
• Remote work ignored: if staff work from home, remote working must be in scope with suitable controls.
• Scope and SoA out of sync: the Statement of Applicability must match the scope you declared.

How the scope connects to the rest of the ISMS

The scope is not a standalone document. It drives several other parts of ISO 27001:

ISMS element	How the scope affects it
Asset inventory	Lists the information, systems and devices inside the scope
Risk assessment	Covers risks to assets in scope only
Statement of Applicability	Justifies which Annex A controls apply within the scope
Supplier management	Covers the suppliers named as interfaces and dependencies
Internal audit	Plans audits across every part of the scope over the cycle
Certification audit days	Auditor time is calculated from the people and sites in scope

If any of these documents cover a different boundary than the scope statement, auditors will raise it. Keep them aligned whenever the scope changes.

Scoping remote-first companies

Many SaaS companies have no office. In that case, state that staff work remotely, name the countries they work from, and include remote working controls such as device encryption, secure home network guidance and screen lock. Physical security controls for offices may be excluded with a justification, but equipment security still applies.

Scope and other frameworks

If you also have SOC 2, align the ISO 27001 scope with your SOC 2 system description so one set of controls and evidence serves both. Differences are fine, but they should be deliberate.

How SecureSlate helps

SecureSlate helps you define your ISO 27001 scope, link it to your asset inventory, risk register and Statement of Applicability, and keep all three in sync as your company grows.

FAQ

Is the ISO 27001 scope statement mandatory?

Yes. Clause 4.3 requires the scope of the ISMS to be determined and available as documented information.

Can we exclude part of the company from the ISO 27001 scope?

Yes, as long as the exclusion is justified and the remaining scope still makes sense. Exclusions should not hide risks to the services customers rely on.

Does the scope appear on the certificate?

Yes. A summary of the scope is printed on the certificate, which is why customers check it.

Can we expand the scope later?

Yes. Many companies start with their main product and extend the scope at a surveillance or recertification audit.

What is the difference between the scope and the Statement of Applicability?

The scope defines what the ISMS covers. The Statement of Applicability lists which Annex A controls apply within that scope and why.

---

How long should an ISO 27001 scope statement be?

Usually a few paragraphs to two pages, plus any supporting lists of locations, systems and dependencies. Clarity matters more than length.

Does the scope need to include our cloud provider?

The cloud provider is usually outside your scope but listed as a dependency. You manage the risk through supplier controls, such as reviewing its certifications and configuring its services securely.

Who approves the ISO 27001 scope?

Top management should approve it, and the approval should be recorded as part of your ISMS documentation.

Can the ISO 27001 scope differ from our SOC 2 scope?

Yes. They often differ slightly, for example ISO 27001 covering the whole company and SOC 2 one product. Document the reason and keep shared controls consistent.

What if our scope is too narrow for a customer?

Explain what is covered and how other areas are protected, and consider extending the scope at your next surveillance or recertification audit.

Is a narrow scope a red flag for customers?

Only if it leaves out what they buy. A focused scope covering the product and the teams behind it is normal and respected.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. Requirements vary by framework, industry, and jurisdiction. Consult qualified advisors for your specific obligations.