NIS2 Article 21(2)(e) lists security in acquisition, development and maintenance, "including vulnerability handling and disclosure", as a required measure, and Article 12 sets up national coordinated vulnerability disclosure through CSIRTs. In practice you need a way to learn about flaws, assess exposure, fix on time, and let outsiders report to you.
What the directive says
Article 21(2)(e) is short. The detail for certain digital entity types comes from Commission Implementing Regulation (EU) 2024/2690, point 6.10 of its Annex. It is a useful model even for entities outside that regulation.
Under that annex, in-scope entities must:
- monitor vulnerability information through channels such as CSIRT announcements, authority notices and supplier information;
- run vulnerability scans where appropriate, at planned intervals, and record the results as evidence;
- address, without undue delay, vulnerabilities identified as critical to their operations;
- keep vulnerability handling compatible with change, patch, risk and incident management;
- set a procedure for disclosing vulnerabilities in line with the applicable national coordinated vulnerability disclosure policy.
Where justified by potential impact they must create a mitigation plan. Otherwise they must document why the vulnerability does not need remediation.
The coordinated disclosure side
Article 12 says each member state designates one CSIRT as a coordinator. It acts as a trusted intermediary between the person who reports a flaw and the maker of the product or service, and can help negotiate disclosure timelines. People must be able to report anonymously if they ask. ENISA maintains a European vulnerability database, where entities can voluntarily register publicly known vulnerabilities.
A working checklist
- Inventory first. You cannot assess exposure without knowing which components you run. Keep a current dependency inventory per service.
- Intake. Subscribe to advisories for your stack and to your national CSIRT notices.
- Triage rules. Define severity levels and target fix times, then record exceptions with an owner and an expiry date.
- Evidence. Save scan outputs, ticket links and fix dates. These answer "evidence of implementation" requests.
- Inbound reports. Publish a security contact, for example a security.txt file, and a short disclosure policy. Name how you will acknowledge reports.
- Outbound disclosure. Decide who approves advisories and how you notify customers.
- Review. Revisit the channels and thresholds yearly.
Reachability helps prioritisation
The directive asks for "appropriate" measures, so a documented risk based approach is acceptable. Knowing whether a vulnerable function is reachable in your code can justify ordering, as long as the reasoning is written down.
Safeguard offers SBOM and dependency scanning, reachability analysis and zero-day discovery, and you can try a free scan. These supply data for the steps above, while policy and disclosure decisions stay with your team.
Quick check
Do I have to publish every vulnerability I find?
No. The text asks for a disclosure procedure aligned with national coordinated disclosure policy, not blanket publication.
Is a bug bounty required by NIS2?
No. NIS2 asks for vulnerability handling and disclosure processes. A bounty program is one option, not a requirement.
Sources
Last reviewed: 19 October 2026.
