NIS 2 vulnerability management under Article 21(2)(e)
Vulnerability management has two sides under NIS 2. How you handle weaknesses in your own systems. And how you handle weaknesses people report to you. Article 21(2)(e) is where the duty lives, CIR (EU) 2024/2690 §6.10 spells out the specifics for the digital providers it covers, and §30(2)(5) BSIG transposes the duty into German law.
The short version
Vulnerability management is point (e) on the Article 21(2) list. The CIR titles its corresponding section 'Handling and disclosure of vulnerabilities'. That title is the giveaway. NIS 2 cares about two things at once: weaknesses sitting in the systems you run, and weaknesses outsiders find in your products and want to tell you about.
For the digital providers it covers, CIR §6.10 lays out five actions. Pull in vulnerability information from CSIRTs, authorities, vendors and service providers. Where appropriate, run vulnerability scans and record the results at planned intervals. Remediate the critical ones without undue delay. Tie vulnerability handling into your change, patch, risk and incident processes. And set up a coordinated vulnerability disclosure (CVD) procedure that lines up with the national CVD policy.
Germany names vulnerability management and disclosure for every entity in §30(2)(5) BSIG, without prescribing the form. The BSI is the national coordinator for coordinated vulnerability disclosure (§5(1) BSIG) and runs it through CERT-Bund. NIS 2 itself also sets up a European vulnerability database under Article 12, operated by ENISA, where entities may voluntarily disclose.
Article 21(2)(e) NIS 2 Directive (2022/2555)
Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.
Point (e) on the list of ten measures. Note the framing: vulnerability handling and disclosure sit inside a wider duty around acquisition, development and maintenance. The CIR splits this into separate points (6.1 acquisition, 6.10 vulnerabilities).
CIR (EU) 2024/2690, Annex §6.10
The relevant entities shall obtain information about technical vulnerabilities in their network and information systems, evaluate their exposure to such vulnerabilities, and take appropriate measures to manage the vulnerabilities.
Directly binding EU law for the entity types listed in Art. 1 CIR (DNS, TLDs, cloud, data centres, MSPs, trust services and the others). §6.10.2 lists five concrete actions. §6.10.3 says when you skip mitigation, you write down why. §6.10.4 says you review the channels you use to monitor vulnerability information at planned intervals.
§30(2)(5) BSIG (Germany)
Security measures for the acquisition, development and maintenance of information technology systems, components and processes, including vulnerability management and disclosure.
Germany copies the EU text. The national CVD framework runs through the CERT-Bund coordinated disclosure programme at the BSI, which is what 'aligned with applicable national CVD policies' in CIR §6.10.2(e) points to in Germany.
Get the information in
Follow vulnerability information from CSIRTs, authorities, vendors and service providers. Run vulnerability scans on a cadence appropriate to your environment. The scan tools (Tenable, Qualys, Nessus, OpenVAS) are the engineering side. The feeds (CERT-Bund newsletter, vendor advisories, NVD) are the awareness side. You need both.
Fix the critical ones, document the rest
Critical vulnerabilities get remediated without delay. Vulnerability handling has to hook into your change management, patch management, risk management and incident management. Where you decide not to mitigate, §6.10.3 says you create a documented mitigation plan or write down why no action is needed. No silent backlog.
Run a coordinated disclosure process
Establish a procedure for receiving vulnerability reports from outsiders and coordinating their disclosure, aligned with the applicable national CVD policy. Minimum mechanics: a published contact channel (security@ inbox or a security.txt file), an acknowledgement SLA, a remediation timeline, and a coordinated public release. CERT-Bund will broker if needed.
Periodic, not reactive
Point 6.10.2(b) asks, where appropriate, for vulnerability scans with the results recorded at planned intervals, and point 6.10.4 for the monitoring channels to be reviewed at planned intervals. For the entities the CIR covers, that means a written cadence: document how often you scan and how often you review your feed list, and stick to it. No text sets the interval.
Disclosure is part of the duty
§ 30(2) No. 5 BSIG and Art. 21(2)(e) NIS 2 name the disclosure of vulnerabilities next to their handling, for every entity. For the digital providers the CIR covers, point 6.10.2(e) asks for a procedure in line with the national coordinated disclosure policy. A minimal setup: a security@ mailbox someone reads, a short policy, and a security.txt file pointing at it.
BSI / CERT-Bund CVD programme
The BSI runs CERT-Bund, the federal CSIRT, and operates a coordinated vulnerability disclosure programme. Researchers can report through CERT-Bund and the BSI will coordinate with affected vendors. § 5(1) BSIG makes the BSI the national coordinator for coordinated vulnerability disclosure under Art. 12(1) NIS 2. If you are setting up a disclosure process for the first time, the BSI's CVD guideline is a good model.
European vulnerability database (Article 12 NIS 2)
Article 12 of NIS 2 sets up a European vulnerability database operated by ENISA. Entities may voluntarily disclose vulnerabilities to it. It is not a mandatory reporting channel under Article 23. It is an EU-wide reference resource that aggregates vulnerability information across member states.
National CSIRTs as CVD coordinators
Each member state designates one of its CSIRTs as coordinator for coordinated vulnerability disclosure (Art. 12(1) NIS 2). National laws may go further than the directive (Art. 5), so check the national text; what also differs is which CSIRT you talk to and how its coordination works.
We patch on Patch Tuesday, that is enough.
Not for the digital providers the CIR covers: point 6.10.2(c) says critical vulnerabilities get addressed without undue delay. Patch Tuesday is a vendor release cadence. A zero-day disclosed on a Thursday with active exploitation does not wait until next Tuesday. A patching cadence for routine fixes plus an out-of-band process for critical issues covers both.
We do not have a CVD process because nobody ever reports vulnerabilities to us.
For the digital providers the CIR covers, point 6.10.2(e) asks for the procedure up front, not once reports arrive. For everyone else, disclosure is named in § 30(2) No. 5 BSIG without a prescribed form. A security@ inbox and a one-page policy are a small, sensible step either way.
Vulnerability scanning is the security team's job.
It is, until you read §6.10.2(d): vulnerability handling has to be consistent with change management, patch management, risk management and incident management. That makes vulnerability management a cross-team process touching IT operations, development and risk, not a siloed security activity.
The disclosure side is the underdocumented half. A realistic minimum: a security@yourdomain.com inbox routed to two people, a one-page disclosure policy, and a security.txt file at /.well-known/security.txt pointing at the inbox. For timelines, the BSI's CVD guideline expects a vendor to acknowledge a report within three working days and gives 45 to 90 days to fix, the internationally usual range.
- Directive (EU) 2022/2555 (NIS 2), Article 12 and Article 21(2)(e): eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §6.10: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §30(2)(5) as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
- BSI / CERT-Bund coordinated vulnerability disclosure programme: bsi.bund.de
- ENISA European vulnerability database (Article 12 NIS 2)
In practice
Where this comes up in the walkthrough
The walkthrough turns this into steps you fill in, with the law explained beside each one. Open a step to see its screen, filled in for a made-up company.
Procurement & Development
Write the rules for buying, updates and vulnerabilities
What you check when buying, how updates arrive and who closes gaps.
Been asked to handle NIS2?
In the end you have everything in one document: what is done, what is still open, and your management's approval with name and date. The app writes the texts.
