NIS2 and vulnerability management: from discovery to proof, and why the board is on the hook

“We have a scanner” is not the same as “we manage vulnerabilities”. NIS2 makes that difference explicit. Directive (EU) 2022/2555, transposed in Romania through GEO 155/2024 and Law 124/2025 (details in our article NIS2 in Romania), does not ask you for a tool, it asks for a closed, proven loop: find, prioritize, fix, re-test, prove. And through Article 20, it puts management on the hook for it.

This material is informational, not legal advice: for your situation, check with DNSC and a consultant.

What NIS2 actually requires on vulnerabilities

Two provisions matter directly:

• Article 21(2)(e) requires security in the acquisition, development and maintenance of systems, including vulnerability handling and disclosure. Not “scan”, but “handle”, that is, take the finding all the way through.
• Article 21(2)(f) requires procedures that assess whether the measures work. A vulnerability fixed on paper but not re-tested does not pass that test.

Notice what is missing again: the name of any product. The law describes a process with a verifiable result, not a shelf in a store.

The loop, not the scan

A scanner gives you a list. Vulnerability management is what you do with it. The loop NIS2 implicitly requires:

1. Find everything you expose, including what no one remembers. The real surface includes forgotten subdomains, test services left online, containers and dependencies, not just what is in the official inventory.
2. Prioritize by real risk, not by the length of the list. The next section goes into it.
3. Fix, with a clear owner and deadline for each finding. A vulnerability with no owner does not get resolved, it migrates from one report to the next.
4. Re-test, to confirm the remediation actually closed the issue, not just that someone ticked “resolved”.
5. Prove, by keeping the audit trail. Without this step, everything you did before is invisible to an auditor.

Steps 4 and 5 are exactly the ones organizations skip, and exactly the ones NIS2 requires at (f). We developed the idea separately, because it holds beyond NIS2, in the control that passes the test.

Prioritization: not all vulnerabilities are equal

The most common mistake is working the list in CVSS-score order. The score is useful but incomplete. A prioritization that survives an inspection accounts for:

• exposure, an internet-facing service matters more than one isolated in the internal network;
• active exploitation, vulnerabilities already exploited in the wild are handled first, regardless of score;
• business impact, which process stops if the system goes down.

A “medium” score on a public, actively exploited service is more urgent than a “critical” on a system with no access path. Prioritization is where security meets operational reality, not an automatic ranking.

The proof and the audit trail

At a DNSC inspection, the question is not “do you have a scanner?”, it is “show me the loop”. Concretely, for a finding you must be able to show: when it was found, who owned it, what deadline it had, when and how it was fixed, and the evidence of the re-test that confirms closure. Plus the exceptions, recorded with reason and deadline, not silent derogations.

A vulnerability-management policy without these traces is a claim. The audit trail turns it into a control. That difference decides an audit.

Article 20: why the board is on the hook

Here is the part many miss. NIS2 does not leave security solely in the IT team’s yard. Article 20 requires the management bodies of essential and important entities to approve the risk-management measures, oversee their implementation and follow specialized training. Management can be held liable for failing these obligations.

The practical effect is that vulnerability management rises from an IT ticket to a board responsibility. A delayed patch is no longer just a technical problem; it becomes a decision someone in management approved or ignored, with traces. The penalties in Law 124/2025 (up to 7 million euros or 1.4% of turnover for important entities, up to 10 million euros or 2% for essential ones) now have a clear addressee.

What to do concretely, proportionate to risk

Without buying anything specific, the order that survives an inspection:

1. Continuous discovery, not an annual scan, and including the exposure you did not have in your inventory.
2. Risk-based prioritization (exposure, active exploitation, impact), not the raw score.
3. Owner and deadline for each finding.
4. Re-test that confirms the remediation.
5. Audit trail collected as you work, not the day before an inspection.
6. Reporting to management, so Article 20 is met, not just invoked.

What we take away

NIS2 treats vulnerability management as a process with a proven result, not as a tool. Finding is only the beginning; the value is in what follows, fixing, re-testing, proving, and in the fact that someone in management answers for that loop. Whoever stops at “we have a scanner” has a list. Whoever closes and proves the loop has a control, and, incidentally, compliance too.

Want to know how your vulnerability-management loop compares to what NIS2 requires, and where it breaks? Contact us and we start from an assessment.

Sources

• EUR-Lex: Directive (EU) 2022/2555 (NIS2), Articles 20 and 21
• DNSC, Romanian National Cyber Security Directorate
• ENISA: European Union Vulnerability Database (EUVD)