NIS2 Vulnerability Management: What Articles 21 and 23 Require

The entire legal basis for vulnerability management under NIS2 is a fragment of one sub-point. Article 21(2)(e) asks for security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.

That is it. Eight words, doing an enormous amount of work.

Everything a supervisor will eventually ask you about, the inventory, the deadlines, the evidence, the disclosure route, hangs off that clause. This guide turns it into five controls an auditor can test, then makes a second argument that most NIS2 coverage misses: the reporting clock in Article 23 is an incident clock, and the cheapest way to never start it is to close the known-CVE path that most incidents actually take.

This is operational guidance, not legal advice. Scope determination for your organisation belongs with counsel.

Who NIS2 Applies To, and the Size-Cap Trap

NIS2 is Directive (EU) 2022/2555. It entered into force in January 2023 with a Member State transposition deadline of 17 October 2024.

Because it is a directive rather than a regulation, the text that binds you is your national transposition, not the directive itself. Transposition has been uneven across Member States in both timing and detail. Always check the national law, and expect the article numbering in your local act to differ.

Scope works in three layers:

• Annex I lists essential sectors: energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management, public administration, space.
• Annex II lists important sectors: postal and courier services, waste management, chemicals, food, manufacturing of certain products, digital providers, research.
• A size cap brings in medium and large entities within those sectors, with specific entities designated regardless of size.

Here is the trap. Most organisations that ask "are we in scope?" get a comfortable no and stop reading. Then a customer who *is* in scope sends a supplier questionnaire, because of the clause in the next section but one, and the requirements arrive contractually instead of legally. The practical population affected by NIS2 is far larger than the population named by it.

Article 21(2): The Ten Minimum Measures in Plain English

Article 21(2) sets ten minimum risk-management measures. In brief:

1. Risk analysis and information system security policies.
2. Incident handling.
3. Business continuity, including backup management and crisis management.
4. Supply chain security, including security-related aspects with direct suppliers.
5. Security in acquisition, development and maintenance, including vulnerability handling and disclosure.
6. Policies to assess the effectiveness of risk-management measures.
7. Basic cyber hygiene practices and security training.
8. Policies on cryptography and encryption.
9. Human resources security, access control and asset management.
10. Multi-factor authentication, secured communications and secured emergency communications.

Items 4 and 5 are the ones this article is about.

Article 21(2)(e): Eight Words About Vulnerability Handling

The clause does not prescribe a scanner, a scan frequency, a severity threshold or a tool. This is a feature of the drafting, not an oversight: NIS2 is risk-based, so the supervisor tests the process you documented against the evidence you produced.

That cuts both ways. There is no box to buy your way out of, and equally there is no defence in having bought one. What you need is a written policy and dated evidence that you followed it.

Article 21(2)(d): Supply Chain Security Means Your Suppliers' CVEs Too

Article 21(2)(d) requires managing security in the relationships with direct suppliers and service providers.

The consequence is frequently underestimated: a vulnerability in software you bought is your risk-management problem, not only your vendor's. If a component in a product you deploy hits the KEV catalog, "we are waiting on the vendor" is a status, not a control. What a supervisor wants to see is that you knew, that you assessed, and that you compensated while you waited.

Turning 21(2)(e) Into Five Auditable Controls

This is the practical core. Five controls, each with a testable artefact.

Control 1: A maintained inventory of technologies and versions in use.

Evidence: the inventory itself, with a review date and an owner. Without this, no other control can be evidenced, because you cannot show that you assessed a CVE against something you never recorded owning.

Control 2: A documented severity-to-deadline remediation policy.

Evidence: a written policy stating that a vulnerability of a given class must be remediated within a given number of days. You do not have to invent one. The four-tier framework in our patch management strategy is a ready-made answer: emergency, urgent, routine and deferred, each with a fixed deadline and a defined trigger.

Control 3: Per-item evidence that the policy was met, with dates.

Evidence: a ticket per vulnerability, showing the date you learned of it, the assessment, the action and the date closed. Aggregate metrics do not satisfy this. Supervisors sample individual items.

Control 4: A published route for outsiders to report vulnerabilities to you.

Evidence: a security.txt file, a disclosure policy page, a monitored mailbox. This is the "and disclosure" half of the clause that most programmes forget entirely.

Control 5: Monitoring of supplier and component vulnerabilities, not just your own code.

Evidence: a feed or service that matches published CVEs against Control 1's inventory, with dated output. The free floor here is the CISA KEV catalog, which tells you which vulnerabilities are confirmed to be under exploitation. A software bill of materials is what makes the matching accurate below the top level.

Controls 1 and 5 together are the ones teams most often fail, because they are continuous rather than annual. That matching, published CVE against declared stack, is exactly what stack-matched CVE alerts automate, and the plan comparison sets out what is included at each tier.

Article 23: The 24-Hour, 72-Hour and One-Month Clock

For a significant incident, Article 23 requires:

An incident is significant if it has caused or is capable of causing severe operational disruption or financial loss, or has affected others by causing considerable material or non-material damage.

Note what this clock is not. It is not a vulnerability clock. NIS2 never asks you to report a CVE. That distinction is the difference between NIS2 and the Cyber Resilience Act, whose Article 14 does put a 24-hour reporting duty on manufacturers for actively exploited vulnerabilities in products they ship. If you both operate services and sell a product, you can be inside both regimes, with two different clocks and two different triggers.

Why Vulnerability Management Is the Cheapest Way to Avoid Article 23

Here is the argument that turns a compliance exercise into an engineering priority.

Incident reporting is expensive. It consumes senior time, it involves counsel, it is visible to a regulator, and it ends with a written record of what went wrong. Every hour spent on Article 23 is an hour not spent building anything.

A large share of significant incidents begin with the exploitation of a known vulnerability, in a product the organisation knew it ran, for which a patch existed. That is the path that Controls 1 through 5 close. Not all of it, obviously, but the part that is embarrassing precisely because it was foreseeable.

So the honest business case is not "Article 21 requires it". It is: a working vulnerability programme is the cheapest available way to reduce the number of times you have to start the Article 23 clock at all.

Article 20: Why Your Management Body Is Personally Exposed

Article 20 requires management bodies to approve and oversee the risk-management measures, provides for their liability for failures, and obliges them to undergo training.

This is the sentence that unlocks budget, so quote it accurately rather than dramatising it. Approval is not a rubber stamp; it is a recorded decision by named people who are then accountable for it. In practice the useful move is to put Controls 1 to 5 in front of the board as a decision item with an owner and a date, and to keep the minutes.

Article 12, Coordinated Disclosure and the European Vulnerability Database

Article 12 covers coordinated vulnerability disclosure and establishes a European vulnerability database, which ENISA operates as the EUVD.

Two practical implications. First, Control 4 is not an optional nicety; the directive expects a functioning disclosure path to exist across the ecosystem. Second, the EUVD gives European organisations a publication surface that does not depend on a single non-EU upstream, which matters more than it did before recent wobbles in the CVE programme's funding.

Penalties, and What Supervisors Ask For First

The penalty tiers differ by classification. Essential entities face a maximum administrative fine of at least 10,000,000 EUR or 2% of total worldwide annual turnover, whichever is higher. Important entities face at least 7,000,000 EUR or 1.4%. Check the article numbering in your own transposition before citing these internally.

More useful than the ceiling is the opening question. Supervisors do not begin with your architecture. They begin with: show me your inventory, show me your policy, show me three closed items with dates. Controls 1, 2 and 3.

A 90-Day Readiness Plan

Days 1 to 30. Establish the inventory. Technologies, versions, owners, one row per thing. Imperfect and current beats perfect and stale. Identify your national transposition and confirm your classification with counsel.

Days 31 to 60. Write the remediation policy. Four tiers, four deadlines, one page. Get it approved by the management body under Article 20 and minute the approval. Publish a security.txt and a disclosure policy.

Days 61 to 90. Turn on continuous matching between published vulnerabilities and the inventory. Route the output into your existing ticketing system so Control 3 evidence is produced as a by-product of the work rather than assembled the week before an audit.

Do those three things and the eight words in Article 21(2)(e) stop being a compliance risk and start being a programme.