What is really running on your systems: why the CMDB is not a measurement

The question every audit starts with

DORA Article 8 and NIS2 Article 21 are written differently and address different sectors. They still begin in the same place: do you know all your IT assets, and can you prove it?

That is the most uncomfortable requirement in the whole text, because it cannot be repaired during the meeting. Everything else depends on it. Risk-based prioritization is only as solid as the population it works on. A remediation deadline only applies to the systems somebody knows about. An asset the security team does not know about is an audit finding that has simply not been written down yet.

From documents to data

There is a structural reason why this question is so hard to answer, and it has been described precisely, including from inside the audit firms. KPMG partner Michael Falk, in a recent piece on cyber governance, sketches a mismatch most security leaders will recognize: companies have long steered production, logistics and sales with data, while information security still rests on manual processes. Evidence sits in PDFs in a filing folder, status reports are assembled by hand, and the basis for decisions is only as current as its last edit. Visibility into your own IT landscape, he argues, is the prerequisite for modern cyber governance: which systems exist, which applications are running, where critical data lives.

We share that diagnosis without reservation. This article is about the point where it becomes concrete: where does that visibility come from, if its traditional source is the very document that has just been named as the problem?

The CMDB is a belief, not a measurement

Almost every organization has a CMDB, an asset database or at least a maintained spreadsheet. These records are rarely set up wrongly. They were correct at the moment they were maintained, and they drift afterwards, quietly and reliably.

The reasons are remarkably similar across industries:

• acquired subsidiaries whose network segments were never fully taken over
• test systems that were set up for two weeks and have been running for three years
• network ranges the scanner was never given, because nobody owned them when it was configured
• systems left over from a project whose owner has long since left the company
• devices someone connected for a good reason and never mentioned again

The usual objection is: that is what our scanner is for. A scanner checks the ranges you gave it. Shadow infrastructure sits, by definition, outside those ranges. A tool that works through the known list cannot correct the list. That is why the next scan mostly confirms what you already believed.

Ground truth from the inside

The alternative is an inventory that is not estimated from the outside but collected on the asset itself. For each asset, our platform records:

• installed packages with their versions
• a software bill of materials in CycloneDX format (SBOM)
• running services
• containers
• local user accounts

This is first-party information: not the export of a database, but the state of the machine at the time of collection. And it is machine-readable from the first second: a CycloneDX SBOM is a structured data format, not a document, and it feeds into whatever central security data platform your data strategy calls for.

The second part is the more interesting one. Wherever the platform is deployed, it also sees the neighboring machines without an agent in the same network segment. Those appear in the inventory as unmanaged assets, with MAC address, vendor and the time they were first seen. Managed, unmanaged and externally reachable assets therefore sit side by side in one inventory, and unmanaged, exposed assets move up in the risk picture. For the outside view, certificate transparency and passive DNS are added: the forgotten, internet-facing assets that appear on no internal list.

What matters just as much is what this is not. It is not a replacement for your CMDB. Ownership, criticality, contractual context and service mapping are your metadata and stay yours; no tool reads them off the network. What a first-party inventory delivers is the ground truth you audit your CMDB against.

And the data stays where it belongs. Telemetry lands only in your own deployment. Our cloud intelligence engine knows the global threat picture, but it holds no customer asset data. Run the platform inside your own boundary and your asset data never leaves the premises; managed hosting stays EU-resident.

Completeness before priority

Only once the population is settled does prioritization become honest. The path from the total set to a list you can act on has four stages:

A CVSS score measures theoretical severity under model assumptions. It does not measure whether a vulnerability is being exploited out there right now, and it knows nothing about whether the affected package is installed on your systems and exposed in your environment. Those two together decide the order, not the number on its own.

And because every deferred vulnerability has to be explained sooner or later: a fixed item is documented by comparing two inventory states, the before and the after of the same asset. Not by another scan, not by a screenshot, and not by a PDF in a filing folder. That is the kind of evidence new standards such as OSCAL and BSI's modernized IT-Grundschutz (Grundschutz++) are pointing towards: controls and proof as structured, machine-readable data rather than documentation.

What stays with you

No tool makes you DORA or NIS2 compliant, and anyone selling it differently is selling you too much. What stays with you:

• the information register and the contract documentation behind it
• the reporting channels and the report itself
• the execution of patches and changes, including your change process
• the judgement of which asset is critical for your business

This matches a point Falk attaches to his data-driven approach: responsibility for prioritization stays with people. That is exactly how we understand our own ordering recommendation, as a body of evidence, not a substitute for judgement. What gets deferred, and which risk the organization carries, is your team's call.

The product boundaries belong in the same paragraph. We are not a scanner: scanners produce the noise, we reduce it. We are not a patch tool: we tell you what to fix, in which order and how, and we document that it was fixed. Automated reconciliation against your CMDB is on the roadmap; today we deliver the record you audit against. The platforms are Linux and Windows, and that is the whole list.

The question that remains

Completeness is unspectacular. It is the highlight of no product demo and it does not fit well on a slide. It still decides whether your prioritization is a statement or a guess.

When was your inventory last checked against reality, rather than against its own previous version?