Back to knowledge base

Vulnerability management and NIS2: is it mandatory?

Published on September 8, 2026

This article is general information about laws and regulations, not legal advice.

In short: vulnerability management does not appear as a term in NIS2 or the Dutch Cybersecurity Act. No discipline, tool or frequency is named. The law does require risk management you can demonstrate, and several parts of Article 21 bear directly on knowing, following up on and assessing vulnerabilities. Anyone who gives that substance sets up a process for managing vulnerabilities in practice.

Picture this: a supplier receives its first NIS2 questionnaire from a large customer. One question reads: how do you manage the vulnerabilities in your systems? Anyone who then searches whether vulnerability management is mandatory under NIS2 runs into contradictory answers. Some vendors call it mandatory; some lawyers point out that the law prescribes no tool at all. Both touch on something true. This article explains where the distinction lies, and why it matters little for your organisation what you call the process.

What the law literally requires

The substantive requirements come from Article 21 of the NIS2 directive. The Netherlands transposed that directive into the Cybersecurity Act (Cyberbeveiligingswet), which has been in force since 15 August 2026 without a general transition period. Paragraph 1 requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage the risks to their network and information systems. Paragraph 2 lists what those measures must at least cover: ten categories, from risk analysis and incident handling to supply-chain security and access control. The term vulnerability management does not appear in that list. The law is worded in a technology-neutral way and names no discipline, product or method.

A few categories bear on vulnerabilities most directly. Point (a) covers risk analysis and information-system security. Point (e), on the security of acquisition, development and maintenance of systems, names vulnerability handling and disclosure; that is essentially about how you deal with vulnerabilities in what you build and buy yourself, in practice often implemented with a point of contact for anyone who finds one. Point (f) covers policies and procedures to assess the effectiveness of the measures. Together they assume you know which systems you have and which vulnerabilities are present on them, because without that picture there is little to analyse, follow up on or assess. None of these categories prescribes a scan.

Why the process is hard to avoid in practice

The law prescribes an outcome, appropriate and demonstrable measures, and leaves the implementation to you. That technology neutrality is understandable, because a standard that fixes a specific scanner or frequency ages quickly. It has a flip side too: you have to substantiate yourself that your implementation covers the risks.

For vulnerabilities, that implementation runs into one point in practice: you can hardly manage what you do not have in view. An organisation that does not know which systems are exposed to the internet and which known vulnerabilities are visible on them can hardly substantiate that its measures are appropriate. The process of getting that picture and keeping it current, discovering what you have, detecting what is vulnerable, prioritising, remediating and recording the outcome, is what vulnerability management is. The law asks for the result, and that result rarely comes about without such a process.

Where the scan stops and the management begins

Two questions often get mixed up here. Whether a vulnerability scan is mandatory is a question about an instrument; the answer is that no tool is legally required. Whether vulnerability management is required is a question about an ongoing process. A scan produces a list at a moment in time. The rest of the process decides whether that list gets shorter: interpreting the findings, tackling the most serious first, checking that remediation holds, and measuring again as soon as the environment or the threat picture changes.

That ongoing character is what Article 21(2)(f) steers towards. A snapshot says little about effectiveness; a series of measurements shows whether vulnerabilities actually stay open for shorter periods. The time from finding to remediating, in practice a widely used metric, becomes a figure you can show. Most of the work is in the follow-up: clearing false positives, vulnerabilities that return after a patch, and systems you only discover through external detection. The Dutch NCSC speaks of kwetsbaarhedenbeheer, which the market often calls kwetsbaarheidsbeheer. Which steps that process involves and how to set it up demonstrably are covered in the pillar article on vulnerability management. Anyone who makes the detection step continuous is doing vulnerability monitoring: the same detection, ongoing.

Demonstrability sets the bar

The duty of care does not stop at "having it arranged". In enforcement practice a supervisor, for many sectors the RDI, as well as a supply-chain partner assessing you, will want to see that the measures demonstrably work. With vulnerability management, demonstrating means showing that the process is running: that it measures periodically, that vulnerabilities found are followed up, and that the lead time is known.

A policy document describes the intention, an external measurement shows the reality. For the supply-chain duty of care that difference weighs heavily: your customer has to explain to their own supervisor why they trust you, and a series of dated, independent reports is stronger evidence for that than a self-completed questionnaire. A report that is verifiably sealed with a timestamp, so the recipient can check that it has not been altered since, can withstand that test better than paper that rests on trust. If you receive such a supplier questionnaire yourself, the measurement is the piece of evidence you place alongside your answers.

What "appropriate and proportionate" means for you

The law does not set the bar equally high for everyone. A small supplier with a handful of internet-facing services has to arrange something different from an IT service provider serving dozens of clients in vital sectors. The scope of the process follows from your risk analysis; the law prescribes no fixed minimum number of scans. If you are unsure whether you fall under the law at all, for instance because you are affected through the supply chain, the self-check on whether you fall under NIS2 helps.

A continuous measurement of your external attack surface is often a low-threshold first step to keep sight of what an attacker sees from the outside. A full picture needs more: authenticated checks of internal systems and attention to the patch cycle, precisely where the risks are greatest. Outsourcing is an option. Vulnerability management calls for expertise and time that many SMEs do not have in house, so placing the execution with an external party is a legitimate choice. The ultimate responsibility stays with the organisation itself. So make sure that what you outsource also yields dated, verifiable reports you can produce yourself to an auditor or supply-chain partner.

Conclusion

Is vulnerability management mandatory under NIS2? The term does not appear in the law. The process, in practice, is hard to avoid for organisations that fall under the Cybersecurity Act. The law requires you to know your vulnerabilities, follow them up and assess the effectiveness of your approach, without prescribing a tool or a frequency. That is exactly what the process delivers. The real question, then, is whether you set it up so that you can also demonstrate it. What you measure continuously, you can substantiate and improve in a targeted way.

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.