How to Define the Scope of Your ISMS for ISO 27001
Defining the scope of your Information Security Management System (ISMS) is the single most important decision you will make during your ISO 27001 implementation. The scope sets the boundary around what your ISMS protects, which parts of your organisation are included, and what assets fall under the certification. Without a clear, justified scope, your ISMS lacks credibility and your certification audit will fail.
What Is an ISMS Scope?
The ISMS scope is a documented statement that defines the boundaries and applicability of the information security management system within your organisation. It describes which parts of the business, which locations, which information assets, and which third-party relationships are covered by the ISMS. The scope must be a true reflection of what your organisation controls and must align with the strategic context of the business.
Scope documentation typically includes organisational departments, physical sites, information systems, networks, data types, and external services that fall under the ISMS umbrella. The scope must be realistic – too narrow and you risk missing critical security controls; too broad and you create an unmanageable system that drains resources.
ISO 27001 Clause 4.3 Requirements
Clause 4.3 of ISO 27001:2022 requires your organisation to determine the boundaries and applicability of the ISMS to establish its scope. The standard is unambiguous: when determining the scope, you must consider the external and internal issues referred to in Clause 4.1, the requirements of interested parties referred to in Clause 4.2, and the interfaces and dependencies between processes performed by your organisation and those performed by other organisations.
This means your scope cannot be arbitrary. It must be derived from a careful analysis of your business context, legal and regulatory obligations, contractual commitments, and the expectations of stakeholders such as customers, regulators, insurers, and shareholders. The scope must be documented and maintained as documented information.
| Clause | Requirement | Impact on Scope |
|---|---|---|
| 4.1 | Understand the organisation and its context | Identifies external and internal issues that influence boundaries |
| 4.2 | Understand needs and expectations of interested parties | Determines which stakeholder requirements must be covered |
| 4.3 | Determine the scope of the ISMS | Produces the documented scope statement |
| 4.4 | Information security management system | Establishes processes needed to implement the scope |
Factors to Consider When Defining Your ISMS Scope
Several factors must be weighed when scoping your ISMS. Organisations often underestimate how interconnected their operations are, which leads to gaps in coverage.
Locations
Every physical site where information is processed, stored, or transmitted must be considered. This includes head offices, branch offices, remote work locations, data centres, and cloud infrastructure. If you operate internationally, consider jurisdictional differences in data protection laws.
Assets and Information Types
All information assets within the scope boundaries must be identified. This includes customer data, financial records, intellectual property, employee records, and operational data. Each asset class brings different security requirements and risk profiles.
Departments and Functions
Not every department may be in scope, but you must justify exclusions. Common in-scope departments include IT, operations, legal, compliance, HR, and finance. Exclusions such as marketing or R&D must be justified and documented.
Third Parties and Outsourced Services
If a third party processes your data or provides infrastructure, they must be addressed in the scope even if they are not certified themselves. Cloud providers, payment processors, and managed service providers all create dependencies that affect scope boundaries.
| Factor | Consideration | Documentation Required |
|---|---|---|
| Locations | Physical and virtual sites, data centres, remote work | Site register, data flow diagrams |
| Assets | Data types, hardware, software, intellectual property | Asset inventory, data classification schema |
| Departments | Included vs excluded functions with justification | Organisational chart, RACI matrix |
| Third parties | Suppliers, cloud providers, outsourced processes | Supplier register, contracts, SLAs |
| Regulations | GDPR, sector-specific laws, contractual obligations | Legal register, compliance obligations |
ISMS Scope Examples
Scope statements differ by organisation type. Here are three realistic examples:
- SaaS Company: The ISMS covers the design, development, and hosting of the [Product Name] platform, including all customer data processed therein, at the London headquarters and AWS eu-west-2 region, encompassing engineering, product, infrastructure, and customer support departments.
- Manufacturing Firm: The ISMS applies to the IT infrastructure, ERP system, and data networks supporting production operations at the Manchester factory and Birmingham warehouse, covering IT, operations, and supply chain departments. Sales and marketing are excluded due to zero data processing in those functions, as documented in the scope exclusion register.
- Consultancy: The ISMS covers the management consultancy services provided to clients, including client data processed at the Edinburgh office and by remote consultants, covering all consultancy, finance, and IT functions.
Scope Boundaries and Exclusions
Scope boundaries must be clearly defined in both inclusion and exclusion terms. ISO 27001 does not require your entire organisation to be in scope, but any exclusion must be justified and must not affect the organisation’s ability to achieve its information security objectives. Common exclusions include standalone business units, legacy systems scheduled for decommissioning, or physical security at co-located data centres if covered by the provider’s own certifications.
Boundary documentation should include process interfaces – where in-scope processes touch out-of-scope processes, and what controls are in place at those boundaries. For example, if your finance system is in scope but payroll is not, you must document how data passes between them and what security controls apply at that interface.
| Boundary Type | Example | Control |
|---|---|---|
| Physical | Office vs remote work | VPN, endpoint protection, clean desk policy |
| Logical | In-scope network segment | Firewall rules, VLAN segmentation, access control |
| Organisational | Subsidiary excluded | Data processing agreement, legal entity separation |
| Process | Data handover to out-of-scope function | Interface control document, encryption in transit |
Common Scope Mistakes
Even experienced organisations make mistakes when scoping their ISMS. The most common pitfalls are:
- Scope too narrow: Excluding critical business functions to reduce audit burden, only to have the certification body reject the scope or identify gaps during the Stage 1 audit.
- Scope too broad: Including the entire enterprise without adequate resourcing, leading to an unmanageable ISMS that fails during surveillance audits.
- Ignoring cloud and remote work: Failing to account for data processed by cloud providers or by employees working from home, leaving significant gaps in coverage.
- No exclusion justification: Excluding functions without documented rationale, which is a direct non-conformity against Clause 4.3.
- Static scope: Setting the scope once and never reviewing it, despite organisational changes such as acquisitions, new product lines, or office relocations.
Scope Review and Maintenance
Your ISMS scope is not a one-time document. It must be reviewed at planned intervals and whenever significant changes occur. Triggers for scope review include mergers and acquisitions, new service offerings, entry into new geographic markets, changes in data protection law, restructuring, and adoption of new technologies such as AI or cloud platforms. The management review process (Clause 9.3) is the natural home for scope re-evaluation.
Scope changes must be communicated to all relevant interested parties and reflected in the risk assessment, Statement of Applicability, and any third-party certifications. If your scope expands, you may need a full risk assessment cycle for the new areas before the next surveillance audit.
Frequently Asked Questions
Can I exclude a department from the ISMS scope?
Yes, but the exclusion must be justified and documented. The exclusion must not affect the organisation’s ability to achieve its information security objectives. Common justifications include the department processing no confidential information or having no information systems shared with in-scope areas.
How often should the ISMS scope be reviewed?
The scope should be reviewed at least annually as part of the management review process, and additionally whenever significant organisational changes occur such as mergers, acquisitions, office relocations, or new product launches.
Do I need to include my cloud provider in my ISMS scope?
Your cloud provider does not need to be inside your scope, but the interfaces, dependencies, and data exchanges with the provider must be addressed. If the provider holds an ISO 27001 certification, you can rely on their controls, but you must still document the relationship and associated risks.
What is the difference between scope and Statement of Applicability?
The scope defines the boundaries of the ISMS – what is covered. The Statement of Applicability (SoA) lists which controls from Annex A are applicable to the ISMS and justifies any exclusions. The scope is a broader document; the SoA is a control-level mapping.
Can my ISMS cover only one product or service?
Yes. Many organisations scope their ISMS around a single product, service, or business unit. This is common for SaaS companies seeking certification for a specific platform. The scope must clearly describe what is and is not covered.
What happens if my scope is too narrow for the certification audit?
The certification auditor will raise a non-conformity during the Stage 1 audit. You will be required to revise the scope and potentially postpone the Stage 2 audit until the scope adequately covers the organisation’s information security obligations.
Get Expert Help Defining Your ISMS Scope
Getting the ISMS scope right from the start saves time, money, and audit headaches. Our ISO 27001 consultants at Bitrixme can guide you through the scoping process, prepare your scope documentation, and ensure your ISMS is audit-ready. Contact us today or message us on WhatsApp to discuss your ISO 27001 project.
