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.7.0, tested at a fixed commit of the BSI library
- 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].
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.7.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.