grundschutz-viewer — the Grundschutz++ catalog next to what your documents say about it.

An assessment result in OSCAL is JSON. To know where a requirement stands, you need the profile, the security plan, the results and the POA&M at once, plus the BSI's catalog. grundschutz-viewer reads these documents and writes one HTML page from them. It needs no server and can be read offline. Per requirement it shows the state, the measurement, the action with its due date and the history over every run.

Status: v0.1.0 since October 2026, built for the grundschutz-worksheets chain; not yet in use in my ISMS
Install:go install github.com/ohartwig/grundschutz-viewer/cmd/grundschutz-viewer@latest
Requires: Go 1.26 to build, OSCAL documents from grundschutz-worksheets or your own
Licence: MIT · no dependencies beyond the standard library

Evidence nobody reads

Until now

The state of a requirement is in the security plan, the measurement in a result, the due date in the POA&M
Nobody checks while reading whether an import points to the right file
What changed since yesterday only shows up in a diff of two JSON files
Anyone who doesn't read JSON gets a table someone copied by hand

With grundschutz-viewer

One page across all runs: state, measurement, action and due date sit next to each requirement
Every import is looked up and checked against the SHA-256 it names; the page says what does not match or is missing
The history shows which requirements changed in each run, and when each requirement changed
The file can be sent around and opened offline, with no server and no account

Does it fit my evidence?

Use it if …

you keep your Grundschutz++ state as OSCAL, for example with grundschutz-worksheets
checks run every night and you want to see what changed since the last one
people who don't read JSON should see the state without anyone keeping a table
the view should work without a server, as a file among a pipeline's artefacts

Don't use it if …

you want a tool to edit the state: the page is read-only
your catalog is not Grundschutz++: other OSCAL catalogs are untested
you need one view over many systems at once: a page shows one security plan
you need an English interface: the page is in German, like the catalog

Why a page and not an application

grundschutz-worksheets writes the OSCAL chain: profile, assessment plan, results, security plan and POA&M. Tools read those files, people do not. The viewer makes them readable for people. It should run where the evidence is made: as a pipeline step that drops one file into the artefacts.

So there is no server, no database and no account. The data is in the page, and the page stands on its own. Which catalog applies, from which commit of the BSI library and with which parameter values, it reads from the profile. There is no setting of its own for that. The ISO 27001 column comes from a mapping collection among the inputs. Without one, the viewer uses the BSI's mapping at the same commit as the catalog.

How the page is made

The viewer reads a folder with all its subfolders. One folder per run makes the history:

grundschutz-viewer -o grundschutz.html runs/

Single files work too, mixed with folders:

grundschutz-viewer -o grundschutz.html security-plan.json results-*.json profile.json

Instead of the explorer, you can render the register: an overview by practice with its own tabs for checks, plan of action, standards and threats:

grundschutz-viewer -view register -o register.html runs/

A run is a security plan and the documents next to it. The newest run is the state the page shows. Every run before it is a point in the history. If an import is not among the inputs, usually the BSI catalog, the viewer fetches it, checks the SHA-256 and caches it. With -offline it fetches nothing.

What it looks like

The screenshots show example data from a made-up company, Example GmbH, over seven nightly runs. The five checks from grundschutz-checks did the measuring; an owner review and a plan of action with due dates complete the picture.

The overview shows the state of the newest run and, below it, every earlier run with the requirements that changed in it. A requirement's record holds its history: one box per run, the oldest on the left, and below that, when the measurement changed. The register orders the same requirements by practice.