Compliance and BSI IT-Grundschutz
How NODE64 maps its checks to the requirements of BSI IT-Grundschutz and ISO 27001 – and where the limits are.
What this view is #
NODE64 maps each of its checks to the requirements of two frameworks:
- BSI IT-Grundschutz – the modules of the German BSI compendium, for example
SYS.1.3(servers running Linux and Unix) orNET.3.2(firewall). - ISO/IEC 27001:2022, Annex A – the controls of the current edition, for example
A.8.9(configuration management).
Under Security → Frameworks you no longer see only "SSH permits password authentication", but also which requirement this touches and how the system stands overall. The card stays collapsed until you open it – collapsed, it shows one sentence with the balance.
The PDF security report contains the same section, per device and across the whole account.
Three states, not two #
Every requirement sits in exactly one of three states:
| State | Meaning |
|---|---|
| met | All linked checks ran and raised nothing. |
| not met | At least one linked check produced an open finding. |
| not technically verifiable | There is no linked check, or none of them could be assessed on this system. |
The third state is the important one, and it is the reason the number at the top does not read "93 % compliant".
Many requirements are organisational. OPS.1.1.2 ("proper IT administration") calls for role concepts, deputisation rules and documentation. A tool that reads configuration files cannot speak to any of that – and does not pretend to here. It shows the requirement, marks it as not verifiable, and leaves it out of the ratio.
A percentage that quietly counts those requirements as met would be a lie. The ratio therefore refers exclusively to the technically verifiable requirements, and the number of the remaining ones stands next to it everywhere the ratio appears.
Thin evidence #
A green tick can rest on very different ground. If a module has fourteen linked checks but only six of them ran – because the agent could not read the relevant configuration – then the requirement is not violated, but it is not really evidenced either.
Such cases carry the note thin evidence. What exactly was missing is listed in the report under "What could not be checked".
Accepted findings #
A finding you deliberately accepted or deferred still counts as not met. That is intentional: an accepted risk is a documented risk, not a resolved one. So the difference stays visible, the requirement is additionally marked exception documented – in an audit that is precisely the interesting line.
Across several devices #
In the account report, a requirement counts as met only if it is met on every device. The "Devices" column gives the number of systems that are out of line.
An average across all servers would make exactly the one host disappear that you are reading the report for.
Mapping at module level #
Mapping happens at the level of modules (SYS.1.3) and controls (A.8.9), not at the level of individual requirement numbers such as SYS.1.3.A5.
The reason is simple: the individual BSI requirement texts are protected by copyright and have to be quoted verbatim. An invented or misplaced number would be worse in an audit than none at all. Anyone who has the compendium at hand can refine the mapping in operation – the database already carries the finer level.
What this is not #
This overview is an implementation aid. It is not a certification, not an attestation and not evidence towards any authority.
Certification against BSI IT-Grundschutz or ISO/IEC 27001 covers the entire information domain including all organisational aspects and is carried out solely by accredited bodies. NODE64 can take the technical part off your hands – collect the evidence, show the actual state and name the gaps. Not the rest.
CIS Benchmarks are deliberately not included. Their licence terms restrict commercial reuse; a mapping against them could not be shipped cleanly.