Grundschutz++ against my own documentation

01 — Where it started

My ISMS follows ISO 27001. There is a Statement of Applicability, registers for risks, assets and suppliers, and evidence for every control. Everything is versioned as Markdown in a repository. The setup is small: one business, one platform, a few customers.

With Grundschutz++ the BSI rebuilds its IT-Grundschutz. The requirements are published machine-readable in the Stand-der-Technik-Bibliothek. The question was simple. Does my ISMS hold up, and where does it not?

02 — Bringing Grundschutz++ and ISO 27001 together

Grundschutz++ no longer orders requirements by modules the way IT-Grundschutz used to. They are grouped by practices, for example DET for detection, KONF for configuration or NOT for contingency. Every requirement has an ID, a text and a level. The level is normal or elevated and follows the protection need.

The biggest change is the format. The BSI publishes the requirements machine-readable in the state-of-the-art library. Nobody has to copy a PDF any more. A script can read the whole list, and no requirement gets lost in transfer.

The bridge to ISO 27001

An ISO 27001 ISMS already has a Statement of Applicability. Clause 6.1.3 d requires it. It lists the 93 controls of Annex A in the 2022 edition, each with the reason why it applies or not. The library contains a mapping from these controls to Grundschutz++.

That mapping produces the checklist. Every applied Annex A control brings its mapped Grundschutz++ requirements. In my case that was 280. Anyone running an ISO 27001 ISMS does not start from zero. The Statement of Applicability defines what to check.

03 — Normal and elevated: where the technical difference lies

The normal level is the baseline for any operation. The elevated level applies where the protection-need assessment shows a high need. The library states the level of each requirement. Whether it applies to your operation depends on your own protection need. The mapping to ISO 27001 does not make that decision for you.

The difference by example

The pairs below show how far apart the levels are. They are paraphrased summaries, not the BSI wording.

• Logging: At the normal level, security-relevant events are collected centrally and retained. Elevated adds access to individual objects: who read which backup, and when? Plus rules on which data never ends up in a log.
• Detection: Normal means detecting and reporting attacks at the network edge and on hosts. Elevated adds anomalies in the application itself and dedicated detection of data exfiltration.
• Capacity: Normal is an alert when a disk fills up. Elevated plans capacity with trends and reserves before an alert is needed.
• Vulnerabilities: Normal tracks advisories for the software in use. Elevated adds regular penetration tests and an active search of public sources for your own attack surface, for example certificate transparency logs.
• Contingency: Normal means backups that can be restored and are tested. Elevated adds a copy in a separate location and deletion protection that administrator rights cannot bypass.

How I treated the elevated level

I answered all requirements at the normal level. At the elevated level there were three classes:

• Already met: the control was running, often as a by-product of another one.
• Low-hanging: doable in a day at most, without a new component. I implemented these right away.
• Deliberately open: the effort does not match the protection need. These are marked, with a reason. They do not sit in a plan nobody executes.

The third class matters most. An open requirement with a reason is a decision. An open requirement without one is a gap. In ISO 27001 that decision belongs in the risk treatment plan, approved by the risk owner.

04 — The method: configuration, not documents

The most important rule of the check: a requirement counts as met when the system shows it. A page claiming it is not enough.

Three kinds of evidence

• Configuration: a setting in the repository that enforces the behaviour. For example a rule that only maintainers may create release tags.
• Measurement: a query against the running system, with a date. For example whether an alert rule is loaded and whether its metric actually arrives.
• Document: only where nothing else works, such as organisational rules or contracts.

The kind of evidence and the date of measurement sit on every line. That sounds pedantic. It is the difference between a check and comparing two texts. Whoever lays documents against documents checks whether the documentation agrees with itself. It almost always does.

Clear rating rules

• Met: the requirement is fully implemented and evidenced.
• Partly: the control exists, but a part is missing. An alert that reaches nobody, or a process without evidence. The missing half is written on the line.
• Not met: there is no control, or only a claim.
• Not applicable: the requirement does not fit the operation. The reason is stated, as in the Statement of Applicability.

One rule turned out to be especially important: a control that only exists on paper counts as not met, not as partly. Otherwise the middle of the scale becomes a hiding place.

05 — The figures

Of the 280 requirements, at the end of the check (26 September 2026):

• 113 met,
• 115 partly met,
• 29 not met,
• 23 not applicable.

The large middle is typical for an ISMS that is technically in good shape. The control runs, but one link of the chain is missing. An alert fires but reaches nobody. A backup runs, but the restore test checks an earlier architecture. Only someone who measures the whole chain sees such gaps.

The 29 gaps are unevenly spread. Technical requirements, on logging, backups or configuration, could often be closed the same day. What stayed open were mostly organisational requirements: management review, awareness, supplier contracts. Those need appointments, not merge requests.

06 — The actual finding

I expected missing controls. What I mostly found was documentation that no longer matched. In both directions.

Patterns that repeated

• Planned, never built: the documentation described a component that never existed. It was meant as the next step and stayed as a fact.
• Evidence for the wrong architecture: a record described a setup that had long been replaced. Formally complete, worthless in substance.
• Alert without a signal: a rule checked a metric that was filtered out before. Such a rule raises no error. It simply stays silent.
• The other way round: controls were already running that the documentation listed as missing. That is an error too. Whoever reads the documentation plans work that is already done.

In small organisations this is almost inevitable. The documentation is written once, carefully and completely. Then the system moves on and the documentation does not. Nobody lies. Nobody checks.

07 — What I am changing

The changes start where ISO 27001 already asks for something. They make the requirement checkable.

• Measured on, per 7.5: documented information must be controlled and current. Every statement about the state of the system carries the date it was measured. A statement without a date is a claim.
• Evidence only via dated amendment, per 7.5.3: a record is not rewritten when it turns out wrong. It gets a dated amendment. What was known when stays visible.
• Alerts that can fire, per Annex A 8.16: a new rule only counts as done once it is established that its metric arrives.
• Detecting drift automatically, per Annex A 8.9: a daily tofu plan reports when the infrastructure deviates from the code. The first run found a real error right away.
• The check as an internal audit, per 9.2: it repeats instead of staying a one-off. Findings go into the improvement register as corrective actions under 10.2.

08 — What this means for an ISO 27001 audit

An auditor does not check whether the documentation looks nice. They check whether the documented controls are effective. They sample: show me this setting, this alert, this restore test.

That is exactly where outdated documentation surfaces. A control that only exists on paper is a nonconformity. If the pattern repeats, a minor nonconformity quickly becomes a major one, because control of documented information under 7.5 is then in question as a whole.

What the check does beforehand

• It finds the samples an auditor would draw, before the auditor does.
• It provides dated evidence for every Annex A control.
• It shows openly what is deliberately not implemented. That belongs in the risk treatment plan under 6.1.3 and needs the risk owner's approval.
• It gives the management review under 9.3 a solid basis instead of a feeling.

Grundschutz++ does not replace a certification. It is, however, a very precise yardstick for what the state of the art is. Whoever checks their Statement of Applicability against it goes into the audit better prepared.

09 — The tool

For the check I wrote a small Node script. It reads the library and the ISO 27001 mapping and matches both against my own Statement of Applicability. The output is one worksheet per practice with all mapped requirements, their level and an empty column for source and finding.

The script does not do the rating. It only makes sure no requirement is overlooked. Answering stays manual work, and that is the part worth doing.

10 — My assessment of Grundschutz++

After one full pass my verdict is mixed. Overall it is clearly positive.

What convinces

• Machine-readable: the requirements can be read in full, filtered and versioned. If your evidence already lives in a repository, check and documentation come together.
• The bridge to ISO 27001: the mapping saves double bookkeeping. The Statement of Applicability stays the leading document; Grundschutz++ adds the depth.
• More concrete than Annex A: where ISO 27001 only names a control, Grundschutz++ often says what it means in operation. That makes rating less a matter of interpretation.
• Levels instead of all-or-nothing: separating normal and elevated forces a conscious decision per requirement.

What takes work

• The mapping is not one-to-one. One Annex A control pulls in several requirements, and some requirements hang on several controls. You merge duplicate lines yourself.
• Appropriate stays interpretation. Many requirements ask for something appropriate. What is appropriate follows your own protection need. Without a documented protection-need assessment every rating can be challenged.
• No tooling for the rating. The library provides the requirements, not worksheets or evidence handling. Everyone has to build that.
• Small businesses have to cut. Some requirements assume an organisation with several roles. With one person in operations you need a justified adaptation, not blind adoption.

My conclusion: Grundschutz++ works as a yardstick for an ISO 27001 ISMS, especially in small businesses. It pays off most for those who treat the check as a measurement, not as a form.

Conclusion

The check against Grundschutz++ found fewer missing controls than expected. Above all it showed where the documentation no longer fits the system. That is the part that costs most in an ISO 27001 audit. The Statement of Applicability provides the checklist, the library's mapping provides the requirements. The rest follows from one simple rule: only count what the system shows, and date every statement.