Vulnerability management: the process, the standard, and how to prove it works
Published on July 28, 2026
Vulnerability management sounds like something for large organisations with a security team, but the core is simple: knowing which weaknesses are in your systems, addressing the right ones first, and being able to show it. Search for it in Dutch and you mostly find definitions and translated vendor pages; how the process works and how you demonstrate that it works at your organisation often remains underexposed. This page covers both: what vulnerability management is, how the cycle runs step by step, what ISO 27001, NEN 7510 and the Dutch Cybersecurity Act expect of it, and where the difference lies between saying it is in order and demonstrating it.
What is vulnerability management?
Vulnerability management is the continuous, cyclical process by which an organisation discovers vulnerabilities in its systems, prioritises, remediates and verifies the fix — and keeps repeating that. A vulnerability is a weak spot through which an attacker can get in somewhere or disrupt something: outdated software with a known flaw, a misconfigured service, an expired certificate, a system accidentally exposed to the internet.
Note the spelling in Dutch, because it gives away where a text comes from. The national cyber security centre (NCSC) writes "kwetsbaarhedenbeheer" (plural), the market and most vendors write "kwetsbaarheidsbeheer". They mean the same thing. In English it is vulnerability management, the term under which most tools come to market. Read the NCSC publications and read a vendor quote and you meet several names for one process; useful to know when you type the term in somewhere.
The word "management" is the crux. Management is not an action but a state you maintain. That distinguishes vulnerability management from the one-off scan it is so often confused with.
Vulnerability management, scan, pentest, patch management and monitoring: what is what?
Five terms that get conflated, while they are different things:
- A vulnerability scan is one step: automated searching for known vulnerabilities. It produces a list. The scan is the detection, not the management.
- A penetration test is a targeted, partly manual attack on a specific system to see how far someone gets. In-depth, point-in-time and expensive — suited to a critical application, not to continuous coverage.
- Patch management is the planned roll-out of software updates: one of the remediation routes within vulnerability management, not the process itself. Vulnerability management determines what needs remediating with what urgency — including issues no patch exists for, such as misconfigurations, expired certificates and forgotten systems.
- Vulnerability monitoring is the signalling layer: periodically re-measuring your external attack surface, so you notice what changes.
- Vulnerability management is the process that encompasses and directs those parts: discover, detect (the scan), prioritise, remediate, verify and repeat. Monitoring provides the continuous signalling within it; the scan provides the findings; management turns them into follow-up.
One more distinction that is often missing: this piece is about the external attack surface — everything visible from the internet. An attacker starts there, and an external measurement shows exactly that. It is a necessary layer, but not the whole discipline: internal, authenticated scans (with credentials, from the inside) find a different class of vulnerabilities — missing patches on internal workstations, misconfigurations behind the front door. Full vulnerability management includes both; this page, and the service behind it, focuses on the outside, because that is the side your customer, auditor and attacker see first.
The confusion is not harmless. Anyone who thinks a scan is "the vulnerability management" buys a snapshot and believes they have a process. In an audit against ISO 27001 control 8.8, a scan report six months old does not count as evidence of a continuous process — only as evidence that you once looked.
The process in five steps
Vulnerability management is a cycle, not a project with an end date. At its core there are five recurring steps. ISO 27001 control 8.8 ("management of technical vulnerabilities") describes the same movement at standard level.
1. Discover. Before you can manage anything, you have to know what you have. For the external attack surface that means: which domains, subdomains, servers and services of yours are exposed to the internet? This is called asset discovery, mapping your systems. It is precisely the systems no one has in mind any more — an old test environment, a subdomain an agency once created — where things go wrong. This is the shadow IT that emerges outside the IT department's view. Management that only looks at the systems you list yourself misses the forgotten ones by definition.
2. Detect. On everything you discover, you periodically search for known vulnerabilities and misconfigurations. This is the vulnerability scan: automated, repeatable, at a fixed cadence. Each vulnerability found usually has a CVE — a unique label that refers worldwide to the same vulnerability — and a CVSS score expressing the theoretical severity on a scale up to 10.
3. Prioritise. Here good management separates itself from a long list. In 2025 more than 48,000 vulnerabilities (CVEs) were registered (source: the annual CVE figures), and the research behind the EPSS model (FIRST/Cyentia) estimates that only around five per cent of them are ever actually exploited. The CVSS base score helps only so far: it measures severity in the lab, not the chance that a vulnerability is really exploited. For that chance there are two additional signals: EPSS, which estimates the global probability of exploitation within thirty days, and the KEV catalogue, a list of vulnerabilities where exploitation has actually been observed. KEV is an American list (from CISA); in the Netherlands the NCSC's security advisories complement the picture. Those two say something about the threat in general; whether the risk applies to you also depends on your own exposure — is the vulnerable service reachable from the outside? — and on how business-critical the affected system is. Good prioritisation weighs those three together: the exploit signals, your exposure and the importance of the system, so the team does the right things first instead of blindly chasing the highest CVSS scores. How that weighing works in practice is explained in EPSS and KEV explained.
4. Remediate. Every finding that deserves attention gets an owner and a deadline. Patching is the best-known remediation option, but not the only one: a temporary mitigation or workaround, shielding behind a firewall, a compensating control, decommissioning an outdated system, or — deliberately and substantiated — accepting the risk are equally legitimate, provided they are documented. It is wise to tie deadlines to severity: a critical, actively exploited vulnerability calls for days, a low one for the regular maintenance cycle. Without an owner and a deadline a finding lingers, and that is the stage where things often go wrong in practice.
5. Verify. Verification happens at two moments. Beforehand: is the finding real? External scans infer versions from what a service reveals, and that sometimes produces a false alarm — a check prevents you spending time on a gap that is not there. Afterwards: is the gap really closed? "It's patched" is a claim; a re-measurement that no longer finds the vulnerability is evidence. Then the cycle starts again, because in the meantime new vulnerabilities have been published and your environment has changed again.
That verification is where vulnerability management turns into demonstrability — and that is where this subject meets the law.
How often? The cadence of management
"How often should I scan?" is the question most searchers have, and the answer follows from the definition: if management is a maintained state, then once a year is too little. New vulnerabilities appear daily and your environment shifts constantly, so detection should recur at a fixed, short cadence. No standard prescribes a frequency; in practice, for the external attack surface, monthly is a workable minimum, weekly is better, and for an acute, widely exploited vulnerability you measure in between, on demand. Remediation follows its own clock, tied to severity (step 4). The gain of a fixed cadence is not only spotting things sooner, but also a series of dated measurements that together show that the process is running. If you want to steer on it, also track the time-to-remediate per severity category — that one number tells both your board and your auditor whether the cycle works.
The standard: ISO 27001, NEN 7510 and the duty of care
Vulnerability management does not stand alone; it is a control that recurs in several frameworks.
- ISO 27001:2022 names it explicitly in control 8.8, "management of technical vulnerabilities": organisations must obtain information about technical vulnerabilities, assess exposure, and take appropriate measures.
- NEN 7510, the Dutch standard for information security in healthcare, has followed the same structure and numbering as ISO 27001 since its 2024 revision. For healthcare providers, technical vulnerability management is thereby a concrete control an auditor tests against.
- NIS2 and the Dutch Cybersecurity Act name no standard and no product, but do require you to have vulnerability handling under control. NIS2 does not anchor it as a standalone measure but embeds it in article 21(2)(e): "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure". (The supply-chain duty of care is a separate measure, under (d).) The Dutch Cybersecurity Act is in force from 15 August 2026 without a transition period; the duty of care therefore applies in full from that date.
The common thread through all these frameworks is not "buy tool X", but "manage this process and demonstrate that you manage it". No standard prescribes a vendor. What they do is set the bar at demonstrability — and that is where many organisations struggle.
Paper versus measurement: the difference between saying and proving
On paper, vulnerability management is in order almost everywhere. The question that counts is whether you can demonstrate it — and there the picture falls apart. One organisation shows a policy document stating that management takes place. Another shows a series of dated measurements stating what was found and that it was resolved.
That is the distinction between paper and measurement, and it runs through this whole subject. A completed policy document, a supplier questionnaire with "yes, we do vulnerability management", a certificate on the wall — they are claims. An auditor, an insurer or a supply-chain partner who looks seriously wants no claim but evidence: dated, traceable measurements showing that the cycle is running. That is exactly what the verification step of the process produces.
That is the vantage point from which we look at vulnerability management. Exposentry is built on OpenKAT, the open-source scanning platform to which Edward Hasekamp of Hasecon contributes as a developer. That is not a seal but a way of working: OpenKAT measures continuously and records every finding as a datable, traceable object — not a PDF snapshot, but a measurement you can retrieve later and whose origin you can demonstrate. That turns "we manage our vulnerabilities" into a verifiable statement rather than an intention: not trusting what ought to be correct, but measuring what is actually exposed to the internet.
Common mistakes
The shortest route to good management is avoiding the common mistakes:
- Scanning without a remediation loop. Producing a list and not following up. The scan is step two of five, not an end point.
- Prioritising on the CVSS score alone. Without EPSS and KEV you spend urgency on vulnerabilities no one exploits, and miss the dangerous ones.
- Shadow IT out of view. Scanning only the systems you list yourself. The forgotten server is exactly where the findings turn up.
- No owner and no deadline. Findings picked up "later" are never picked up.
- Not verifying the fix. Assuming a patch works without re-measuring.
- Accepting risk without recording it. Accepting is allowed, but only as a decision with a name and a date — otherwise it is simply ignoring.
Do it yourself or outsource?
Vulnerability management requires tooling, time and interpretation skills. If you do not have those in house — and many organisations have no security team of their own — then outsourcing is a real option, but not for the whole process.
Well suited to outsourcing: the discovery and detection of the external attack surface, prioritisation by actual risk, and reporting in language that can be read outside the IT department too. This is repetitive, tool-intensive work in which a specialised service has economies of scale.
Not to be outsourced: the decision about what you do with a finding, and the ultimate responsibility for the risk. Under NIS2 and the Dutch Cybersecurity Act that responsibility lies explicitly with the board and is not transferable. An external party delivers the measurement and the evidence; the choice to patch, shield or accept stays with you.
What does it cost? A fair question without one answer: the price depends on how much of yours is exposed to the internet, how deep and how often you measure, and whether you handle it internally (staff hours, tooling) or buy it in. As a market-wide indication: continuous external monitoring costs hundreds of euros per month, a one-off baseline scan a few hundred euros. Weigh those costs against the impact of a single incident or a fine under the Dutch Cybersecurity Act. You can see what a continuous service costs under plans and pricing.
Conclusion
Vulnerability management is not a scan and not a product, but a cycle: discover, detect, prioritise, remediate, verify, and again. The standards — ISO 27001 control 8.8, NEN 7510, and the duty of care under NIS2 and the Dutch Cybersecurity Act — do not ask for a particular brand, but for a process that runs and that you can demonstrate. That last part, demonstrability, is where many organisations can make gains: not saying it is in order, but showing it with dated measurements.
Exposentry delivers the measurement and signalling side of that cycle as a service: continuous scans of your external attack surface based on OpenKAT, with periodic, forensically substantiated reports you can use to substantiate your position towards an auditor, insurer or supply-chain partner. Start small with a baseline scan that inventories what of yours is exposed to the internet, and let it settle into a fixed cadence. See the plans and pricing or start with a baseline scan to see where you stand.
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 EU-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.