.png)
%20(1).png)
.svg)
The short answer: Your ISO 27001 scope is the written boundary of the information security management system: the services, sites, teams, systems and suppliers the ISMS covers, and the ones it does not. Clause 4.3 of ISO 27001 requires you to define that boundary, document it, and account for the interfaces with whatever you leave outside it. The scope statement is then printed on your certificate, so it has to cover the service your customers actually buy.
Scope is the first decision in an ISO 27001 project and it sets the price of every decision after it: how many assets go in the risk register, how many controls you justify in the Statement of Applicability, how many audit days the certification body quotes. Buyers have also got better at reading scope statements, and a certificate covering "the Bristol office" when the platform runs from three countries no longer gets waved through.
{{snapshot}}
ISO 27001 scope at a glance
- Clause 4.3 owns it. Determine the boundaries and applicability of the ISMS, consider your 4.1 and 4.2 context and the interfaces with other organisations, and keep it as documented information.
- It goes on the certificate. The scope statement is public. Customers and auditors read it, so write it for them.
- Six dimensions to decide. Locations, business units, services, systems, people and suppliers: each in or out, with a written reason.
- Too small is the expensive mistake. A scope that excludes the thing you sell produces a certificate your customers reject.
- Everything downstream inherits it. Risk assessment, SoA and audit days follow the boundary you draw.
{{/snapshot}}
What clause 4.3 actually asks for
Clause 4.3 is four sentences long. You determine the boundaries and applicability of the ISMS, considering the external and internal issues from clause 4.1, the requirements of interested parties from 4.2, and the interfaces and dependencies between activities you perform and activities other organisations perform for you. The scope must be available as documented information. That is the whole clause, and the clause 4.3 hub takes it line by line.
Notice what it does not say: not the whole company, no prescribed format. The auditor has no checklist beyond those three considerations, which is why the rest of clause 4 matters.
The phrase people skip is "interfaces and dependencies": every point where an in-scope process touches something outside the boundary. The cloud provider hosting your platform. The payroll bureau. You need not pull them inside the scope, but you must name the boundary and manage the relationship, which is what the Annex A supplier controls (5.19 to 5.22) exist for. The full text is at iso.org.
How to decide what sits inside the scope
Work through six dimensions, decide in or out for each, and write down why. The rule for most organisations: scope to the service customers are asking about, add the functions that support it and anything sharing infrastructure or an identity provider with them. Stop there.
| Dimension | Typically in scope | Typically out of scope | Justification to write down |
|---|---|---|---|
| Locations | Offices where in-scope staff work; hosting regions; remote working | A sales office with no access to in-scope data | Which locations process, store or can access in-scope information |
| Business units | Engineering, support, operations, IT, HR (for joiner and leaver controls) | A subsidiary with its own IT and legal identity | Separate systems, separate identity provider, no shared data flows |
| Services | The product or service named in customer contracts | A legacy product being retired; an internal tool with no customer data | What customers buy and what handles their data |
| Systems | Production, code repositories, identity provider, ticketing, corporate laptops | A marketing website with no customer data; a standalone lab network | Whether it holds, processes or grants access to in-scope information |
| People | Employees and contractors with access to in-scope systems or data | Staff in an excluded entity | Access, not job title, decides inclusion |
| Suppliers | Managed as interfaces: hosting provider, MSP, payroll bureau, outsourced development | Their internal controls (their certification, your contract) | Named as a dependency, controlled through supplier management |
The last column is the one that matters at audit. "Out of scope" with no reason gets questioned at stage 1. Valid reasons: separate legal entity with separate systems, no access to in-scope information, service delivered by a supplier with its own assurance. "Too hard" is not one, however carefully phrased.
The fastest way to find your real boundary is to list the assets. If you cannot say which systems hold in-scope data and who administers them, you do not yet know your scope, whatever the draft says. An information asset register that feeds the risk register does that job once, then keeps doing it as systems get added, so drift gets caught before an auditor catches it.
Three ISMS scope statement examples
Scope statements are short: two to five sentences, usually referencing the SoA version. Three you can adapt, with the reasoning that makes each defensible.
Example 1: a SaaS company
"The ISMS covers the design, development, hosting, support and operation of the Acme platform, delivered to customers from AWS eu-west-2, together with the corporate information systems used by Acme Ltd staff working from its London office and remote locations, in accordance with the Statement of Applicability version 3.1."
This names the product, hosting region, legal entity and people. AWS's data centres are an interface, not in scope, managed through supplier controls and AWS's assurance reports. Remote working is named explicitly, because auditors will ask where the engineers actually sit.
Example 2: a managed service provider
"The ISMS covers the provision of managed IT, cloud and cyber-security services to clients, including service desk, remote monitoring and management, backup and privileged access to client environments, delivered from Acme's Manchester operations centre and by remote engineers, in accordance with the Statement of Applicability version 2.0."
Clients ask managed service providers for ISO 27001 because the MSP holds privileged access to their environments. A scope that leaves out the service desk or the RMM tooling leaves out the exact risk the client worries about. Client-owned systems stay outside; the MSP's access to them is inside.
Example 3: a single-site professional services firm
"The ISMS covers the handling of client information in the delivery of consulting services by Acme Advisory LLP from its office at 12 Example Street, Leeds, including the information systems and staff supporting those engagements, in accordance with the Statement of Applicability version 1.2."
One site, one entity, one service line, so the boundary is simple. What matters for a consulting firm is subcontractors and the client-owned systems staff log into. Both are interfaces: the scope document names them, supplier and access controls manage them.
A scope statement template you can fill in
Keep the statement to one paragraph and put the detail in a scope document it references. The certificate carries the paragraph; the auditor reads the document, which needs these sections:
- Organisation and legal entities covered.
- Products and services in scope, using the names customers see in contracts.
- Locations: offices, hosting regions, and whether remote working is included.
- Organisational units and roles inside the boundary, with approximate headcount.
- Systems and networks, either listed or by reference to the information asset register.
- Exclusions, each with a one-line justification.
- Interfaces and dependencies: suppliers, group companies, customers, and how each is controlled.
- Context references: the 4.1 issues and 4.2 requirements the scope responds to.
- Control: owner, approver, version and review trigger.
Write section 6 as if a sceptical customer will read it, because one will. Do not skip the review trigger in section 9, or the scope goes on naming an office you left two years ago.
The scope-too-small trap
It is tempting to certify one team or office to get the badge quickly. The certificate then reads "the information security management system supporting the Bristol office". Your customer buys a platform built by engineers in Bristol, Kraków and a contractor in Lisbon. Procurement compares scope with contract and either rejects the certificate or sends back the questionnaire it was supposed to replace. The scope must cover the service the customer buys end to end, including every team and system that touches its data. Anything narrower was drawn for the convenience of the project, and the market will notice.
The opposite failure is real too. Scoping the whole group, including entities with no connection to the service, doubles audit days and fills the risk register with orphan assets. HealthBoxHR, an HR and payroll SaaS holding sensitive employee data, drew the boundary around the platform and the people running it. In their CTO's words: "Starting without anything in place, we were able to achieve ISO/IEC 27001:2022 certification in 12 weeks." That speed came from a boundary decided in week one and not re-litigated in week eight.
What auditors check about scope
At stage 1 the auditor confirms a documented scope exists, traces back to your 4.1 and 4.2 context, identifies interfaces and dependencies, and agrees with the SoA and the risk assessment. They also settle the certificate wording.
At stage 2 they walk the boundary: an interview with an in-scope engineer about a named system, a trace of customer data to the supplier hosting it, a check that the supplier is actually managed. They also look for in-scope data leaking into out-of-scope places, such as a group file server used by everyone when only one unit is certified, or a shared Active Directory that makes the "separate entity" exclusion untrue.
The findings we see most often are boring and avoidable: a scope naming a location that closed, a scope that says "all systems" while the SoA excludes physical controls, a business unit excluded on paper that shares the in-scope identity provider. An ISO 27001 gap analysis before stage 1 catches all three, because it starts by asking whether the scope, the asset register and the SoA describe the same organisation.
How scope drives the SoA and risk assessment, and how to change it later
Scope is the input to everything that follows. The risk assessment covers the assets inside the boundary and nothing else. The Statement of Applicability justifies each Annex A control against the risks inside that boundary, and a control marked not applicable is defensible only if the scope explains why the risk cannot arise. Change the scope and both change with it.
Changing scope after certification is routine. Extend it at a surveillance or recertification audit: update the scope document, assess the new assets, update the SoA, and tell the certification body, which may add audit days. Reducing scope is possible too, and customers notice.
The same boundary can serve more than one standard. Blue-i Group, an event technology company, certified to ISO 9001, 14001 and 27001 in under two years on one platform, with the context and boundary written once and reused across three management systems.
{{snapshot}}
Hicomply's take
We have read a lot of scope statements and the bad ones fail the same way: they describe the project team rather than the service. Draw the boundary around what customers buy, name every interface honestly, and let the asset register decide the rest. The mistake to avoid is treating scope as a paragraph you write on day one and never open again. Keep it version-controlled next to the SoA with a review trigger, because the moment you add a site or a supplier, the certificate describes a company that no longer exists.
{{/snapshot}}
Draw the boundary once and stop redrawing it
Most scope problems are record-keeping problems: the asset register, the scope document and the SoA drift apart because they live in three places. Keeping them in one system, with the asset register feeding the risk register and the SoA generated from the control set, removes the drift.
Start with the free ISO 27001 readiness assessment to see whether your scope, context and asset list hold together, then book a demo and bring your draft scope statement. We will tell you whether an auditor, or a customer, will accept it.
