Most discussion of NIS2 focuses on incident reporting and risk-management measures. The coordinated vulnerability disclosure side gets less attention, even though it shapes how every regulated organisation is expected to handle the moment a researcher arrives with a flaw. Here is what NIS2 actually asks for, in plain terms.
NIS2 Splits CVD Across Two Layers
NIS2 divides coordinated vulnerability disclosure between a national layer and an organisational layer.
At the national layer, every Member State must adopt policies that promote and facilitate coordinated vulnerability disclosure, and must designate at least one CSIRT to act as coordinator. That CSIRT receives vulnerability reports, follows up on them, protects the anonymity of the reporter where requested, and coordinates between parties when a flaw affects more than one vendor. Member States must also allow a person to report a vulnerability anonymously, and give researchers a degree of legal protection when they follow the rules.
At the organisational layer, essential and important entities must treat vulnerability handling and disclosure as part of their risk-management measures. This is the part that lands on companies rather than governments. NIS2 does not set out a full template, but the NIS Cooperation Group guidance fills that gap with a clear set of expectations.
What a CVD Policy Is Expected to Contain
The guidance reads almost as a checklist. An organisation adopting its own CVD policy is expected to cover the following.
- Scope. State plainly which systems and services are in scope, and list anything provided by third parties that is excluded. Reporters should not have to guess.
- A point of contact. A dedicated channel for reports, such as a security address or an online form, with internal routing so reports arriving through other channels reach the right team. A security.txt file on the website helps researchers find it.
- Proportionality. The reporter should not disrupt service or go further than needed to demonstrate the flaw, and should not retain data, including personal data, longer than necessary.
- Good faith. The organisation commits not to pursue legal action against a reporter who follows the policy. The reporter commits to acting without intent to harm.
- Confidentiality. Reporters do not share what they find with third parties, beyond the designated CSIRT or competent authority, and do not go public without agreement.
- Personal data handling. Because a reporter may come across personal data, the policy should set written obligations on how that data is handled, limited to what is needed to prove the flaw exists and protected by encryption. For data protection professionals, this is the part worth close reading. A CVD policy can function as a form of agreement binding the researcher to the organisation, which has direct GDPR consequences for who counts as controller and on what lawful basis the data is processed.
- Reward or recognition. Optional. This ranges from a public acknowledgement or hall of fame through to a bug bounty. Recognition costs almost nothing and still raises the quality of reports.
The Operational Side
Beyond the policy text, the guidance sets expectations for how the process runs day to day.
Communication should be secure, using encryption or a protected portal, so details of an unpatched flaw do not leak. Each stage should have a deadline, for acknowledging receipt, for progress updates, for developing a fix and for any publication, while staying flexible enough for genuinely complex cases. Disclosure to the public should be coordinated with the affected parties and the designated CSIRT, so there is time to fix the flaw and warn affected users before details become public. Where a product depends on upstream components, the vendor is expected to track those dependencies and pass vulnerability information both up to suppliers and down to customers.
None of this is exotic. It is the difference between a process that holds up under scrutiny and a security address that someone checks when they remember to.
Why This Matters Now
NIS2 sets the EU-wide expectation that organisations run a proper coordinated vulnerability disclosure process. It raised the floor. What it does not do is impose specific, deadline-bound disclosure duties on every manufacturer of a connected product.
That is where the Cyber Resilience Act comes in. The CRA takes the same coordinated disclosure thinking and makes it binding on manufacturers placing products with digital elements on the EU market, with concrete obligations and hard deadlines. The vulnerability handling expectations NIS2 describes in principle, the CRA turns into a legal requirement with a date attached.
If you have read this far because NIS2 applies to you, the CRA is the next document on your desk. The good news is that an organisation that builds a credible CVD process for NIS2 has already done most of the groundwork for what the CRA will require.
Source: NIS Cooperation Group, Guidelines on Implementing National Coordinated Vulnerability Disclosure Policies, 2023.