ISMS Scoping

In this article I will discuss ISMS scoping according to ISO 27001, TISAX® and KRITIS.

Depending on the basis, there are recognized best practices, guidelines and/or specific requirements that must be strictly adhered to and which I will list below.

---

ISO27001

The ISACA Germany Chapter has published a comprehensive implementation guide for ISO/IEC 27001:2022, which is specifically aimed at organizations that already operate an information security management system (ISMS) in accordance with this international standard or are planning to introduce one. This guide is characterized by its practical recommendations and detailed instructions that help companies to effectively meet the complex requirements of ISO/IEC 27001.

In relation to the scope of an ISMS, an essential part of ISO 27001 implementation, the guide stresses the importance of a precise definition. The scope of an ISMS, often referred to as the ISMS scope, is crucial as it defines the area of application of the ISMS within the organization. It determines which business areas, information, locations, assets and technologies are covered by the ISMS. A precise and comprehensive definition of the ISMS scope is essential to ensure that all relevant parts of the company are adequately protected.

In this context, the guide states the following:

3.1 Context of the Organization

One of the first tasks when implementing an ISMS is to determine the specific scope of the management system and to conduct a requirements and environment analysis with regard to the organization and its stakeholders. By taking the context of the organization into account, an organization can ensure that its information security measures are adapted to its specific needs and circumstances and are therefore effective. ISO/IEC 27001 therefore requires organizations to carefully analyze the context of the organization and incorporate it into their information security planning and implementation.

Determination of the scope

According to the standard, the scope must be documented and describes the extent of the ISMS within a company, i.e. it sets the boundaries and defines which assets (processes, business areas, locations, applications, etc.) are within and which are outside the scope.

The identification of the scope is usually carried out using an environment and requirements analysis.

• The scope document is essentially a document for the stakeholders of the management system and should be made available to them upon request, as this is the only way for stakeholders, such as customers, to check whether the processes, infrastructures, topics or requirements relevant to them are covered by the ISMS.

• In practice, organizations often refer to existing ISO/IEC 27001 certificates when making inquiries, which - upon closer inspection - are often not relevant or sufficient for the inquiry because the requested process is not or only partially covered by the ISMS. To avoid unpleasant surprises, the scope document or a precise description of the scope should therefore always be requested in addition to a certificate.

• Another relevant document for presenting the scope and extent of an ISMS is the normatively required statement of applicability (Statement of Applicability), which documents the justified decisions on the implementation of the controls from Annex A, i.e. whether the respective measure is applied within the ISMS or not, including the respective justification for the application or non-application.

• It is common for the information security policy to at least roughly outline the scope. In contrast to the scope document, the security policy and the SoA are usually internal documents and are not intended to be passed on to external parties. However, attention should be paid to the exact scope definition and the contents of the SoA in the context of service provider relationships and, if applicable, service provider audits.

Environmental analysis

The environmental analysis serves to classify the ISMS in the overall environment for the relevant scope. In addition to the organizational and technical interfaces relevant to the ISMS, it should also describe industry-specific or location-specific conditions. This must take into account both the internal environment, e.g. other management systems (ISO 9001:2015, ISO 22301:2019, etc.), interfaces to other important departments such as risk management, human resources, data protection, facility management, auditing and legal, if not part of the current scope, and the external environment, e.g. important suppliers and service providers, strategic partners and, if applicable, other organizations.

Requirements analysis

The people responsible for the management system need a clear overview of which interest groups (stakeholders) exist and what requirements they have for the organization and the management system. The requirements of interested parties can include legal and official requirements (e.g. EU GDPR, UWG, TMG, regulatory authorities), but also contractual obligations, for example. The organization itself (or possibly an organization higher up in the hierarchy) could also have decision-making and/or policy-making powers, which must be taken into account accordingly.

Success factors from practice

Since defining the scope is the first and crucial step in setting up and operating an ISMS, this phase should be carried out with particular care. Understanding the context is the basis for all further actions (e.g. structure and process of the risk analysis, organizational structure, definition of work packages and their prioritization, project planning) and is also an essential business prerequisite for estimating the feasibility and effort (resources, budget, time) for setting up and later operating the ISMS.

• In ISO 31000:2018, section 5.4.1 "Understanding the organization and its context", lists are provided with which the completeness of the representation can be achieved.

• The level of detail required to define the scope of application usually results from the internal and external requirements for the organization's information security. In practice, it has proven helpful to describe the areas significantly affected by the ISMS in sufficient detail in the scope of application, as this description is an important control tool and will be relevant for strategic decisions and (later) coordination.

• The identification of interest groups (and their requirements) required under section 4.2 of the standard must be carried out carefully and comprehensively in every case, as this is the only way to define clear goals and contents of the ISMS and achieve the best possible benefit. Examples of interest groups are: owners, shareholders, supervisory board, works council, regulatory authorities or legislators, customers, clients, suppliers or subcontractors, service providers, employees, etc.

• Business plans, contracts and specifications from supervisory authorities and legislators on the business processes concerned can serve as a basis for collecting relevant internal and external requirements. In practice, this is often done by a compliance or IT compliance function, which can support the collection of requirements.

Documentation requirements

According to ISO/IEC 27001:2022, the following minimum documentation requirements apply:

• Scope of the ISMS (Section 4.3)

• Statement of applicability (Section 6.1.3 d)

• Overview of all relevant legal, regulatory and contractual requirements that impact the information security strategy and the ISMS (Section 18.1)

• Overview of all interest groups (stakeholders) relevant to the specific scope of the ISMS

In addition, the following document has proven to be useful in practice:

• Interface agreements between the ISMS scope and the internal areas supporting the ISMS (to ensure that cooperation with the internal area is in accordance with ISO/IEC 27001:2022 and the relevant IS requirements of the organization). Example: Interface agreements with the human resources department.

References

SO/IEC 27001:2022 – Sections 4.3 and 6.1.3 ISO/IEC TR 27023:2015 ISO 22301:2019 ISO 31000:2018 ISO 9001:2015

ISACA Implementierungsleitfaden ISMS 2022.pdf

PDF herunterladen • 1.58MB

(Unfortunately only available in German)

---

TISAX® (Trusted Information Security Assessment Exchange)

In the context of information security, ISO 27001 offers companies a great deal of flexibility in defining their information security management system (ISMS). But if we look from ISO 27001 to TISAX®, we come across a different approach. TISAX® is a standard specifically for the automotive industry and has a specific specification for the audit scope, which in turn specifies the minimum scope of the ISMS for companies. This represents a significant deviation from the flexible design of the ISMS scope, as is possible with ISO 27001.

In this context, the TISAX® Participant Handbook states the following:

"4.3.2. The TISAX audit scope TISAX Participant Handbook (link date 04.12.2023)

„In the second step of the TISAX process, one of our TISAX audit providers will conduct the information security assessment. He needs to know where to start and where to stop. That’s why you need to define an “assessment scope”.

The “assessment scope” describes the scope of the information security assessment. In simple terms, every part of your company that handles your partner’s confidential information is part of the assessment scope. You can consider it a major element of the audit provider’s task description. It dictates what the audit provider needs to assess.

The assessment scope is important for two reasons:

1. An assessment result will only fulfil your partner’s requirement if the respective assessment scope covers all parts of your company that handle partner information.

2. A precisely defined assessment scope is an essential prerequisite for meaningful cost calculations by our TISAX audit providers.

Important note:

ISO/IEC 27001 vs. TISAX

First, we have to differentiate two types of scopes:

1) the scope of your information security management system (ISMS) and

2) the scope of the assessment.These two are not necessarily identical.

For the ISO/IEC 27001 certification, you define the scope of your ISMS (in the “scope statement”). You are completely free to define the scope of your ISMS. However, the scope of the assessment (also known as “audit scope”) must be identical with the scope of your ISMS.

For TISAX, you also have to define your ISMS. But the scope of the assessment can be different.

For the ISO/IEC 27001 certification, you can freely shape the scope of the assessment through the way you define the scope of your ISMS.

In contrast, for TISAX, the scope of the assessment is predefined. The scope of the assessment can be smaller than the scope of your ISMS. But it must be within the scope of your ISMS.“

4.3.2.2. Standard scope TISAX Participant Handbook (link date 04.12.2023)

“The standard scope description is the basis for a TISAX assessment. Other TISAX participants only accept assessment results based on the standard scope description.

The standard scope description is predefined and you can’t change it.

A major benefit of having a standard scope is that you don’t have to come up with your own definition.

This is the standard scope description (version 2.0):

The TISAX scope defines the scope of the assessment. The assessment includes all processes, procedures and resources under responsibility of the assessed organization that are relevant to the security of the protection objects and their protection goals as defined in the listed assessment objectives at the listed locations. The assessment is conducted at least in the highest assessment level listed in any of the listed assessment objectives. All assessment criteria listed in the listed assessment objectives are subject to the assessment.

We strongly recommend choosing the standard scope. All TISAX participants accept information security assessment results based on the standard scope.”

Proposal for the minimum scope of the ISMS scope for TISAX®:

The ISMS scope covers all processes, procedures and resources involved at Mustermann GmbH at the following locations:

Mustermann GmbH
Muster Street 1
12345 Musterstadt 

If the company's ISMS scope document sets this requirement and does not fall below it, the further description of the scope can follow best practices, such as the implementation guide of the ISACA Germany Chapter.

With regard to the scope of the audit, it should also be noted that the company should not ignore the following note from the manual and should fully comply with it:

An assessment result will only fulfil your partner’s requirement if the respective assessment scope covers all parts of your company that handle partner information.

TISAX Participant Handbook.pdf

PDF herunterladen • 7.54MB

TISAX® is a registered trademark of the ENX Association. AUDIT MANUFAKTUR has no business relationship with ENX. The mention of the TISAX® trademark does not constitute a statement by the trademark owner regarding the suitability of the services advertised here. TISAX® assessments to obtain labels are only carried out by the testing service providers listed on the ENX homepage.

---

Choice of scope for critical infrastructures (KRITIS)

In the context of KRITIS, the audit scope also specifies the minimum scope of the ISMS scope. For a successful audit that meets the legal requirements, a careful and precise determination and description of the scope is necessary. This process requires an in-depth analysis and evaluation of various aspects to ensure that all relevant information technology systems, components and processes that are part of the critical infrastructure are comprehensively taken into account. The following statements from the Federal Office for Information Security (BSI) aim to explain the basic principles and methods that are essential for an adequate definition and representation of the scope in audit preparation:

Choice of scope

Information on choosing the scope of application (link date 04.12.2023)

"In particular, checking whether the scope of application has been chosen correctly is very important for the suitability of the evidence. The auditor must ask himself whether the choice of scope of application is correct and also fully covers the information technology systems, components and processes that belong to the critical infrastructure facility to be checked, as well as those that have an influence on the critical infrastructure.

The auditor must assess the scope of application under the audit aspects

• the functionality of the critical service,

• the suitability and necessity and

• evaluate and check for completeness.

The description of the system and the associated parts of the critical service must be comprehensible and their characteristics must match the registered system category. The scope must be shown graphically and, where necessary for understanding, described in writing. The graphic representation should provide a quick overview, while the textual description supplements this overview with the necessary depth of information. If there are dependencies or interfaces to areas or systems outside the scope, these must be recognizable in the graphic overview and described comprehensibly. The same applies to parts of the critical service that are provided by third parties on behalf of the operator.

If the representation of the scope of application is embedded in a representation of a larger area or overall network, the boundaries of the scope of application must be clearly identified.

Network structure plan

The central element of the graphical representation is the network structure plan. In its function as an overview, it must depict all areas of the critical infrastructure and show communication interfaces and dependencies to the outside world. It must be clear from it to what extent individual elements are relevant for the critical service. Choosing an appropriate level of abstraction is essential for this. In particular, the network structure plan records all systems, components and, if applicable, applications that are crucial for the functionality of the critical service. Associated processes can be recorded in the network structure plan or shown separately. In any case, however, it must be possible to assign processes to the associated necessary IT systems, components and applications. It is also important here that the interaction of the essential components with each other and with third parties is clear.

Similar objects should be grouped together in a sensible way so that the network structure plan remains clear.

Objects can be assigned to the same group if the objects all

• are of the same type,

• have similar tasks,

• subject to similar conditions and

• have the same need for protection.

If the systems, components or other areas of the critical infrastructure are distributed across multiple locations, the scope must reflect this division and specifically name the locations. It must also show the connections between the locations. Outsourced parts of the critical service must be identifiable in the scope, as must the communication interfaces used. These also include maintenance interfaces, provided they are permanently activated.

This means that at least the following interfaces must be shown in the network structure plan:

• Communication interfaces to external networks

• Communication interfaces to networks at other locations

• Maintenance interfaces, if they are permanently activated

• Interfaces to outsourced parts of the service

If elements of the network structure plan are represented by symbols to improve clarity, the elements used must be explained in a legend. A list format can also be used to provide a better overview of the requirements for the representation of the scope of application by a network structure plan.

Requirements for the description and presentation of the scope

• G01: The system is described clearly and comprehensibly.

• G02: The parts of the essential services provided by the operator are clearly and comprehensibly described.

• G03: The presentation contains all essential characteristics of the plant category.

• G04: All processes relevant to the KDL are recorded.

• G05: All systems, components and, if applicable, applications relevant to the KDL are recorded.

• G06: All areas of KRITIS are derived from the submitted scope.

• G07: The limits of the scope are clearly visible.

• G08: The interfaces to processes, systems, components and, if applicable, applications outside the scope are clearly and comprehensibly described.

• G09: The dependencies on processes, systems, components and, if applicable, applications that lie outside the scope are recognizable and described in a comprehensible manner.

• G10: Parts of the KRITIS operated by third parties are clearly and comprehensibly described.

• G11: The scope enables an assignment between processes and associated necessary systems, components and, if applicable, applications.

• G12: The scope is shown in a network structure plan.

• G13: Written additions to the network structure plan necessary for understanding have been made.

Requirements for the representation of the scope of application by a network structure plan

• N01: The network structure plan provides an overview of the scope.

• N02: All relevant systems, components and, if applicable, applications are shown.

• N03: The level of abstraction has been chosen appropriately.

• N04: The relevance of individual elements of the network structure plan for the kDL is evident.

• N05: All external communication interfaces are shown.

• N06: Maintenance interfaces are shown if they are permanently activated.

• N07: The network structure plan shows any existing division into locations.

• N08: The IT connections between different locations are shown.

• N09: Outsourced services are shown.

• N10: Functional names and legends are available where necessary and are understandable."

Zur Dokumentation des Geltungsbereiches bei KRITIS-Betreibern - Hilfestellung und Beispiel.

herunterladen • 897KB

(Unfortunately only available in German)

Validierung und Darstellung eines Geltungsbereichs für Kritische Infrastrukturen (Anforder.

herunterladen • 494KB

(Unfortunately only available in German)