grundschutz-worksheets — the BSI's Grundschutz++ catalog as a checklist and an OSCAL chain.
The BSI publishes Grundschutz++ in machine-readable form, as OSCAL. grundschutz-worksheets turns it into one row per requirement, sortable by the kind of evidence it needs. It also writes the OSCAL documents of an ISMS: profile, security plan, assessment plan, assessment results and POA&M. You check against the running system, not against your own documentation.
- In use: in my own ISMS, for the profile, security plan, assessment plan, assessment results and POA&M. The mappings to NIS2, DORA, C5 and SOC 2 are built but neither in use nor reviewed.
- Version: v1.10.0, tested at a fixed commit of the BSI library; follows BSI-Standard 300-1
- Requires: Node 24 or later;
worksheet.mjsneeds no install - Licence: MIT · the catalogs © BSI, CC BY-SA 4.0, fetched at run time
The check nobody can repeat
Until now
- The requirements sit in PDFs and spreadsheets that someone compares by hand
- Which version of the catalog applied is written down nowhere
- The security plan is a text someone writes, and it goes stale
- What does not apply, and why, is in another document
With grundschutz-worksheets
- One row per requirement, with modal verb, action word and kind of documentation, as a Markdown checklist or CSV
- Every output names the commit of the BSI library; a run against a newer commit shows what changed in the diff
- The security plan is assembled from profile, component definitions and assessment results; the same inputs give the same bytes
- Requirements that do not apply are in the profile with their reason
Does it fit my ISMS?
Use it if …
- you align your ISMS with Grundschutz++ or want to map your ISO 27001 Statement of Applicability onto it
- you want a check you can repeat, at a fixed version of the catalog
- you collect evidence from operations and want to keep it as OSCAL
- a command line and JSON files are enough for you
Don't use it if …
- you expect a verdict or a certification: the tool assesses nothing for you and is not legal advice
- you must rely on the mappings for NIS2, DORA, C5 or SOC 2: they are unreviewed drafts and must be checked against the original texts before any audit
- you are looking for a user interface with users, roles and approvals
- you want to check against “the latest version”: nothing runs without a commit
Why one row per requirement
The BSI publishes Grundschutz++ in the Stand-der-Technik-Bibliothek. Every requirement is a JSON object with a fixed grammar: a subject, a modal verb (MUSS, SOLLTE, KANN), an action word and the kind of documentation the evidence belongs in. The tool flattens that. Then you can sort by the kind of evidence a requirement needs.
The action word alone says a lot. “Aktivieren” or “verschlüsseln” asks for a configuration and a measurement showing it is in effect. “Überprüfen” or “testen” asks for a dated run. “Verankern” or “dokumentieren” asks for a document. How I checked my own documentation this way is described in the blog post about it. The series Grundschutz++ as code tells how the OSCAL chain grew out of it.
Two rules are built in. Nothing runs without a commit of the library, because the library is republished all the time. And nothing is dropped silently: mapping targets the catalog does not know are listed on stderr at the end.
How a checklist is made
A preset names the catalog, the mapping and the commit the repository is tested at. There are eleven, from the whole catalog to SOC 2:
node worksheet.mjs --presets
node worksheet.mjs --preset iso27001 --sources @soa.txt --format csv
node worksheet.mjs --preset gspp --levels normal-SdT --summary
A row of the Markdown checklist looks like this:
- [ ] **KONF.2.1** Grundkonfiguration für Systeme · normal-SdT · SOLLTE · dokumentieren
Konfiguration für IT-Systeme SOLLTE eine Grundkonfiguration dokumentieren.
The applicability becomes an OSCAL profile, one run of a check becomes assessment results. Every document is validated against the NIST schema:
node profile.mjs tailoring.json > profile.json
node results.mjs run.json > results.json
node validate.mjs profile.json results.json
The profile names the catalog with its SHA-256. Requirements that do not apply are listed there with their reason, and so are your values for the catalog's placeholders: [jährlich] instead of [regelmäßig].
What BSI-Standard 300-1 requires
Since 26 October 2026, BSI-Standard 300-1 describes the method behind Grundschutz++. The catalog says what is required. The standard says how a package of requirements is put together and what follows when a requirement is not met. Where the tools touch that, they follow the standard:
package.mjsderives the package from business processes, protection needs and assets. The requirements of the method and all without a target-object category are always in it.- There are three states: fulfilled, not fulfilled, not applicable. An unfulfilled SOLLTE requirement is temporary or permanent. Permanent takes a risk analysis and an approved residual risk, and is impossible for a MUSS requirement.
- The risk register asks for the minimum of Annex 3: risk owner, protection goals, risk level, treatment and measures. A temporary acceptance needs its end date, the implementation plan the owner's approval.
- Requirements of your own, in the format of Grundschutz++, complete the package where the catalog does not cover an asset.
- Every review names who checked. Every measure names who answers for it.
The tools check that the record is complete, not that it is right. The risk analysis stays the institution's work, and none of this replaces a certification. The whole chain as a template to copy, with measurements every night: grundschutz-starter.
The documentation
Presets and mappings
Eleven named audit scopes: the whole catalog, ISO 27001 and IT-Grundschutz through the BSI's mappings. Plus NIS2, the Implementing Regulation, DORA, C5 and SOC 2 as unreviewed drafts.
The OSCAL chain
Profile from the applicability, component definition per build, security plan, assessment plan, assessment results and POA&M. Plus coverage per standard and a report over a period.
Versions
currently v1.10.0
Every version as a tag vX.Y.Z, tested and validated against the NIST schema at the BSI library commit that tools/bsi-library.mjs names.
GitHub
Node 24 or later
Source code, changelog, issues. A pull request is not merged on GitHub; I carry the change over by hand. MIT.
Grundschutz++ in your own ISMS?
I help you get started: the applicability as a profile, the first checks from operations, a security plan built from data instead of text.