NIS 2 Vulnerability Management and Disclosure

Key Takeaways

Point	Summary
Organizational requirement	Article 21(2)(e) requires vulnerability handling and disclosure policies
EU vulnerability database	ENISA operates a European vulnerability database
Coordinated disclosure	Member states must establish coordinated vulnerability disclosure policies
CSIRTs role	National CSIRTs act as coordinators for vulnerability disclosure
Proactive approach	Organizations must actively identify and address vulnerabilities

Quick Answer: NIS 2 requires organizations to implement vulnerability handling and disclosure policies as part of their cybersecurity measures. At the EU level, the directive establishes a coordinated vulnerability disclosure framework through ENISA and national CSIRTs, creating a structured process for reporting and addressing vulnerabilities.

Organizational Vulnerability Management

What NIS 2 Requires

Article 21(2)(e) mandates security in the acquisition, development, and maintenance of network and information systems, including vulnerability handling and disclosure. This translates to:

Requirement	Description
Vulnerability identification	Processes to discover vulnerabilities in your systems
Vulnerability assessment	Evaluation of the risk each vulnerability presents
Remediation planning	Prioritized approach to addressing vulnerabilities
Patch management	Timely application of security patches and updates
Disclosure policies	Procedures for handling vulnerability reports from external researchers

Building a Vulnerability Management Program

Step 1: Establish an Asset Inventory

You cannot manage vulnerabilities in systems you do not know about:

• Maintain a comprehensive inventory of all hardware, software, and services
• Include version information and patch status
• Track end-of-life and end-of-support dates
• Map dependencies between systems

Step 2: Implement Scanning and Detection

Tool/Process	Purpose
Vulnerability scanners	Automated scanning of networks and systems for known vulnerabilities
Penetration testing	Simulated attacks to identify exploitable vulnerabilities
Code analysis	Static and dynamic analysis of application code
Configuration audits	Review of system configurations against security baselines
Threat intelligence	Monitoring for newly disclosed vulnerabilities affecting your technology stack

Step 3: Assess and Prioritize

Not all vulnerabilities present equal risk. Prioritize based on:

Factor	Consideration
Severity	CVSS score and potential impact
Exploitability	Is there a known exploit? Is it actively exploited in the wild?
Exposure	Is the vulnerable system internet-facing or isolated?
Criticality	How important is the affected system to your operations?
Data sensitivity	What data could be accessed through the vulnerability?

Step 4: Remediate

Action	Timeline
Critical vulnerabilities (actively exploited)	Immediate (24-48 hours)
High vulnerabilities	Within 7-14 days
Medium vulnerabilities	Within 30 days
Low vulnerabilities	Within 90 days or next maintenance window

When immediate patching is not possible, implement compensating controls (network isolation, additional monitoring, access restrictions) while working toward remediation.

Step 5: Verify and Document

• Verify that patches are applied successfully
• Re-scan to confirm vulnerabilities are remediated
• Document all vulnerability management activities
• Track metrics: time to remediate, vulnerability counts, scan coverage

Coordinated Vulnerability Disclosure (EU Level)

ENISA European Vulnerability Database

NIS 2 tasks ENISA with establishing and maintaining a European vulnerability database. This database:

• Contains information on known vulnerabilities in ICT products and services
• Accepts voluntary contributions from any entity (in scope or not)
• Includes severity information and remediation guidance
• Is publicly accessible to support vulnerability management
• Complements other vulnerability databases (CVE, NVD)

National Coordinated Disclosure

Each member state must establish:

• A coordinated vulnerability disclosure policy
• A designated CSIRT to act as coordinator for vulnerability disclosure
• Processes for security researchers to report vulnerabilities responsibly
• Timelines and procedures for coordinating remediation with vendors

How Coordinated Disclosure Works

Step	Actor	Action
1	Researcher	Discovers a vulnerability
2	Researcher	Reports to the national CSIRT or directly to the vendor
3	CSIRT	Validates the vulnerability and coordinates with the vendor
4	Vendor	Develops and tests a patch or mitigation
5	CSIRT + Vendor	Coordinate public disclosure timing
6	Vendor	Releases patch and advisory
7	CSIRT	Publishes coordinated advisory, updates ENISA database
8	Organizations	Apply the patch and verify remediation

Vulnerability Disclosure Policy for Organizations

NIS 2 entities should establish their own vulnerability disclosure policy that enables security researchers to report vulnerabilities responsibly:

Key Elements

Element	Description
Scope	Which systems and services are covered
Reporting channel	How to submit vulnerability reports (email, form, platform)
Safe harbor	Commitment not to pursue legal action against good-faith researchers
Response timeline	Expected timeframes for acknowledgment and remediation
Communication	How the organization will communicate with reporters
Recognition	Whether and how researchers will be credited

Integration with NIS 2 Incident Reporting

Vulnerability exploitation may trigger NIS 2 incident reporting obligations. When a vulnerability is actively exploited and causes a significant incident:

• The 24-hour early warning timeline applies
• The incident notification should reference the vulnerability
• The final report should include the vulnerability as part of the root cause analysis
• Information about the vulnerability should be shared with the CSIRT to help protect other entities

Supply Chain Vulnerability Management

Supply chain security under NIS 2 includes monitoring vulnerabilities in third-party products:

• Subscribe to vendor security advisories for all critical software
• Monitor vulnerability databases for issues in your technology stack
• Include vulnerability management requirements in supplier contracts
• Have processes to act quickly when supply chain vulnerabilities are disclosed
• Participate in coordinated vulnerability disclosure processes when appropriate

Common Questions

Do we need to run our own vulnerability disclosure program?

NIS 2 requires vulnerability handling and disclosure policies, but this does not necessarily mean you need a full bug bounty program. At minimum, you should have a clear process for receiving and handling vulnerability reports, whether through a simple security contact email or a more structured disclosure program. The key is that external parties have a way to report vulnerabilities responsibly.

How does this relate to penetration testing?

Penetration testing is one component of vulnerability management. NIS 2's requirement for assessing cybersecurity effectiveness (Article 21(2)(f)) supports regular penetration testing as a way to identify vulnerabilities that automated scanning might miss. The frequency should be proportionate to your risk profile, with annual penetration testing as a reasonable baseline for most organizations.

What about zero-day vulnerabilities?

Zero-day vulnerabilities (those without available patches) require a different approach: implement compensating controls, increase monitoring, and coordinate with vendors and CSIRTs. The coordinated vulnerability disclosure framework under NIS 2 is designed to handle exactly these situations, ensuring that information about zero-days is shared responsibly to minimize exploitation risk while remediation is developed.