Why is a one-off scan or pentest not enough?

Because both are snapshots. New vulnerabilities are published continuously (more than 48,000 CVEs in 2025, over a hundred a day) and your own environment changes constantly: new systems, expired certificates, a colleague switching on a service. A report that is six months old may describe an organisation that has since become materially different.

Is vulnerability monitoring mandatory under NIS2?

No, no product or service is mandated by name. But the NIS2 duty of care is continuous in nature: you must manage your risks on an ongoing basis and be able to demonstrate it. Periodic, dated reports from monitoring are a practical and affordable form of evidence for that, not a legal requirement in themselves.

What is the difference between vulnerability monitoring and a SIEM or EDR?

They look at different things. Vulnerability monitoring watches your outside: which weaknesses can an attacker see and abuse, before anything happens. SIEM and EDR watch the inside: they detect suspicious behaviour once something is already under way. Prevention and detection complement each other.

What should I expect from good vulnerability monitoring?

Four things: discovery of your full external attack surface (including forgotten systems), periodic detection of vulnerabilities, prioritisation by actual risk, weighing exploit likelihood and exposure alongside the severity score, and dated, traceable reports you can use as evidence towards customers, auditors or regulators.

Back to knowledge base

What is vulnerability monitoring, and why a one-off scan is not enough

Published on July 11, 2026 · Updated on August 4, 2026

Many organisations have done something by now: a penetration test last year, a security scan during the last website overhaul, an internet.nl check with a nice score. The report sits in a drawer and the feeling is: this is taken care of. That feeling is understandable, and possibly premature. Because the question that matters is whether you know where you stand today.

That is precisely the gap vulnerability monitoring fills. This article explains what it is, why a snapshot ages so quickly, and what you as a decision-maker should demand from it.

What is vulnerability monitoring?

Vulnerability monitoring is the continuous, automated surveillance of your systems for vulnerabilities: known weaknesses in software, configuration errors and services that are unintentionally exposed to the internet. External monitoring does this from the attacker's perspective: everything visible from the outside is periodically re-examined. That outside-in perspective is also known as external attack surface management or EASM.

The difference with a one-off scan is not in the technology but in time. A scan answers the question "where did I stand on that date?" Monitoring answers the question your customer, auditor and regulator actually ask: "where do you stand now, and how do you keep track?"

Note also the distinction from vulnerability management. Monitoring is the continuous signalling of your external attack surface: the layer that notices what changes and what goes wrong. Vulnerability management is the broader process around it (discover, prioritise, remediate, verify and start again) in which monitoring provides the continuous signalling layer. Without that layer, the rest of the process runs on outdated assumptions.

Why a snapshot ages so quickly

Three clocks are ticking at once, and all three tick against you:

New vulnerabilities. New CVEs are published continuously: more than 48,000 in 2025, over a hundred a day. The software that was secure at your last test may turn out to contain a critical vulnerability next week, without anything changing on your side.
Your own infrastructure. Organisations change constantly: a new SaaS integration, a test environment accidentally left public, an expired certificate, a marketing agency creating a subdomain. It is precisely that shadow IT emerging outside the IT department's view where incidents tend to originate.
Attackers already scan continuously. Malicious automated scanners probe the entire internet around the clock. The gap between the publication of a vulnerability and its first abuse is sometimes measured in hours. If you look only at long intervals, you fall behind what the adversary already sees.

The practical consequence: a pentest or scan report that is six months old may describe an organisation that has since become materially different. As evidence towards an auditor it then offers less convincing proof than a current, periodic report, and the same holds as steering information for yourself.

What NIS2 and your supply chain make of this

The duty of care under NIS2 and the Dutch Cybersecurity Act is phrased as an ongoing obligation: managing risks is a continuing duty, approved and overseen by the board. Nowhere does it say you must buy monitoring for that; no tool whatsoever is mandatory. But demonstrating that you continuously meet your duty of care is considerably easier with a stack of dated, periodic reports than with a single report that is eighteen months old.

The same applies in the supply chain. A supplier who fills in a supplier questionnaire with "our external systems are scanned monthly, last month's report attached" stands out, for example, from a competitor pointing to an outdated pentest. Auditors look for repeatable, dated evidence.

That is also the vantage point from which we look at this subject. Exposentry is built on OpenKAT, the open-source scanning platform to whose upstream repository Edward Hasekamp of Hasecon contributes as a collaborator. That colours our approach, which comes down to the difference between paper and measurement: a completed questionnaire or a policy document is a claim, whereas a dated measurement of your actual attack surface is evidence. We call this evidence-first monitoring, or evidence-driven monitoring: measuring what is actually exposed to the internet.

What good vulnerability monitoring includes

Anyone procuring monitoring, or assigning it internally, should demand four components:

Discovery. First know what of yours is exposed to the internet: domains, subdomains, servers, services. Monitoring that only looks at the systems you list yourself will by definition miss the forgotten ones, and that is exactly where the risk sits.
Detection. Periodic, automated examination of all those systems for known vulnerabilities and configuration errors. Weekly or monthly, at a fixed cadence.
Prioritisation. Not every finding deserves the same urgency. Good monitoring weighs whether a vulnerability is actually being exploited in the wild, so your IT team or provider fixes the right things first. How that weighing works is explained in EPSS and KEV explained.
Reporting as evidence. Dated, traceable reports in language understood outside the IT department too, usable towards the board, customers and auditors. How to get from a technical list to board-level steering information is described in from CVE list to board report.

Monitoring complements detection inside your network (SIEM, EDR) and a targeted penetration test on your critical applications. It is the preventive outer layer: it signals whether the basics stay in order, so you can steer in time; remediation itself remains with your IT team or provider. What that costs, you can see under plans and pricing.

Conclusion

Vulnerability monitoring converts a snapshot into a continuous answer. For the board, it changes the question you put to your organisation: "when did we last look, what was found, and has it been fixed?" Whoever can answer those three questions every month has the core of their duty of care demonstrably in order.

Exposentry delivers vulnerability monitoring as a service: continuous scans of your external attack surface based on OpenKAT, with monthly, forensically substantiated reports you can use directly as evidence. Starting need not be a big undertaking: begin with a baseline scan that inventories what of yours is exposed to the internet, and let it settle into a fixed monthly cadence. See the plans and pricing or start today with a baseline scan to see where you stand.

Written by Edward Hasekamp, founder of Exposentry and collaborator on the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides EU-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.