The controls your client actually asks about
Compliance chips are now one per framework and open to show what they mean, three German frameworks are available - BSI IT-Grundschutz, NIS2 and the CyberRisikoCheck - and a tenant chooses which ones it is assessed against. Four analysers that had been quietly evidencing nothing now evidence something.
Every check Wegweiser runs is mapped to the compliance controls it evidences, and those controls show up on the finding as a row of small chips. It is one of the quietest features in the product and one of the most useful in a room with a client: the machine is not patched, and here is the control that says it should be.
The row had two problems. It was showing you the wrong thing, and for some checks it was showing you nothing at all.
One chip per framework, and you can open it
The strip used to be one chip per control, capped at four, with a +1 on the end when there were more. The +1 was not a button. There was nowhere for it to go. If a check touched five controls you were told that a fifth existed and left there.
The control names were not much better off. A chip could only fit a control number, so the name - the part that says what the control actually requires - lived in a title attribute, which is to say it lived in a tooltip that appears after a second of hovering and which most people never discover.
Now a chip is a framework, not a control. CIS v8 2 means this check evidences two CIS controls. Click it, or hover it on a mouse, and the panel tells you which two and what they require. A check that touches nine controls across four frameworks is four chips, not four chips and a dead number, and the strip stays the same shape whether a check touches two controls or ten.
Frameworks you choose, in the jurisdiction you sell into
The frameworks were fixed: CIS, ISO 27001, Cyber Essentials, NIST. That is a British and American answer given to everybody, which is an odd thing for a product with a German name to do.
Three German frameworks are now available:
BSI IT-Grundschutz. Bausteine from the Edition 2023 Kompendium - OPS.1.1.3 Patch- und Änderungsmanagement on patch compliance, OPS.1.1.5 Protokollierung and DER.1 Detektion von sicherheitsrelevanten Ereignissen on the log analysers, NET.3.2 Firewall, SYS.2.2.3 Clients unter Windows, SYS.1.3 Server unter Linux und Unix, ORP.4 Identitäts- und Berechtigungsmanagement. One note in the open: IT-Grundschutz++ went live on 1 January 2026 and Edition 2023 stays binding through a parallel phase into roughly 2029. These references have a migration ahead of them, not an expiry date.
NIS2, as § 30 Abs. 2 BSIG. The German transposition, cited the way a German auditor cites it. It is a coarse framework by construction - ten measures covering an entire ISMS - so only the numbers an endpoint check can honestly speak to are used: Nr. 2 for incident handling, Nr. 3 for backup and recovery, Nr. 5 for maintenance and vulnerability disclosure, Nr. 9 for access control and IKT-system management.
DIN SPEC 27076, the BSI CyberRisikoCheck. The one with the most direct commercial value for a German MSP, because it is delivered by an IT service provider: a structured interview across 27 requirements in six areas for firms under fifty staff. Requirements are cited by the standard's own Anhang A numbering, so 15-1 on a patch finding is the requirement your CyberRisikoCheck report will number 15-1 too.
And you pick. Settings now carries a Compliance frameworks list, and the chips show only what you tick. A German Systemhaus has no use for Cyber Essentials; a British MSP has none for a Baustein number. If you have never opened the setting, the frameworks follow the language your analyses are written in, so nothing changes for anyone who does not want it to.
Four checks that were evidencing nothing
The mapping is a hand-maintained list, and while we were in there we found out what hand-maintained lists do.
Lynis - the Linux hardening audit - was mapped under one spelling of its name while the database stores another. The lookup is exact, so it matched nothing. Every Lynis audit on every Linux machine had been showing an empty compliance strip, which looks identical to a check that legitimately evidences nothing. Disk health, binary inventory and Windows security posture had never been mapped at all, and Windows security posture is the check that reads Defender, its signature currency, tamper protection and your firewall profiles: about as directly a compliance control as an endpoint check gets.
Between them that was roughly a tenth of everything the fleet produced, evidencing nothing, and none of it was ever an error.
That last part is the reason it lasted. An unmapped check does not fail. It returns an empty list, the page draws no chips, and the result is indistinguishable from the correct answer. So there is a test now: every analyser in the product must either be mapped to its controls or be named, in writing, as one that evidences none and why. Run against the code from before this release, it names eight.
The mapping stays deliberately conservative, which is the other half of being useful here. Wegweiser cannot see whether you have multi-factor authentication switched on, who installed a program, or whether a laptop has a login password. Those controls are absent from the map even where the requirement sitting next to them is mapped. A chip means a check speaks to that control. It has never meant you passed it, and a mapping that overclaimed would be worth less than no mapping at all.