Scanning is not NIS2 compliance — but it is a necessary building block
Published on May 26, 2026
There is an appealing promise in the market: buy a scanner, run a report, and you are "NIS2 compliant". It sounds reassuring, but it is not true. We think you should know this — precisely because we offer scans ourselves. A vendor who overclaims undermines the very trust it should be building. This article explains honestly what scanning does and does not do for your NIS2 position.
What NIS2 asks beyond technology
NIS2 and the Dutch Cybersecurity Act (Cyberbeveiligingswet) are about much more than detecting vulnerabilities. The law requires a coherent system of measures, including:
- Governance and board accountability: the board is liable for cybersecurity and must demonstrably steer on it.
- Risk management: an ongoing process to identify, weigh and treat risks.
- Incident reporting: significant incidents must be reported to the regulator within tight deadlines.
- Policy, processes and people: from access management and back-ups to awareness and exercises.
- Supply-chain duty of care: assessing and safeguarding the security of your suppliers.
A scanner does not fully cover any of these elements. A report full of findings does not replace a risk analysis, a reporting process or a board decision. Scanning alone therefore does not make you NIS2 compliant, and anyone who promises that is selling you an illusion. Which other NIS2 claims do not hold up — from "the official mandatory tool" to fixed deadlines — is covered in what the NIS2 supply-chain duty of care really requires.
Why scanning is indispensable anyway
At the same time, the reverse holds just as firmly: NIS2 explicitly names managing vulnerabilities as a mandatory measure. You cannot run credible risk management without knowing which vulnerabilities you actually have. Scanning is therefore a necessary building block: not the whole structure, but a foundation the rest rests on.
It also delivers something regulators and large customers explicitly want to see: defensible evidence for vulnerability management and the supply-chain duty of care. Instead of "we pay attention to security", you put a dated, traceable overview on the table of what was found and what was done about it. If you supply a NIS2-obligated organisation, that is exactly the evidence they need for their own supply-chain duty of care.
From scan result to compliance evidence: how to organise it
The more interesting question is therefore not what a scan does not do, but how you organise the data from a scan into evidence that fits your NIS2 file. That requires four elements per finding:
- Date and origin: when was this found, and how?
- Owner and decision: who picks it up — or why are we consciously accepting this risk?
- Remediation deadline: within which agreed timeframe must it be resolved?
- Re-check: after remediation, was it measured again that the finding is actually gone?
This is also where the difference between an ad-hoc vulnerability scan and continuous monitoring becomes visible. A single scan delivers a snapshot: useful as a baseline, but outdated next month. Continuous monitoring delivers a series of dated measurements — and with that exactly what an auditor wants to see: not that things were fine on one day, but that you keep watch structurally and demonstrably follow up. How you then translate that series into a report the board can steer on, you can read in from CVE list to board report.
Evidence-first: how a finding came about
This is where Exposentry's approach makes the difference. We don't just churn out a list of vulnerabilities. Our scans are built on OpenKAT, the open-source scanner from the Dutch government, which records for each finding how it was obtained: which module looked, at which target, at what moment, and which underlying observation led to the conclusion. What OpenKAT exactly is — and what it is not, such as a mandatory or "official" platform — is covered in what OpenKAT is — and what it is not.
That yields forensically substantiated evidence, comparable to a chain of custody: a chain of observations you can retrace and defend. For a CISO or buyer, that is the difference between a report you have to believe and a report you can verify. If you want to understand which observations sit underneath, read what an attacker sees of your domain.
Trust through not overclaiming
It may seem counterintuitive for a vendor to say what its product does not do. Yet that is precisely what builds the credibility that counts in security. A substantiated, honest report that knows its own limits is worth more in the long run than a compliance stamp that falls apart at the first critical question.
So see scanning for what it is: a strong, demonstrable building block in your broader NIS2 approach. Combine it with your own governance, risk management and processes, and you stand on solid ground.
Get started
Want to begin with that building block? See the plans and pricing or start with a first scan. No empty promises — just sober, forensically substantiated findings you can defend towards regulators and customers.
Written by Edward Hasekamp, founder of Exposentry and core maintainer of the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides NL-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.