Grundschutz++ as code, part 7: One measurement, many standards
A service provider with ISO 27001 falls under NIS2 and is asked by a customer for a SOC 2 report. Three standards, three spreadsheets, three times the question about multi-factor sign-in. At heart they ask for the same thing. What is missing is a machine-readable statement of what corresponds.
OSCAL has a model of its own for that, the mapping collection. I built mappings for four standards, after feedback at the InfoSec-Stammtisch and not for myself: my ISMS measures against Grundschutz++, and that is enough for me. This part shows what they make possible and where it ends.
Part 7 of the series “Grundschutz++ as code”. The overview of all parts is further down.
01 — What a mapping is in OSCAL
A mapping collection says, for every requirement of a source catalogue, which requirements of a target catalogue correspond to it. Every mapping carries a relationship: equal-to, equivalent-to, subset-of, superset-of or intersects-with.
The relationship is the real content. intersects-with means: the targets cover part of it, not all. The model arrived only with OSCAL 1.2.0 in December 2025.
02 — Grundschutz++ as the hub
Next to the catalogue, the BSI supplies a mapping from ISO 27001 Annex A onto Grundschutz++. For NIS2, DORA, C5:2026 and SOC 2 there is none. Mine follow a simple principle. Every source requirement names the Annex A controls it corresponds to. The Grundschutz++ targets then follow from the BSI's mapping.
The only judgement I make myself is the step to ISO. A reviewer can check it against a list she knows. Where Annex A is silent, I set direct targets, for risk analysis, multi-factor sign-in, handling vulnerability reports and exit strategies, for example.
- ISO 27001:2022 Annex A: the BSI's mapping, 280 Grundschutz++ requirements.
- NIS2: Art. 21(2)(a) to (j), that is § 30(2) nos. 1 to 10 BSIG, 187 requirements.
- NIS2 Implementing Regulation: the 49 headings of the Annex of Regulation (EU) 2024/2690, step to ISO by ENISA, 223 requirements.
- DORA: Art. 5 to 30, 176 requirements.
- C5:2026: 168 criteria, 384 requirements.
- SOC 2: CC1 to CC9, A1 and C1, 231 requirements.
For part of NIS2 I do not have to take the step to ISO myself. Implementing Regulation (EU) 2024/2690 makes Art. 21 concrete for DNS and cloud providers, data centres, managed service providers and other digital services, in 161 numbered requirements. With its implementation guidance, ENISA published a table that assigns the matching ISO 27001 controls to each heading, under CC BY 4.0. The preset nis2-ir takes over exactly that assignment, and a tool checks that it is still ENISA's.
It still takes some reading. The column is typed by hand: here a Greek alpha stands where an A is meant, there a dot is missing. The tool reads it by fixed rules and rejects anything that is not a control of the 2022 edition. A judgement of mine remains in just two headings, for which ENISA names only clauses of the management system.
03 — What the report says per standard
The measurements are against Grundschutz++. coverage.mjs follows the mapping. Per NIS2 paragraph or SOC 2 criterion it says what the measurements tell about it. It says no more than the mapping allows. It knows five states: satisfied, partial, not satisfied, not measured and no mapping. “Satisfied” is possible only through a relationship that claims full coverage. Through intersects-with everything stays “partial”, even if every measurement is green.
node coverage.mjs --preset nis2 results/*.json
The report starts with the gaps, not with a percentage. This is what it looks like over the results of one night, measured with the five checks from part 8 in a test run on 13 October 2026:
10 requirements · mapping nis2-to-gspp.json (status draft) · results from 5 file(s)
- Not measured: 6 -- nothing evidences them; they are not satisfied by default.
- Draft mapping: every row below rests on a mapping not yet reviewed by a person.
- Not satisfied: 2
- Partial: 2
- Satisfied: 0
Six of the ten points of Art. 21(2) are not measured at all. Two count as not satisfied, because the update check had a finding. The other two stay partial, although their measurement was green. The relationship is intersects-with. And of seven and fifteen targets respectively, only one is measured. Nothing is satisfied, and that is exactly the honest answer.
04 — Why “fully covered” is refused
All four mappings are drafts, written with AI help and not yet reviewed by any person. As long as that holds, the generator rejects every relationship that claims full coverage. Only once a review sheet has been ticked off may a mapping say subset-of.
The tool produces the sheet as well: per source the remark, the step to ISO and every target with its title and a box to tick.
node worksheet.mjs --preset soc2 --sources 'CC6.*'
A mapping is a claim. It does not turn a measurement into evidence for another standard. It only says how far the measurement reaches.
05 — What cannot be mapped
Some things Grundschutz++ does not ask for, and the mapping says so with a reason. DORA Art. 19, the reports to the supervisor, is such a case. In C5, INQ-01 to INQ-04, requests from authorities for customer data, have no target.
A gap with a reason is worth more than a forced hit.
06 — The laws themselves as a catalogue
For NIS2 and DORA there is no official OSCAL catalogue. The generator builds one from the German text in the Official Journal and checks the address and SHA-256 of every document. It rejects any other bytes, and it changes nothing in the wording except whitespace.
So the review sheet shows the text of the law right next to the targets.
07 — A catalogue without text
For SOC 2 that was not possible. The Trust Services Criteria belong to the AICPA. After registering you can read them for free, but you may not pass them on. For almost everything a chain does with a standard, though, it does not need the text at all. Mapping, assessment plan and result point to identifiers. The wording is read by a person who judges whether a target fits. She has the source open anyway.
standards/soc2.json therefore holds the 61 criteria of the 2017 edition with the revised points of focus of 2022. Each carries its identifier, a title in my own words and a note on where the text is. The metadata carry text-reproduced=none. So a tool knows, too, that no wording is reproduced here. The generator refuses a duplicate identifier, a criterion outside its series and a count that does not match the source.
The same pattern works elsewhere. C5:2026 is published machine-readable, but under CC BY-ND 4.0, so my mapping uses only the identifiers. For ISO 27001 Annex A, the control numbers and short titles of my own are enough. This is not legal advice: whoever wants to publish checks the licence of the standard in question.
08 — What a mapping is not
- No audit: a NIS2 report from the mapping does not replace an assessment under NIS2. It shows which measurements contribute to which paragraph.
- No SOC 2 report: that is written by an audit firm. The chain gives it the material for one, namely dated results of the same checks over a period, readable per criterion. Part 8 is about that.
- Not in use here: the mappings are built and tested. My own ISMS does not need them.
09 — The series at a glance
- Grundschutz++ against your own documentation: the method, the catalogue as a data model, the comparison with IaC and GitOps.
- Applicability as data: the statement of applicability as an OSCAL profile.
- Containers that say which requirements they meet: a signed component definition on every image the pipeline builds.
- Measurement as evidence: checks write their results as OSCAL, dated, signed, impossible to delete.
- The ISMS as a build product: security plan, assessment plan, results and plan of action as an OSCAL chain, rebuilt with every measurement.
- What no repository knows: the second level, the running system against its code.
- One measurement, many standards: NIS2, DORA, C5 and SOC 2 as mappings onto Grundschutz++. This post.
- The chain to take away: general checks, the report over a period and a template that wires it all together.
Parts 1 to 6 describe what runs in my ISMS. Each appears only once its step runs in operation and has been measured. Parts 7 and 8 show tools I built after feedback at the InfoSec-Stammtisch and do not use myself. The code is in grundschutz-worksheets. A map of the whole series is OSCAL in practice: eight models, one chain.
Frequently asked questions
Does this replace a NIS2 audit?+
No. It shows which measurements contribute to which paragraph and where nothing measures.
Can I use a mapping of my own?+
Yes, with --mapping-file. The same rule applies to your own mapping: full coverage only after a person has reviewed it.
Why not map NIS2 straight onto Grundschutz++?+
Because the step via ISO can be checked. Reviewers know Annex A, and the BSI's mapping does the rest.
Why is the SOC 2 text not in the catalogue?+
Because it belongs to the AICPA. Identifiers are enough for every mapping.
Conclusion
Mappings are tempting, because one measurement turns into five reports. That is exactly why each needs a rule that refuses full coverage until a person has reviewed it. Otherwise a green branch protection becomes a satisfied NIS2 criterion, and nobody ever claimed that.
I do not use the mappings myself. But whoever has to evidence several standards at once gets an honest answer to how far their own measurements reach.
Continue with part 8: The chain to take away.
I show you how far your measurements reach for NIS2, DORA or SOC 2, and where they don't.
Mappings onto Grundschutz++ as OSCAL, a report per standard that starts with the gaps, and review sheets a person uses to tick off every mapping before it may claim more.
Platform operations instead of consulting on paper: if you like, I connect the mappings to the checks you already run.
About the author

Kai Ole Hartwig
Programming since 2002 – self-taught, set up my own business with KO-Web in 2012. Over 100 projects, with a focus on security, performance, automation and quality. Today freelance: DevSecOps consulting, training and software development.