ISMS scope: what it is and how to write one an auditor will accept

Your ISMS scope says which parts of your organisation the information security management system covers: which services, teams, locations, systems and information. It's a short statement, usually a paragraph or two, and almost everything else in your ISMS hangs off it. Your risks, your Statement of Applicability, your policies and your audit all work inside the line it draws.

If you're running ISO 27001 on your own, the scope is the first thing to get right, because it decides how much work the rest will be.

Why it matters

The scope comes from clause 4.3 of ISO/IEC 27001:2022. In summary, the standard asks you to decide the boundaries and applicability of your ISMS, and to take three things into account when you do:

• The issues you identified for clause 4.1 (your context: market, size, systems, suppliers).
• The requirements of the interested parties you identified for clause 4.2 (customers, regulators, staff, insurers).
• The interfaces and dependencies between what you do yourself and what others do for you, such as a cloud host, a managed IT provider or a payroll bureau.

The scope must be kept as documented information. It also ends up on your certificate, so customers who check your certificate see exactly what it covers. A scope that leaves out the service a customer actually buys from you won't help you win that customer.

What an auditor looks for

At stage 1 the auditor reads your scope closely, and at stage 2 they test it against what they find. Expect them to check that:

• It's specific. It names the services or products, the locations, and the teams in scope. "All of the company's information" is too vague to audit.
• It's consistent. The same boundary shows up in your risk assessment, your Statement of Applicability, your asset list and your supplier list. A system that's in scope should have risks and an owner.
• Exclusions are justified. If part of the business is left out, you can say why, and the parts that are in scope don't depend on it in a way that undermines security.
• Interfaces are understood. Where information crosses the boundary (to a supplier, a parent company, a shared office), you know it and you've dealt with it, usually through supplier controls.
• It's approved and current. Someone with authority signed it off, and it still matches how the business works today.

Common reasons it fails: the scope says one thing and the SoA or risk register says another; a key cloud service or outsourced function isn't mentioned anywhere; or the business has changed (a new office, a new product) and the scope never caught up.

An example scope statement

This is an illustrative example for a fictional company, not a template to copy word for word. Yours should describe your own business.

The information security management system covers the design, development, hosting and support of the Acme Booking platform, provided to UK healthcare clinics as software as a service. It includes the staff, processes and information involved in those activities, the company's office in Leeds, staff working from home, company-managed laptops and mobile devices, and the production environment hosted with our cloud provider in the UK. Office facilities management is excluded; it is provided by the landlord and does not process customer information. Services from the cloud host, email provider and payroll bureau are outside our direct control and are managed through our supplier security controls.

Notice what it does: it names the service and who it's for, the locations, the people and devices, where the systems are hosted, one justified exclusion, and the suppliers it depends on. It doesn't list individual servers or name every member of staff.

Check your own scope

Before you approve it, check you can answer yes to each of these:

• Does it name the services or products your customers rely on?
• Does it say where the work happens, including home working and the cloud?
• Is every exclusion explained, and does nothing in scope depend on it?
• Are the suppliers that handle in-scope information covered?
• Would a customer reading your certificate recognise the service they buy?
• Do your risk register, Statement of Applicability and asset list cover the same ground?

Common mistakes, and how to keep it manageable

• Scoping too wide too early. Covering everything sounds safe, but every team and system you include needs risks, controls and evidence. Many small organisations start with the service their customers ask about, then widen the scope later.
• Scoping too narrow to be useful. Leaving out the platform your customers actually use makes the certificate look like a technicality. Check the scope against why you're doing ISO 27001 in the first place.
• Listing every server by name. Describe the boundary in terms that survive change ("our production environment hosted in the UK", "staff laptops and mobile devices") and keep the detail in your asset register, where it's easier to update.
• Forgetting suppliers. Outsourcing a service doesn't take it out of scope. If a supplier handles your in-scope information, say how it's covered.
• Never revisiting it. Review the scope whenever the business changes, and at least at each management review.

How to do it in ClearIMS

1. Start from the draft. When you set up ClearIMS, the onboarding chat asks about your business in plain English and drafts a first scope for you. It's a draft until a named person approves it.
2. Open ISMS scope and read the draft against the checklist above: services, locations, teams, systems, exclusions and interfaces.
3. Edit it in your own words. You can use the AI rewrite to tighten the wording. It only suggests text, and you decide what stays.
4. Send it for approval. A named person in your organisation approves the scope. The AI never approves anything. ClearIMS keeps each version, with who approved it and when, so you can show an auditor how it has changed.
5. Keep the rest consistent. When the scope changes, check your risks, Statement of Applicability, assets and suppliers still match it.

Related pages

• Context issues: the clause 4.1 issues your scope takes into account.
• Interested parties: whose requirements the scope has to meet.
• Statement of Applicability: the controls that apply inside the scope.
• Assets and Supplier register: where the detail behind the scope lives.