How to define the ISMS scope under ISO 27001

Edition context: references to 2013 are retained for historical use. For current implementation, consider ISO/IEC 27001:2022 with Amendment 1:2024. System certification does not guarantee that every information security incident will be prevented.

ISO/IEC 27001:2022 and its 2024 amendment

ISMS scope has been widely discussed since ISO 27001:2013 introduced concepts such as interfaces and dependencies. A structured approach makes it easier to establish an appropriate scope.

1. What is the purpose of the ISMS scope?

The main purpose of defining the information security management system scope is to identify the information to be protected and the relevant organizational boundaries. Information may be held in the office or in the cloud and accessed locally or remotely. Responsibility for protecting information within scope must address where, how and by whom it is accessed.

For example, a laptop taken outside the office is not automatically outside the ISMS scope. Its role must be considered when employees use it to access in-scope networks, sensitive information and services.

Scope also matters for certification: auditors assess how the ISMS operates within its defined boundaries, including relevant interfaces and dependencies with external or excluded activities. Excluding a department does not remove the need to manage its effects on in-scope information.

2. ISO 27001 requirements for scope

When defining scope, ISO 27001 requires consideration of:

• The internal and external issues addressed in clause 4.1.
• The interested-party requirements addressed in clause 4.2.
• Interfaces and dependencies between activities performed within the ISMS and those outside it.

A short description of locations and organizational units can help clarify boundaries, for example using a floor plan or organization chart. These are practical ways to communicate scope, not a universal requirement to use a particular diagram.

The ISMS scope must be available as documented information. It can be a separate document, incorporated into another document such as the information security policy, or supported by references to documented context, interested parties and their requirements.

The next issue is how to identify interfaces and dependencies.

Interfaces and dependencies

A diagram can help identify dependencies. Draw the processes included in the ISMS scope, then show processes provided from outside that scope. Include the core business processes, not only security or IT processes. An existing ISO 9001 process map may provide a useful starting point. The example below illustrates this approach.

The example places core and support processes within Company A’s ISMS scope and shows software development and maintenance, legal, cleaning and accounting services outside the boundary.

Once dependencies are understood, identify the interfaces through which inputs and outputs cross the ISMS boundary so that they can be protected appropriately.

There are several approaches to identifying interfaces:

One approach is to identify the endpoints under your control. A router may be a local network interface where the telecommunications provider takes over the connection; an entrance may be a physical interface for an office.

• Another approach describes interfaces through people, processes and technology. In the example, the people in Company A include the software users, while the external software development and maintenance provider may be represented by its lead developer.
• Processes include support for software faults and development of new functionality.
• Technology includes the help desk application, email, VPN and FTP connections, where these are used.

3. Common ISMS scope mistakes

Consider the following issues when defining scope:

• A smaller scope does not necessarily make implementation easier. Departments excluded from the scope become external interfaces that still require appropriate access controls and coordination. Their boundaries and interactions must be clearly defined.
• Control selection is not the same as defining the ISMS scope. Controls cannot be omitted merely because the organization does not wish to implement them. Determine necessary controls from risk treatment and applicable requirements, compare them with Annex A to avoid omissions, and justify inclusion and exclusion in the Statement of Applicability. Controls may also come from other sources.

4. Benefits of defining the ISMS scope

Defining scope clarifies the operating environment, relevant security requirements and the information that needs most attention. Establishing and documenting scope early provides a sound basis for the rest of the ISMS documentation and implementation.