NIS2 vulnerability management requirements

NIS2 vulnerability management requirements sit inside a wider cybersecurity risk-management framework. The evidence needs to show how an organization monitors vulnerabilities, evaluates exposure, chooses a treatment, assigns ownership, and checks whether the treatment worked.

The exact duties depend on the entity, sector, Member State, and applicable national law. Start by confirming scope with qualified counsel or your competent authority.

Separate the Directive from the detailed regulation

Directive (EU) 2022/2555, known as NIS2, requires essential and important entities in scope to take appropriate and proportionate cybersecurity risk-management measures. Article 21(2)(e) includes security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure. Article 21 also covers risk analysis, incident handling, supply chain security, and assessing whether risk-management measures work.

Member States implement the Directive through national law. That local implementation matters when deciding which entity is covered, which authority supervises it, and how the requirements are enforced.

Commission Implementing Regulation (EU) 2024/2690 gives more detailed technical and methodological requirements for the entity types listed in the regulation. These include certain DNS, cloud, data centre, content delivery, managed service, online marketplace, online search, social networking, and trust service providers.

Section 6.10 of that regulation contains the detailed vulnerability handling and disclosure measures discussed below. Don't apply that section to every EU business or assume every NIS2 entity has the same detailed duties without checking scope.

Build evidence around the work

Monitor vulnerability information

For entities in the implementing regulation's scope, section 6.10 calls for monitoring appropriate vulnerability information channels. Examples in the regulation include announcements from CSIRTs, competent authorities, suppliers, and service providers.

Evidence can include an approved source list, subscription or integration records, review ownership, intake timestamps, and a sample showing how a relevant notice became a tracked finding. Record how often the source list itself is reviewed and updated.

Evaluate exposure and choose treatment

Finding a CVE doesn't establish exposure. Connect the vulnerability to the affected network or information system, deployed version, reachable path, and business impact.

A reviewable record usually contains:

• The affected service, asset, or component
• The source and detection date
• Technical severity and operational criticality
• Exposure, exploitability, and existing controls
• The treatment decision, rationale, owner, and due date

The implementing regulation says relevant entities should take appropriate measures to manage vulnerabilities. The evidence should explain why the chosen action fits the exposure and potential impact.

Plan scans and keep the results where appropriate

Section 6.10.2(b) says relevant entities should perform vulnerability scans where appropriate, record evidence of the results, and run them at planned intervals.

Keep the scan scope, schedule, configuration, completion result, and follow-up records. If scanning isn't appropriate for a system, document the reason and the alternative monitoring or assurance method. Avoid treating an empty dashboard as proof that the planned scan ran successfully.

Handle critical vulnerabilities without undue delay

The detailed regulation ties “without undue delay” to vulnerabilities the entity identifies as critical to its operations. The record should preserve that operational judgment alongside technical severity.

Keep the time the team confirmed criticality, escalation path, accountable owner, interim mitigation, target date, implementation evidence, and verification result. If the response took longer than policy expected, record the reason and the risk decision instead of rewriting the original date.

Connect vulnerability handling to adjacent processes

Section 6.10 links vulnerability handling with change management, security patch management, risk management, and incident management. Evidence should show those handoffs in the systems the team already uses.

A finding might link to a change approval and deployment. An exploited vulnerability might also link to an incident. A delayed fix might link to a risk decision and mitigation plan. Keep one stable finding identifier across those records so a reviewer can follow the path.

Maintain a coordinated disclosure procedure

The detailed regulation requires a vulnerability disclosure procedure aligned with the applicable national coordinated vulnerability disclosure policy.

Document how a researcher or supplier can report a vulnerability, who receives it, how receipt is acknowledged, how the team protects sensitive information, and how remediation and publication timing are coordinated. Check the national policy that applies to the entity instead of copying a generic process.

Create a mitigation plan when impact justifies it

Section 6.10.3 calls for a mitigation plan when the potential impact justifies one. The plan should connect the vulnerability to interim controls, actions, owners, timing, dependencies, and the condition for closure.

When remediation isn't required, the same section calls for documented and substantiated reasons. Keep the exposure analysis, decision authority, compensating controls, and review date. A bare “accepted” status doesn't show the reasoning.

Review ownership, timing, and effectiveness

Article 21(2)(f) includes policies and procedures for assessing whether cybersecurity risk-management measures work. The implementing regulation adds detailed effectiveness assessment requirements for its scope.

Useful evidence includes overdue findings, time to handle vulnerabilities critical to operations, failed verification attempts, recurring vulnerable components, expired exceptions, source coverage, and whether planned scans completed. Record the review date, participants, conclusions, and resulting actions.

A practical record structure

One vulnerability register can connect the required context without replacing the source systems. For each finding, keep:

1. A stable identifier and original source.
2. The affected system, component, version, and exposure.
3. Severity, operational criticality, and impact.
4. The decision, rationale, owner, due date, and approval.
5. Remediation, mitigation, disclosure, change, risk, or incident links.
6. Verification result, closure date, and reviewer.

Keep history when ownership, dates, or decisions change. That history helps show how the organization managed risk over time.

The ISO 27001 A.8.8 evidence checklist covers a similar record from an information security management system and audit perspective.

Check current law before relying on the guide

The Commission proposal tracked as procedure 2026/0012/COD remains in the ordinary legislative procedure as of 15 July 2026. It is a proposal, not an adopted amendment to the Directive.

Recheck the procedure, current EUR-Lex texts, applicable national law, and regulator guidance before using this guide. A checklist can't prove legal compliance across every Member State or entity type.

Start with a working register

The free vulnerability management template keeps findings, exposure, decisions, owners, due dates, mitigation evidence, and verification in one Excel workbook. Adapt it to the rules and processes that apply to your organization.

Practical guidance only. This isn't legal advice.