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, and §30(2)(5) BSIG transposes it 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.
CIR §6.10 lays out five actions. Pull in vulnerability information from CSIRTs, authorities, vendors and service providers. Run vulnerability scans on a documented cadence. Remediate the critical ones without 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 puts the same rule into national law through §30(2)(5) BSIG. The national CVD framework runs through the CERT-Bund coordinated disclosure programme at the BSI. 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 sections (§6.9 acquisition, §6.10 vulnerabilities). The disclosure half is what gets undervalued.
CIR (EU) 2024/2690, Annex §6.10
The relevant entities shall obtain information about technical vulnerabilities in their network and information systems, assess their exposure to such vulnerabilities and take appropriate measures to manage them.
Directly binding EU law for the sectors named in the CIR Annex (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 periodically.
§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
§6.10.2(b) says scans run 'periodically as appropriate'. §6.10.4 says you review the channels you use to monitor vulnerability information periodically. Both phrases mean: written cadence. Document how often you scan, document how often you review your feed list, and stick to it. A scan once a year because someone remembered is not periodic.
Coordinated disclosure is a duty, not optional
§6.10.2(e) says the procedure has to exist. Not 'if you get reports'. The procedure exists so that when a researcher does find something, they have a channel and you have a process. Minimum viable: a security@yourdomain.com mailbox someone reads, an acknowledgement window (commonly 7 days), and a disclosure window (commonly 90 days). Document it, publish it, point a security.txt file 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. §30(2)(5) BSIG points at this. If you are setting up a CVD process for the first time, aligning your timelines and contact channels with the CERT-Bund model is the safe default.
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
Every member state has its national CSIRT acting as the CVD coordinator (NCSC-NL in the Netherlands, CERT.at in Austria, CCB in Belgium). The duty is the same EU-wide. What differs: which CSIRT you talk to and the exact mechanics of their coordination process.
We patch on Patch Tuesday, that is enough.
It is not. §6.10.2(c) says critical vulnerabilities get remediated without delay. Patch Tuesday is a vendor release cadence. A zero-day disclosed on a Thursday with active exploitation does not wait until next Tuesday. You need a patching cadence for routine fixes and an out-of-band process for critical issues.
We do not have a CVD process because nobody ever reports vulnerabilities to us.
§6.10.2(e) does not say 'set up a process when reports start coming in'. It says the procedure has to exist. The point is to make sure that when a researcher does find something, they have a clear channel and your team knows what to do. A security@ inbox and a one-page policy is enough to satisfy the duty. Not having one is a finding.
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. And §6.10.4: review channels at an organisational level. That makes vulnerability management a cross-team process touching IT operations, development, risk and the management body, not a siloed security activity.
The engineering side is usually in reasonable shape. Most Mittelstand IT teams already run a scanner (Tenable, Qualys, Nessus, OpenVAS) and have some kind of patch cadence, even if it is just 'Patch Tuesday for clients, quarterly for servers'. The CIR §6.10.2(a)+(b)+(c) duties are mostly about writing down what already happens and tightening the critical-fix timeline.
The CVD side is the underdocumented half. Realistic minimum: a security@yourdomain.com inbox routed to two people, a one-page disclosure policy (acknowledge within 7 days, disclose within 90 days, credit researchers who want it), and a security.txt file at /.well-known/security.txt pointing at the inbox. Half a day of work. The piece that audits actually flag.
The PRO module captures your vulnerability inventory, scan schedule, remediation tasks and acceptance decisions in one place. Each scan finding gets routed into a task with an owner, a due date and a sign-off. §6.10.3's 'document why no action is needed' is the same sign-off path: written justification, named approver, audit trail. No separate spreadsheet.
We also ship a CVD policy template (security@ inbox setup, security.txt content, acknowledgement and disclosure SLAs aligned with CERT-Bund). You drop in your domain and your contacts and you have the §6.10.2(e) duty covered. Inbound reports route into the same task pipeline as scan findings, so the response timeline is tracked the same way.
- 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)