To scope an ISO 27001 ISMS, decide which products, locations, people, systems and suppliers the management system covers, write down what sits outside and why, and describe every interface across the boundary. Scope should match what a customer is buying from you, not the smallest set that looks easy to pass.
Why does scope come first?
ISO 27001 clause 4 asks you to understand your organisation's context, identify interested parties and their requirements, and then determine the scope of the information security management system. Every later step depends on it. The risk assessment covers the scope, the Statement of Applicability is drawn up for it, internal audits sample it and the certification body audits it. A vague scope produces vague evidence.
A caveat on sources: the ISO pages for the standard returned a 403 to our fetch, and the full text is paid. This guide relies on the structure of the 2022 edition as widely described, including clauses 4 to 10 and the 93 controls of Annex A in four themes. Check precise wording against your licensed copy.
What goes into a scope statement?
A good scope statement is short and testable. It names five things.
- Products and services. For example the hosted application your customers log into, and the support function around it.
- Locations. Offices, data centres, cloud regions and any home working arrangements you intend to cover.
- Organisational units and people. Which teams and roles are inside.
- Assets and systems. Production environments, source control, build pipeline, corporate identity provider, endpoint fleet.
- Exclusions with reasons. A sales tool with no customer data, a separate legacy product, a subsidiary under another management.
Then add an interface table. For each place where the in-scope system exchanges data with something out of scope, record what flows, how it is protected and who is responsible. Auditors tend to start there, because boundaries leak at interfaces.
How wide should it be?
Think from the buyer's side. If your customers send you a questionnaire about your platform, and your certificate excludes the platform's build pipeline, you have a certificate that does not answer the question. A scope that is too small is cheap to achieve and weak to sell.
Too wide has a cost as well. Every system in scope needs risk assessment, control decisions and evidence, so adding a rarely used marketing tool costs time without raising trust.
A practical middle path for a software company is to include everything that can affect the confidentiality, integrity or availability of customer data in the product: code, build, deployment, production, identity, endpoints used by engineers and support staff, and the key suppliers. Add corporate functions such as HR for the controls that touch people, because the people theme of Annex A will be tested.
How do suppliers and cloud providers fit?
You cannot exclude a supplier that runs your production. You can treat the provider's own infrastructure controls as theirs while keeping your configuration of it in scope. Record the shared responsibility split in writing, collect the supplier's assurance reports, and note any controls that you rely on them for. The Statement of Applicability should say so.
What mistakes are common?
- Writing scope as a marketing sentence instead of a boundary.
- Leaving out the build pipeline and source code.
- Excluding a system but letting it connect to production with no interface record.
- Forgetting remote workers and personal devices.
- Changing scope halfway through to avoid a gap, which the auditor will see in the records.
What to do
- List interested parties and what each requires, including customers, regulators and staff.
- Draft the scope in the five parts above, and have top management approve it.
- Draw the boundary on an architecture diagram with interfaces numbered.
- Complete the interface table with data, protection and owner.
- Record each exclusion with its reason.
- Revisit scope when you launch a product, enter a country or change a major supplier.
Quick check
Can I leave production out of an ISO 27001 scope?
You can write any scope, but a certificate that excludes the systems customers rely on does not answer their questions, and auditors will probe the interfaces.
Who approves the scope?
Top management should approve it, since clause 5 puts leadership commitment and the ISMS policy on them.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. Once scope is set, the technical part of your inventory can come from your real repositories and dependencies through scans and SBOMs, so the asset list is generated rather than typed. Monitoring then watches the boundary systems between audits, which gives the team time for other work. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. A certification body does the audit. Safeguard helps you prepare and keep evidence ready. Book a call to walk through it.
Sources
- ISO/IEC 27001 page on iso.org, not retrievable (HTTP 403) on 18 October 2026, so claims are kept general
Last reviewed: 18 October 2026.
