How to define your ISO 27001 scope (without making a rod for your own back)

This guide walks you through how to define your ISO 27001 scope using documents from my toolkit:

These documents aren’t mandatory, and I’ll show you how to phrase your scope statement, what to include/exclude, and the pitfalls to avoid.

---

1. What is the ISO 27001 scope?

The scope tells the world (and your auditor) what parts of your organisation, processes, locations, systems and services are covered by the ISMS. It’s the boundary line:

• Everything inside the scope must follow the ISMS
• Everything outside doesn’t (for now)

ISO 27001 puts this in clause 4.3. Your ISMS Scope Document template already follows that structure.

A good scope statement should clearly answer:

• What business you’re in
• What information and services you’re protecting
• Which people, locations and systems are in scope
• Which departments and processes are included or excluded
• What’s explicitly out of scope

If a customer, auditor or sales prospect reads your scope, they should be able to say: “I can see exactly what’s covered.”

---

2. Inputs to gather before you write the scope

Before you try to write a neat paragraph, use the Scope Assessment Workbook to capture the raw thinking. That’s where you:

• Map out why you’re doing ISO 27001
• Identify which data you care about most
• Work out where it lives and who touches it
• Decide what’s in and what’s out

At a minimum, answer these questions:

• Why are we doing ISO 27001?
  • Customer demand, tenders, regulator, board expectation, mergers, etc.
• What information must we protect?
  • Customer data, platform data, employee HR data, finance data, IP, etc.
• Where does that information live?
  • Office 365 / Google Workspace, AWS/Azure, CRM, ticketing tools, laptops, mobile devices.
• Who processes it?
  • Internal teams, remote staff, contractors, outsourced HR, cloud providers.
• What can we legitimately leave out (for now)?
  • Offices that never touch customer or employee data (whatever is at the heart of your scope)
  • Legacy systems being decommissioned
  • Marketing-only sites with no in-scope data

Alongside that, consider:

• Internal and external issues (growth, new products, security threats, regulation)
• Interested parties and their expectations (customers, regulators, employees, key partners)
• Legal, regulatory and contractual requirements (GDPR, DPA 2018, specific contract clauses)

The workbook is your discovery and decision tool. The scope document is the polished output.

---

3. Keep the scope focused (especially in year one)

For most small organisations, it’s a mistake to aim for “whole company” scope out of the gate. You’ll drown yourself in work and evidence. I say this over and over – and rarely does anyone listen to me – but why over-complicate things for yourself? If the key reason behind 27001 is to prove to customers, then focus on the services and technologies that process customer data – everything else can wait.

A more sensible first-year approach:

• Focus the scope on the services and data that win or retain customers
• Include the supporting systems and people that actually handle that data
• Plan to extend the scope later as the ISMS matures

You can always widen your scope. Shrinking it after the fact is much harder.

You can’t magically change your scope outside of an audit and have that certificate cover your new scope automatically; you would have to recertify, but there is no reason why you can gently increase your scope during the period between audits and recertify with the new scope when it’s time.

Typical first-year scope for a small SaaS company

“The ISMS covers the design, development, hosting and support of the [Product Name] SaaS platform and related customer data processing activities, carried out by staff working in the UK and remotely within the EEA, using Microsoft 365, AWS and approved third-party processors.”

Why auditors would like this:

• States what (SaaS platform and customer data)
• States who (staff in certain regions)
• States where/with what (Microsoft 365, AWS, specific third parties)

Example: Limiting scope to one big contract

“The ISMS is limited to the processing of customer data received from Client X under contract [ref], and the supporting information systems (Microsoft 365, HubSpot and AWS) and staff involved in delivering those services. Other business activities are excluded from this scope.”

Useful when a single major customer is driving ISO 27001 and you don’t want to ISO the entire business on day one.

---

4. What to include in your scope document

If you grab a copy of my scope template, then the next job is to fill out the sections clearly and concisely.

Typically, you’ll cover:

• Purpose of the document
  • Say that it defines the boundaries and applicability of the ISMS.
• Introduction / organisation overview
  • A short “who we are and what we do” paragraph, helpful for auditors and new stakeholders.
• Scope statement
  • The key paragraph people will quote and copy into reports and contracts.
• Purpose of the ISMS
  • Why you’re doing this: protect information, meet legal/contractual obligations, support strategy, etc.
• Context of the organisation
  • Internal and external issues that affect information security.
  • Key internal and external stakeholders and their requirements.
• Business functions in scope
  • E.g. Product/Engineering, Support, Information Security, Finance, HR (if using the same systems).
• Physical locations in scope
  • Offices, co-working spaces, home-working, data centres.
• Technology services in scope
  • Microsoft 365 / Google Workspace, cloud hosting, CRM, ticketing tools, endpoint devices.
• Outsourced services in scope
  • HR/payroll providers, managed IT/SOC, hosting partners, key SaaS providers.
• Out-of-scope elements
  • Name them explicitly; locations, systems or activities that are not covered.
• Document maintenance
  • Who owns the document, how often it is reviewed, and how it’s shared internally.

You don’t need pages of text. I personally like to create tables of these sections of information – it makes it a lot easier to read and digest.

A clear, organised document that matches reality is exactly what an auditor wants.

---

5. What you can exclude (and how to justify it)

ISO 27001 lets you set boundaries, but those boundaries must make sense.

Things you might reasonably exclude:

• Marketing-only websites that never process customer or employee data
• Regional offices that genuinely don’t support in-scope services
• Legacy systems being decommissioned and not touching in-scope data
• R&D environments isolated from in-scope production systems

When you exclude something, write a short justification based on data and service relevance, for example:

“The regional marketing office in Madrid is excluded from the ISMS scope as it does not process customer or employee personal data and does not support in-scope services.”

If you can’t explain why something is out, it probably shouldn’t be.

---

6. Common scope pitfalls (and how to fix them)

A few patterns come up again and again.

Pitfall 1: “Whole company” scope you can’t support

Sounds neat, but then you must:

• Train everyone
• Cover every process
• Audit every function

Fix: Narrow the scope to the services, data and locations that genuinely matter for your objectives (often: revenue-generating services handling customer data).

---

Pitfall 2: Forgetting remote and home workers

If staff working from home access in-scope systems or data, they’re in scope whether you write it down or not.

Fix: Explicitly include home-working and remote locations in the scope, and back it up with controls (devices, VPN, policies).

---

Pitfall 3: Ignoring suppliers and cloud services

Cloud and outsourced providers are often where most of the data actually sits. You can’t just say “All third-party services are out of scope“, either. If you are the owner/guardian of that data on behalf of others and it falls into scope, then those third parties fall into scope too. I recently had a client who tried this with an auditor, despite my advice, and it didn’t fly well in their stage one assessment…

Fix: Name key providers (e.g. AWS, Azure, Microsoft 365, your HR/payroll provider, CRM, ticketing platform) in the scope and cover them in your supplier management and risk assessments.

---

Pitfall 4: Vague technology boundaries

“Cloud services” is too woolly.

Fix: Be specific. For example, “Microsoft 365 (Exchange, SharePoint, OneDrive), AWS [regions/services], HubSpot CRM, Freshdesk ticketing,” etc.

---

Pitfall 5: No out-of-scope list

If you don’t say what’s out, people assume everything is in.

It’s not mandatory to create or define what’s out of scope, but in my many years of governance and project management, if I’ve learnt anything, it’s not to allow ambiguity in scope – and a great way of doing that is to be explicit about what is out of scope. Or, people assume it’s in by omission.

Fix: Use a small “Out of scope” section in your scope document. List key exclusions and why they’re excluded.

---

Pitfall 6: Never reviewing the scope

Businesses grow, launch new products, open offices and add suppliers — but the scope document never changes. It’s easy to focus on other part of the ISMS – there’s a lot to do! – but you should review the scope and not just assume it’s still applicable.

Fix: Set an annual review as a minimum, and update the scope whenever there’s a material change (new product line, new region, major new platform).

---

7. How the scope drives risk, SoA and Annex A

Once your scope is agreed:

• Only in-scope assets, locations, services and people go into your asset inventory
• Your risk assessment focuses on those in-scope assets and processes
• Your Statement of Applicability (SoA) is built from the risks affecting in-scope assets
• Your evidence set and audits stay focused on what you’ve actually committed to protect

That’s how scope controls cost and effort: the broader the scope, the more risks, controls, evidence and audit work you’re signing up for.

But remember: you can’t simply exclude things that clearly handle in-scope data just to make life easier. Scope has to be honest.

---

8. How to handle outsourced and cloud services

You don’t need to “pretend you own AWS”, but you do need to:

• Acknowledge that those providers are within scope for the services they deliver
• Describe them in the Technology Services or Outsourced Services sections of your scope document
• Cover them in your risk assessment, SoA and supplier management and assessment process

Typical wording:

“The ISMS includes cloud infrastructure and productivity services used to process in-scope information, including AWS, Microsoft 365 and [other key platforms], and the management of these services through supplier and security governance processes.”

That’s enough for an auditor to see that you understand your dependencies and have them under control.

---

Bringing it all together (and how the templates help)

In practice, designing a good scope is mostly structured thinking and clear writing. The hard bit is starting from a blank page.

That’s why I provide:

• A Scope Assessment Workbook – to help you answer “What are we protecting, for whom, and where does it live?” in a structured way.
• An ISMS Scope Document template – to turn those answers into a clear, auditor-ready scope statement and supporting detail.

Use the workbook to explore options, agree boundaries and avoid over-scoping. Then use the scope document template to capture the final agreed scope and keep it maintained.

Want the templates?
You can get both the Scope Assessment Workbook and the ISMS Scope Document as part of my full ISO 27001 Toolkit, along with risk, SoA and internal audit templates that all line up with the same structure.