A requirement is not a measure

"Has the measure been implemented?" In a meeting with the head of IT, the information security officer and an auditor, this question can mean three different things. The head of IT thinks of the concrete configuration rolled out last week. The ISO thinks of a requirement from the BSI IT-Grundschutz Kompendium. The auditor thinks of a control from Annex A of ISO 27001, which the German version of the standard also calls "Maßnahme", measure.

All three answer yes, and all three are right. They just were not talking about the same thing.

Module: what for

The module (German: Baustein) is the unit the Kompendium thinks in. It belongs to a target object, such as a server type, an application, a room or a process. The Kompendium describes its content as follows (our translation):

"The modules of the IT-Grundschutz Kompendium each contain a description of the component, procedures and IT systems under consideration, followed by a brief overview of specific threats and concrete requirements to secure the target object."

A module is therefore neither an obligation nor an implementation. It is the package that says which obligations apply to which target object. Which target objects exist and why the server is rarely what actually needs protecting was the topic of part 4.

Requirement: what must be fulfilled

The module contains the requirements, uniquely numbered, for example SYS.3.4.A2. The Kompendium describes their role as follows (our translation):

"The requirements formulated there describe what generally has to be implemented in order to reach the state of the art with suitable security measures."

What, not how. A requirement can be audited but is open in its execution. It is assigned to one of three levels: basic requirements are to be implemented first, together with the standard requirements they form the state of the art for normal protection needs, and on top come requirements for elevated protection needs.

How binding a requirement is lies in the modal verb. For MUST, the Kompendium says it is a requirement that must be fulfilled unconditionally, adding in brackets (our translation):

"unrestricted requirements for which no risk acceptance is possible"

SHOULD, by contrast, means that a requirement normally has to be fulfilled, but there may be reasons not to do so. Such a deviation must be carefully weighed and soundly justified.

Measure: how it is fulfilled in your organisation

The measure is the concrete implementation in your environment: the group policy, the process, the contract, the locked door. The Kompendium describes the path from one to the other: for typical scenarios, security requirements were selected (our translation)

"which can then be transferred into security measures that fit the individual circumstances."

The requirement is the same for everyone, the measure is yours. For many modules the BSI publishes implementation guidance with suggestions, and the numbering makes the separation visible: where implementation guidance exists, the measure listed there for a requirement "A" carries the same number with a preceding "M", in the example SYS.3.4.M2.

A2 is the obligation, M2 is a suggestion. The IT-Grundschutz check asks whether the requirement is fulfilled, not whether the implementation guidance was followed to the letter. Choosing a different measure that fulfils the requirement just as well is correct.

Control: the same word, one level up

In ISO 27001 and ISO 27002 the unit is called a control. In substance, a control is a safeguard that modifies a risk or maintains it at a level. The 93 controls in Annex A describe what is to be achieved, for example that access is regulated. How this is done is explained in ISO 27002 as guidance.

The German version of the standard refers to controls as "Maßnahmen", measures. So the ISO word "measure" is closer in content to the Grundschutz requirement than to the Grundschutz measure. This is exactly where the confusion from the first paragraph comes from: the auditor asks about an objective, the head of IT answers with a configuration.

How to keep the levels apart

• Module: Which target object does this apply to? The answer is a name, for example SYS.3.4.
• Requirement: What must be fulfilled, and how binding is it? The answer is an audit point with MUST or SHOULD, for example SYS.3.4.A2.
• Measure in the Grundschutz sense: How is it fulfilled in our organisation? The answer is something you can show.
• Control, called "Maßnahme" in the German ISO version: Which Annex A objective is addressed? The answer is a number from Annex A and a justification in the Statement of Applicability.

In practice this means: in a security concept, requirement and measure belong in separate columns. If the "implementation" column only says "fulfilled", the measure is missing. If it lists a configuration without reference, the requirement is missing. And anyone running Grundschutz and ISO side by side should say, with every "measure", which world the word comes from.

Sources

BSI IT-Grundschutz Kompendium, 2023 edition, chapter "IT-Grundschutz – Basis für Informationssicherheit", sections on modules, structure of the modules and modal verbs (German). ISO/IEC 27001:2022, Annex A, and ISO/IEC 27002:2022 (in substance, text of the standard protected by copyright).

In the next part: Grundschutz check, internal review, audit. Who audits, against what, and with what consequence.

The previous part: A policy is not a guideline.