Defining the Scope: What Belongs in the ISMS and What Does Not?

TL;DR

The scope defines which locations, departments, processes, systems, and networks your ISMS covers.
A scope that is too large overwhelms the organisation; a scope that is too small leaves blind spots and jeopardises certification.
External interfaces such as cloud services, service providers, and customers must be explicitly documented.
The scope is a living document that must be updated when there are organisational changes, new locations, or changed business processes.
Start pragmatically, document exclusions with justification, and obtain management approval.

Why the Scope Is the Most Important First Step

When you build an information security management system (ISMS), a question arises at the very beginning that sounds unassuming but determines the success or failure of the entire project: What exactly should your ISMS cover?

ISO 27001 calls this the scope (in German: Geltungsbereich). In Chapter 4.3 of the standard, it requires you to determine the boundaries and applicability of your ISMS to establish its scope. It sounds like a formal requirement, but in truth it is the most strategic decision you make during the entire ISMS introduction.

Because the scope determines everything that follows. Every risk analysis, every policy, every measure, every internal audit, and every management review relates to the defined scope. Define it too broadly, and you drown in effort. Define it too narrowly, and critical areas are missing, and your ISMS fails to protect exactly the areas where it matters most.

Furthermore, every auditor in an ISO 27001 certification checks the scope first. If it is not plausible, not complete, or not traceably justified, the auditor will become sceptical within the first few minutes. And that scepticism then accompanies the entire audit.

What Belongs in the Scope?

The scope describes concretely which parts of your organisation and infrastructure are covered by the ISMS. This typically encompasses five dimensions:

1. Locations

Which physical locations are part of the ISMS? This includes office buildings, data centres, server rooms, home office workplaces, and production facilities — to the extent they involve information processing.

Precision is important here. If you have three office locations but only include the headquarters in the ISMS, this must be explicitly documented. The other two locations are then exclusions, and you must be able to justify why they are not (yet) in scope.

Since the pandemic, the topic of home office is also relevant. If employees regularly work from home and access company data, home office belongs in the scope — at least as a defined working context with corresponding rules.

2. Organisational Units and Departments

Which departments are affected? In a small company with 30 employees, the answer is often simple: all of them. In a larger company, it may make sense to initially limit the scope to certain areas, such as the IT department, development, and management.

Typical departments in ISMS scope:

IT / System administration: Operation and maintenance of IT infrastructure
Software development: If you develop software that processes customer data
Management: Bears overall responsibility for information security
HR: Manages sensitive employee data and handles onboarding/offboarding
Sales / Customer service: Has access to customer data and communicates externally
Finance / Accounting: Processes business-critical financial data

Departments with no direct connection to information processing can be justifiably excluded. But caution: The justification must be sound. An auditor will ask.

3. Business Processes

This is where it gets concrete. Which business processes are relevant for your ISMS? ISO 27001 requires that you define the scope in the context of business activities. This means: You must understand which processes access or generate information worthy of protection.

Examples of typical processes in scope:

Customer order processing
Software development and deployment
IT operations (servers, network, backup, monitoring)
HR administration
Finance and invoicing
Communication with customers and partners
Procurement and supplier management

You do not need to list every micro-process. But the core processes that are business-critical or process sensitive data belong in scope.

4. Information Systems and Applications

Which IT systems support the processes in scope? This is where clean IT asset management comes into play. You list the relevant systems, applications, and platforms:

Servers and infrastructure: Physical servers, virtual machines, container environments
Cloud services: Microsoft 365, AWS, Azure, Google Workspace, and every SaaS application that processes company data
Business applications: ERP, CRM, accounting software, project management tools
Communication systems: Email, messenger, video conferencing platforms
Development environments: Code repositories, CI/CD pipelines, test environments
End devices: Laptops, smartphones, tablets of employees

This listing does not need to go into the finest detail, but it must be complete enough that an auditor can understand which systems you have in view and which are deliberately excluded.

5. Networks and Network Segments

Which network areas belong to the scope? This includes the internal LAN, WLAN, VPN connections, DMZ segments, and connectivity to external networks. If you practise network segmentation, you describe which segments are in scope.

The topic of network boundaries is also relevant: Where does your network end and where does the internet provider's or cloud provider's begin? These handover points are interfaces that must be explicitly documented.

Documenting External Interfaces

An area often underestimated in scope definition is external interfaces. Your ISMS does not exist in a vacuum. There are points where information leaves your company or enters from outside. You must know and document these interfaces.

Cloud Services and SaaS Providers

If you use Microsoft 365 for email and document management, part of your information processing takes place at Microsoft. This does not mean Microsoft's data centres are in your scope. But the interface to Microsoft — how you use the service, how you manage access, what data is stored there — very much belongs in your scope.

The same applies to every SaaS application: Your CRM in the cloud, your project management tool, your accounting software. You must document that you use these services and how you ensure information security at these interfaces. In ISMS Lite, external interfaces and cloud services can be captured as assets and linked directly to the scope definition. This typically happens through supplier assessments and contractual agreements.

Service Providers and Partners

External IT service providers with access to your systems are a critical interface. A managed service provider maintaining your servers, a development partner with access to the code repository, an agency with access to your CMS: All of these are points that must appear in the scope document.

For these interfaces, you do not need a separate risk analysis of the service provider, but you must document that the interface exists, which data or systems are affected, and how you manage the risks (contracts, data processing agreements, regular reviews).

Customers and Clients

If you process customer data — for example as an IT service provider or software vendor — the interface to the customer is relevant. What data do you receive from the customer? How is it transmitted? Where is it stored? Who has access?

Some customers also impose their own requirements on your ISMS. Especially in the B2B environment, clients increasingly demand ISO 27001 certification or at least demonstrable information security measures. These requirements flow into your context of the organisation (ISO 27001, Chapter 4.2) and influence the scope.

Common Mistake: Scope Too Large or Too Small

The two most common mistakes in scope definition are extremes in both directions. Both can significantly jeopardise the ISMS project.

Mistake 1: The Scope Is Too Large

You include everything: every location, every department, every process, every system. This sounds conscientious but leads to massive problems in practice:

Resource overload: You must conduct risk analyses, implement measures, and verify their effectiveness for every area. For a company with 100 employees and one location, this is feasible. But if you have three locations, ten departments, and fifty systems in scope, the project quickly becomes unmanageable.
Endless introduction phase: Instead of having a functioning ISMS after 6–9 months, you drag the project out for years. Motivation of all involved drops, and at some point management asks why it still is not finished.
Superficial implementation: When the scope is too large, you tend to only scratch the surface everywhere. Better fewer areas thoroughly implemented than a huge scope with half-hearted measures.

Mistake 2: The Scope Is Too Small

The other extreme: You limit the scope to the IT department and its servers. Everything else is out. This can work but carries considerable risks:

Security gaps through exclusions: If accounting is outside the scope but financial data is processed on the same servers that are in scope, you have a logical problem. The auditor will ask how you protect accounting data when their processes are not in scope.
Lack of acceptance: If only IT is in scope, other departments do not feel affected. Information security is then perceived as a purely IT topic, not as an organisation-wide task. This undermines the entire security culture.
Auditor scepticism: An auditor will look closely at a conspicuously small scope to see whether you are trying to exclude problematic areas. Exclusions that are not plausibly justified can lead to findings.

The Golden Middle Ground

The best strategy is a pragmatic scope that covers all business-critical areas but consciously draws boundaries where it makes sense. Rule of thumb: Everything directly related to delivering your core service belongs in. Areas that are only indirectly affected can be justifiably excluded and integrated in a later phase.

Practical Example: Scope for a 100-Employee Company

Let us look at what a concrete scope document can look like. Our example is the fictional SecureData Solutions GmbH, an IT service provider with 100 employees and one location in Munich.

Company Profile

Industry: IT services (managed services, software development)
Employees: 100
Locations: 1 (headquarters Munich, Ridlerstrasse 42)
Customers: Mid-market companies in the DACH region
Data centre: Own server room on site + cloud services (AWS, Microsoft 365)

The Scope Document

Scope of the ISMS of SecureData Solutions GmbH

Version: 1.0 | Date: 2026-03-01 | Approved by: Management

The ISMS of SecureData Solutions GmbH covers all processes, systems, and information assets required for the delivery of managed IT services and software development services at the Munich location.

Locations included:

Headquarters Munich, Ridlerstrasse 42 (offices, server room, meeting rooms)

Home office workplaces of employees (as a defined working context)

Organisational units included:

Management

IT operations / System administration

Software development

Project management

Sales and customer support

HR

Finance / Accounting

Core processes included:

Delivery of managed IT services for customers

Software development and deployment

IT operations (servers, network, backup, monitoring, patch management)

Customer onboarding and contract management

Incident management and support

HR administration and access management

Information systems included:

Internal server infrastructure (VMware cluster, backup systems)

AWS environment (hosting of customer solutions)

Microsoft 365 (email, SharePoint, Teams)

Jira / Confluence (project management, documentation)

GitLab (code repository, CI/CD)

DATEV (accounting)

Zammad (ticket system / customer support)

Networks included:

Internal LAN and WLAN at the Munich location

VPN access for remote work

DMZ for externally accessible services

Connection to AWS (site-to-site VPN)

External interfaces:

AWS (cloud hosting): Managed through supplier assessment and AWS security certifications

Microsoft (M365): Configuration according to CIS Benchmarks, access management via Conditional Access

Customers: Data transfer via encrypted channels, governed by data processing agreements

External tax advisor: Access to DATEV, governed by confidentiality agreement

Exclusions:

Marketing department (3 employees): No direct access to customer or production systems. Usage limited to website CMS and social media tools. Integration planned for Phase 2.

Building cleaning and facility management (external): No access to IT systems, physical access controlled by visitor regulations.

What Is Good About This Example

Specific and traceable: Every point is specific enough that an auditor understands what is meant.
Exclusions are justified: The marketing department is not simply omitted but explicitly excluded with justification and a reference to planned integration.
External interfaces are named: For each external service, it is documented how security is managed.
Versioned and approved: The document has a version number and is approved by management.

How the Scope Is Versioned and Approved

The scope document is a controlled document in the sense of ISO 27001. This means it is subject to your document control and must meet certain requirements.

Versioning

Every change to the scope results in a new version. The document contains at minimum:

Version number: Sequential (1.0, 1.1, 2.0). Major changes like new locations or significant expansions receive a new major version. Smaller adjustments like adding a new IT system receive a minor version.
Date: When was this version created?
Author: Who made the change? Typically the Information Security Officer.
Change history: What was changed compared to the last version and why?

Approval by Management

ISO 27001 requires in Chapter 5.1 that top management establishes the information security policy and ensures the ISMS meets requirements. This includes approval of the scope.

Specifically, this means: Management must formally approve the scope. This can happen as a signature on the document, as a documented resolution in a management meeting, or as a digital approval in a document management system. What matters is that the approval is verifiable.

This approval is not just a formality. It ensures that management knows and accepts the boundaries of the ISMS. If the scope excludes areas, management must be aware that these areas are not protected by the ISMS and consciously support this decision.

Communication and Availability

The scope must be known to relevant parties. Your employees should know whether they work within the ISMS scope or not. External auditors must be able to review the document. And interested parties — such as customers asking about your certification — should be able to receive a summary of the scope.

It is best to publish the scope document in your internal wiki or document management system and reference it in the information security policy.

When and Why the Scope Must Be Adapted

The scope is not a document you write once and then forget in a drawer. ISO 27001 requires that you keep the scope current. There are specific occasions when a review and possible adjustment is necessary.

Organisational Changes

When your company grows, establishes a new department, or restructures, you must check whether the scope still fits. A typical example: You create a new development team that independently develops a new product. This team and its systems must be included in the scope.

New Locations

Opening a second office or renting a co-working space as a permanent work location requires a scope expansion. Increased use of home office may also necessitate an adjustment if the topic was not previously addressed in the scope.

Changes to the IT Landscape

When you migrate from on-premises to cloud, introduce a new ERP system, or build a new customer communication platform, your IT landscape changes and potentially your scope with it. New systems bring new interfaces that must be documented.

Changed Business Processes

When you enter a new business field, offer a new service, or fundamentally restructure an existing process, check whether the scope still reflects reality. This is particularly relevant when the new process handles different or additional data.

Regulatory Requirements

New laws or regulations may require a scope adjustment. A current example: The NIS2 Directive requires comprehensive cybersecurity measures from affected companies. If you fall under NIS2 and your ISMS scope does not yet cover all areas required by NIS2, you need to expand.

Insights from Audits and Incidents

Internal audits or security incidents can reveal that the scope has gaps. If an incident occurs in an area that was previously outside the scope, that is a strong signal to include this area.

Review Rhythm

Even without a specific trigger, you should review the scope at least annually, ideally as part of the management review. You check whether the documented scope still matches the actual situation and document the result — even if no change is needed.

Checklist for Scope Definition

Use this checklist to ensure your scope document is complete:

All relevant locations are named (including home office if applicable)
All included departments are listed
Core business processes in scope are described
Relevant information systems and applications are captured
Networks and network segments are documented
External interfaces (cloud, service providers, customers) are named
For each interface, how security is managed is described
Exclusions are explicitly listed and justified
The document is versioned (version number, date, author)
Management has formally approved the scope
The scope is known to employees within the scope
A review cycle is defined (at least annually)

Conclusion: Better to Start Pragmatically Than Plan Perfectly

The scope is the foundation of your ISMS. Take the time to define it carefully, but do not fall into perfectionism. A well-justified scope that covers 80% of your organisation and documents the remaining 20% as a planned expansion is better than a theoretically perfect scope that you never finish.

Start with the areas that are business-critical. Document clearly what is in and what is out. Justify your exclusions traceably. Obtain management approval and ensure all participants know what the ISMS applies to. And plan from the start that the scope is a living document that grows with your company.