The ISMS scope is the single most consequential decision you make before starting your ISO 27001 programme. It determines which business functions, systems, locations, and data flows are covered — and by extension, how many controls you need to implement, how long certification takes, and how much it costs. Get the scope right and the rest of the project follows logically. Get it wrong and you either overspend or end up with a certificate that does not cover what buyers need to see.
Why Scope Matters
ISO 27001 Clause 4.3 requires you to define the scope of your ISMS — the boundaries within which the management system operates. Everything inside the scope is subject to the full ISO 27001 requirements: risk assessment, controls, internal audit, management review, and certification audit. Everything outside the scope is explicitly excluded.
Your scope statement appears on your ISO 27001 certificate. Enterprise buyers and procurement teams read it. If your scope does not cover the product or service they are evaluating, the certificate has limited value to them.
What the Scope Includes
The scope definition must address four dimensions:
- Business functions: Which departments, teams, or business units are covered? Product engineering, DevOps, customer support, HR, finance?
- Systems and infrastructure: Which production systems, cloud environments, internal tools, and third-party services are in scope?
- Locations: Which physical offices, data centres (or cloud regions), and remote working arrangements are covered?
- Data flows: Which categories of information — customer data, employee data, financial data, source code — are within the ISMS boundary?
Writing Your Scope Statement
The scope statement should be clear, specific, and auditable. A good scope statement for a SaaS startup might read:
"The development, hosting, operation, and delivery of the [Product Name] SaaS platform, including the associated cloud infrastructure hosted on AWS (eu-west-1 and ap-south-1 regions), corporate IT systems, and supporting business processes operated from the Pune office and remote working locations."
Notice what this includes: the product, the cloud infrastructure (with specific regions), corporate IT, and all locations. Notice what it does not include: specific excluded business units, R&D projects not yet in production, or subsidiary operations in other countries.
The Too-Broad Trap
The most common mistake for larger organisations is scoping too broadly. If you include every department, every system, every location, and every data flow, you are committing to:
- Risk-assessing every asset in the organisation — potentially hundreds of assets
- Implementing controls across systems and teams that may not be ready
- A longer, more expensive certification audit (audit days scale with scope)
- Higher ongoing maintenance — more controls to monitor, more evidence to collect, more people to train
A broad scope is not inherently wrong — large enterprises need it. But for startups and mid-sized companies, it delays certification and increases cost without proportional benefit.
The Too-Narrow Trap
The opposite mistake: scoping so narrowly that the certificate does not cover what enterprise buyers care about. If you certify only your "internal IT systems" but exclude the SaaS platform that customers use, the certificate is commercially useless. Procurement teams will read the scope statement and note that their product is not covered.
Your certificate does not mention your core product or service by name. Customer-facing systems are excluded. Your cloud infrastructure is outside the ISMS boundary. Enterprise buyers still send security questionnaires despite your certification because the scope does not cover what they are buying.
Scope Examples — For Startups
| Company Type | Good Scope | Common Mistake |
|---|---|---|
| B2B SaaS (20 people) | Development, hosting, and delivery of the SaaS platform + cloud infrastructure + corporate IT + Pune office | Only corporate IT — excludes the product customers actually use |
| FinTech (50 people) | Payment processing platform + AWS infrastructure + customer data processing + supporting business functions | Entire company including R&D lab and future products not yet in production |
| Healthcare SaaS | Patient data platform + hosting + API integrations + all clinical data flows | Only the API layer — excludes the application and database |
| Consulting firm | Client engagement delivery + internal knowledge management + client data handling | Only internal email and laptops — excludes client deliverables |
Defining Boundaries
For each dimension of scope, define what is in and what is out:
- System boundaries: List the specific systems, applications, and infrastructure components. Use names — "AWS account 123456789, eu-west-1 region" not just "cloud infrastructure."
- Organisational boundaries: List the teams and functions included. If HR is in scope (it usually is for employee data), say so explicitly.
- Physical boundaries: List office locations. For remote-first companies, state "remote working locations of all employees within the ISMS scope."
- Third-party boundaries: Key vendors and processors that handle in-scope data should be identified. Their management falls under Annex A supplier controls.
Expanding Scope Over Time
Starting with a tight scope and expanding later is the recommended approach. You can expand scope at any surveillance or recertification audit (annually or every three years). Common expansion patterns:
- Year 1: Core SaaS product + primary cloud environment + corporate IT + main office
- Year 2: Add additional products, new cloud regions, or acquired business units
- Year 3 (recertification): Full enterprise scope if the business has grown significantly
A tight initial scope is a feature, not a compromise — it is the standard approach recommended by most certification bodies and compliance consultants. For the full ISMS overview, see our What Is an ISMS guide. For the self-assessment on whether ISO 27001 is right for your organisation, see our ISO 27001 Self-Assessment Guide.
Frequently Asked Questions
The scope statement defines the boundaries of your ISMS — which business functions, systems, locations, and data flows are covered. It appears on your ISO 27001 certificate and is read by enterprise buyers. Clause 4.3 requires you to document it, and auditors will verify that your ISMS actually covers everything the scope claims.
Yes — this is the recommended approach for most startups. Start with your core product, primary cloud environment, and supporting business processes. You can expand scope at any annual surveillance audit or the three-year recertification audit. Certification bodies expect and support this pattern.
The certificate has limited commercial value for that customer. Enterprise procurement teams read the scope statement on your certificate. If it does not mention the product or service they are buying, they will likely still send a full security questionnaire. This is why excluding your core product from scope is a common and costly mistake.
Yes, if your employees work remotely and access in-scope systems or data. For remote-first companies, the scope statement should include 'remote working locations of all employees within the ISMS scope.' Remote working controls (Annex A.6.7) then apply to all in-scope remote workers.
Audit days scale roughly proportionally with the number of employees, locations, and systems in scope. A 20-person SaaS startup with a tight product scope might need 4-6 audit days. A 200-person company with broad organisational scope might need 10-15 days. More audit days means higher certification body fees.