How to Write a NIS2 Vulnerability Disclosure Policy: Article 12 Requirements, Bug Bounty Programs, and CSIRT Coordination

CVD Under NIS2: Two Separate Obligations, One Coherent Framework

Most NIS2 guidance focuses on the CSIRT coordinator mechanism established by Article 12 — the national-level infrastructure that facilitates vulnerability disclosure between reporters and ICT manufacturers. But if you are an essential or important entity under NIS2, your primary CVD obligation comes from a different provision entirely: Article 21(2)(e), which requires you to implement “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.”

These two articles operate at different levels and create different duties. Article 12 builds the national CVD infrastructure; it is addressed to member states and their designated CSIRTs. Article 21(2)(e) is addressed to you — the entity — and it requires a working vulnerability disclosure process as part of your mandatory cybersecurity risk-management measures. Getting this distinction right is the starting point for compliance.

Who Does Each Provision Apply To?

Before building your CVD policy, confirm which provisions apply to your organisation.

Provision	Applies To	Core Obligation
NIS2 Article 12	EU member states and their designated CSIRTs	Designate a CSIRT as CVD coordinator; enable anonymous vulnerability reporting; contribute to the EU Vulnerability Database
NIS2 Article 21(2)(e)	Essential and important entities in NIS2 sectors	Implement vulnerability handling and disclosure as part of cybersecurity risk-management measures
CRA Article 14	Manufacturers of products with digital elements	Mandatory 24-hour, 72-hour, and 14-day notification of actively exploited vulnerabilities to national CSIRT and ENISA

If your organisation is classified as essential or important under Article 3 of the directive, Article 21(2)(e) applies regardless of whether you manufacture products. If you also develop or sell software or hardware products, CRA Article 14 creates an additional, separate reporting obligation from September 2026. To understand whether your organisation falls within NIS2 scope, see our full NIS2 requirements guide.

Does This Apply to You? A Quick Decision Path

Do you operate in a NIS2 Annex I or Annex II sector (energy, transport, banking, healthcare, digital infrastructure)? If yes, you are in scope and Article 21(2)(e) applies.
Do you exceed the size threshold — 50 or more employees, or annual turnover above €10 million? If yes, you are likely classified as essential or important.
Do you manufacture products with digital elements (software, connected devices, industrial controllers)? If yes, CRA Article 14 will also apply from 11 September 2026.
Uncertain about your classification? Contact your national competent authority. Classification determines supervision intensity and maximum penalty exposure.

NIS2 Article 12 coordinated vulnerability disclosure pathway from security researcher through CSIRT coordinator to vendor and public disclosure — Under NIS2 Article 12, the designated CSIRT acts as the trusted intermediary between the reporter and the affected vendor, negotiating timelines and managing multi-entity cases.

How NIS2 Article 12 Works: The CSIRT Coordinator Role

Article 12 of Directive (EU) 2022/2555 requires each EU member state to designate one of its CSIRTs as the national CVD coordinator. This CSIRT acts as a trusted intermediary — not a passive mailbox, but an active party that facilitates the full disclosure process between the person or organisation reporting a vulnerability and the affected vendor or service provider.

The designated CSIRT coordinator carries four specific obligations under the directive: identifying and contacting entities affected by a reported vulnerability; assisting the reporter throughout the process; negotiating disclosure timelines with the vendor; and managing cases where the vulnerability affects multiple entities, potentially across borders. Where a vulnerability has cross-border implications, the national CSIRT coordinators cooperate through the established EU CSIRT Network.

A key statutory guarantee: reporters can submit vulnerabilities anonymously. The CSIRT coordinator must maintain confidentiality and take diligent follow-up action. This anonymity protection directly addresses one of the historic barriers to responsible disclosure — the legal risk to the reporter — and is now a legal right across all EU member states.

By 17 October 2024 — the NIS2 transposition deadline — member states were required to have CVD policies and designated coordinator CSIRTs in place. As of mid-2025, Belgium (CCB), Germany, Finland, Latvia, Lithuania, Malta, and Poland have fully operational national CVD frameworks. Czech Republic, Denmark, Estonia, Greece, Romania, Spain, Sweden, and Cyprus remain in development stages, with most operating under informal arrangements pending formal transposition.

The European Vulnerability Database (EUVD)

ENISA launched the European Vulnerability Database on 13 May 2025. The EUVD provides aggregated, actionable information on vulnerabilities affecting ICT products and services — covering severity assessments, affected product versions, patch availability, and mitigation guidance. Since January 2024, ENISA has operated as a CVE Numbering Authority (CNA), enabling it to assign CVE identifiers to vulnerabilities discovered by EU CSIRTs or reported to them for coordinated disclosure.

The EUVD offers three dashboard views: critical vulnerabilities, actively exploited vulnerabilities, and EU-coordinated vulnerabilities. It draws from national CSIRT advisories, vendor guidance, open-source vulnerability databases, and CISA’s Known Exploited Vulnerabilities catalogue. Participation by entities is voluntary — the mandatory mechanism under Article 12 operates at the CSIRT coordinator level, not at the level of direct entity submission.

Your Organisation’s CVD Obligation: Article 21(2)(e) in Detail

Article 21(2)(e) requires essential and important entities to implement measures covering “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.” This is one of ten mandatory security measure categories under NIS2 and will be verified by competent authorities during supervision and audits.

In practice, “vulnerability handling and disclosure” under Article 21(2)(e) means your organisation needs four operational capabilities:

A published vulnerability intake channel — a named email address, web form, or managed disclosure platform where external reporters can submit reports. The channel should support encrypted submissions and specify a response commitment.
An internal triage process — documented steps for receiving, assessing severity, assigning ownership, and prioritising remediation. Without a triage process, intake channels become backlogs with no accountability.
A remediation tracking mechanism — a way to track each reported vulnerability from intake through to fix or accepted risk, with timestamps that create an audit trail for regulators.
A disclosure decision process — a defined process for deciding when and how to disclose a vulnerability publicly, including who has authority to approve disclosure and under what conditions.

These CVD processes connect directly to the secure acquisition and maintenance obligations in your software development lifecycle. A vulnerability disclosure workflow and a secure development lifecycle are not separate systems — they are two ends of the same security process. For how these fit together, see our NIS2 secure development guide.

CVD Gap Analysis	Current State (typical)	Required State	Effort
Vulnerability intake channel	No public security contact	Published security@ address or web form, with encrypted submission option	Low
Internal triage process	Ad hoc, undocumented	Written SLA: acknowledge within 5 days, triage within 10	Medium
Remediation tracking	Email threads, no audit trail	Ticket system with mandatory CVD fields and timestamps	Medium
Disclosure decision authority	Unclear or ad hoc	Named role (CISO or equivalent) with documented decision criteria	Low
Published CVD policy document	None	Public-facing policy with scope, timelines, safe harbour, exclusions	Medium

How to Write Your CVD Policy: Structure and Required Elements

A CVD policy is a public document that tells security researchers what to report, how to report it, what you commit to doing with their report, and what they can expect in return. It creates the legal and procedural framework for responsible disclosure at your organisation.

1. Scope Definition

List which systems, services, and product categories are in scope — and explicitly exclude others. Ambiguous scope is one of the most common reasons CVD programmes fail: reporters waste time on out-of-scope assets, and you receive noise rather than signal. “All production systems hosted at [your domains]” is cleaner and more defensible than “our technology infrastructure.”

2. Reporting Channel and Encryption

Provide a dedicated channel: a security@ address, a web form, or a managed disclosure platform. If you want encrypted reports — and for critical infrastructure entities, you should — publish your PGP public key or use a platform that handles encryption natively. State your initial response commitment clearly; five business days is the accepted industry norm and signals that the channel is actively monitored.

3. Disclosure Timeline Commitment

State how long you will take to remediate before public disclosure occurs. NIS2 does not mandate a specific number of days — the CSIRT coordinator negotiates timelines in complex multi-party cases. Industry practice, as established by frameworks including ISO/IEC 29147 and organisations such as Google Project Zero, centres on 90 days as the standard embargo period, with extensions possible for complex vulnerabilities when agreed with the reporter.

Your policy should commit to a default timeline (90 days is a widely accepted baseline) and define a clear process for requesting an extension. Open-ended timelines without a stated maximum are a red flag to experienced researchers and a governance weakness in a regulatory audit.

4. Safe Harbour Commitment

Provide explicit assurance that reporters acting in good faith — not exploiting the vulnerability, not exfiltrating data, not disrupting services — will not face legal action for the act of discovery and reporting. This is the single most important trust signal your CVD policy can send. Without safe harbour language, skilled researchers will disclose elsewhere or withhold reports entirely.

5. Triage and Remediation Workflow

Describe your internal process at a high level: how you assess severity, how you communicate with the reporter during remediation, and what the reporter can expect at each stage. You do not need to expose internal tooling details — the purpose is to give the reporter confidence that their report will be acted on, not ignored.

6. Public Disclosure Process

State how you will disclose the vulnerability after remediation: whether you will issue a CVE through ENISA or another CNA, publish a security advisory, or coordinate through your national CSIRT. If you intend to credit reporters publicly, say so. Credit is a meaningful incentive that costs nothing and materially increases both the quality and volume of incoming reports over time.

7. Exclusions and Legal Boundaries

Clearly state what is not permitted: automated scanning of production systems, social engineering of staff, physical access attempts, or accessing customer data beyond what is strictly necessary to demonstrate the vulnerability. Explicit exclusions protect both parties and prevent scope disputes that undermine the programme.

Roles and Responsibilities

Task	CISO / IT Security	Legal / Compliance	Board
CVD policy authorship and maintenance	Owns	Reviews	Approves
Vulnerability intake operation	Operates	—	—
Triage and severity assessment	Owns	—	—
Safe harbour legal language	Contributes	Owns	—
Public disclosure decision	Co-decides	Co-decides	Informed
Regulatory audit trail maintenance	Owns	Supports	Accountable
National CSIRT coordinator relationship	Manages	—	—

Disclosure Timelines and What Happens When the Window Closes

The 90-day embargo period is an industry standard, not a legal mandate under NIS2. Its logic is practical: it gives vendors enough time to develop and test a patch for most vulnerabilities while preventing indefinite suppression of security issues that put users at risk. Google Project Zero, CERT/CC, and the ISO/IEC 29147 framework all use 90 days as the baseline, with the understanding that extensions can be granted for complex or critical vulnerabilities when the vendor is actively working toward a fix.

When a vendor does not respond or fails to remediate within the agreed window, the CSIRT coordinator’s role becomes decisive. Under Article 12, the CSIRT can intervene to negotiate additional time, or — where the vulnerability poses an immediate public risk — facilitate disclosure even without a patch available. The CSIRT is not a gatekeeper that can block disclosure indefinitely; its mandate is to ensure disclosure happens in a structured way that maximises public protection while giving vendors a fair opportunity to respond.

For multi-vendor incidents, where the same vulnerability affects components used by multiple entities, the national CSIRT coordinates with other member state CSIRTs through the EU CSIRT Network. ENISA provides oversight at the EU level and, in the most complex cases, manages cross-jurisdictional coordination directly.

The NIS2 incident reporting obligation under Article 23 runs parallel to CVD but is distinct from it. Incident reporting concerns significant events that have already occurred and affected operations; CVD concerns vulnerabilities that have been discovered but not yet exploited. Your team needs clear internal criteria for when a vulnerability crosses into incident territory — typically when there is evidence of active exploitation. See our NIS2 incident reporting guide for the Article 23 thresholds and timelines.

Bug Bounty Programmes: When They Add Value

The NIS Cooperation Group — the body that supports NIS2 implementation across member states — has explicitly endorsed vulnerability reward programmes, including bug bounty programmes, as an impactful mechanism for implementing CVD. This matters practically: it means regulators view a well-run bug bounty programme as a credible compliance tool, not just a commercial practice.

A bug bounty programme and a CVD policy are not the same thing. A CVD policy defines your process for receiving, handling, and disclosing vulnerabilities from any external reporter. A bug bounty programme adds a financial incentive layer to encourage researchers to report to you specifically. You can have a CVD policy without a bug bounty; running a bug bounty without a CVD policy creates legal exposure because the terms and obligations are undefined.

A bug bounty programme makes practical sense for NIS2 entities when three conditions are met:

Large or internet-exposed attack surface: public APIs, consumer-facing applications, or services where external discovery is likely regardless of internal testing
High-criticality classification: essential entities in energy, banking, or digital infrastructure, where the cost of an undisclosed breach substantially exceeds programme operating costs
Mature underlying security programme: triage processes, remediation tracking, and disclosure workflows are already in place — you are adding incentive, not building process from scratch

For smaller important entities or organisations with limited security resources, a well-written CVD policy with a responsive email channel and documented triage process fully satisfies Article 21(2)(e). The minimum viable CVD setup — a published policy, a monitored inbox, and a triage procedure — can be implemented in weeks, not months, and is audit-defensible on its own.

NIS2 CVD vs CRA Article 14: Understanding the Overlap

The Cyber Resilience Act (CRA), which entered into force on 10 December 2024, creates a mandatory vulnerability reporting obligation for manufacturers of products with digital elements — separate from, and running alongside, NIS2’s CVD framework. If your organisation both operates critical infrastructure and manufactures software or connected devices, both regimes apply and their requirements do not overlap cleanly.

	NIS2 Art. 12 + 21(2)(e)	CRA Article 14
Who it applies to	Essential and important entities	Manufacturers of products with digital elements
Obligation type	CVD framework + policy (cooperative)	Mandatory notification (regulatory reporting)
Report to	CSIRT coordinator; voluntary EUVD participation	National CSIRT + ENISA (mandatory)
Timeline	Negotiated; industry standard is 90 days	24h early warning / 72h full notification / 14-day final report
Trigger	Vulnerability discovered and reported externally	Actively exploited vulnerability or severe incident
Effective date	17 October 2024 (NIS2 transposition deadline)	11 September 2026
Reporter anonymity	Guaranteed for external reporters under Art. 12	N/A (manufacturer reports its own vulnerabilities)

The practical implication for dual-scope organisations: you need both a CVD policy (NIS2 Art. 21(2)(e)) and a rapid-response vulnerability notification pipeline for your products (CRA Art. 14). CRA’s 24-hour early warning window in particular requires pre-established internal escalation paths. You cannot build that escalation chain in real time when a vulnerability in your product is actively exploited in the wild.

NIS2 CVD Compliance Checklist

Action	Owner	Status
Confirm NIS2 classification: essential or important entity (Article 3)	Legal / Compliance	☐ Complete
Designate a CVD point of contact with clear accountability (CISO or equivalent)	Board / CISO	☐ Complete
Publish CVD policy covering scope, channels, timelines, safe harbour, and exclusions	CISO / Legal	☐ Complete
Establish and monitor a vulnerability intake channel with encrypted submission option	IT Security	☐ Complete
Document internal triage process with acknowledgement and resolution SLAs	IT Security	☐ Complete
Identify your national CSIRT coordinator and establish a point of contact	CISO	☐ Complete
Familiarise security team with the EUVD at euvd.enisa.europa.eu	IT Security	☐ Complete
Audit supply chain contracts for CVD clause requirements	Legal	☐ Complete
If applicable: build CRA Article 14 notification pipeline before September 2026	CISO / IT Security	☐ Complete
Document all CVD activity (intake, triage, remediation, disclosure) for regulatory audit	CISO	☐ Complete

Frequently Asked Questions

Is a bug bounty programme mandatory under NIS2?

No. Bug bounty programmes are one effective implementation mechanism, endorsed by the NIS Cooperation Group, but not a legal requirement. A published CVD policy with a responsive intake channel and documented triage process fully satisfies Article 21(2)(e).

What if we cannot patch a reported vulnerability within 90 days?

Contact your national CSIRT coordinator and request a timeline extension, documenting the technical reasons for the delay. NIS2 does not mandate a specific disclosure deadline — the CSIRT coordinator facilitates negotiation between you and the reporter. Non-response is not a strategy: regulators treat failure to engage as a governance failure independent of the technical issue.

Do we need to register vulnerabilities directly with the EUVD?

Not necessarily. Entity participation in the EUVD is voluntary. If your national CSIRT coordinates disclosure on your behalf, they may register the vulnerability as part of the coordination process. If you are a manufacturer subject to CRA Article 14, reporting to your national CSIRT and ENISA is mandatory from September 2026, and ENISA feeds relevant information into the EUVD automatically.

Does our CVD policy need to comply with a specific standard?

NIS2 does not mandate a named standard. ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling processes) are the reference frameworks most commonly aligned with and accepted by regulators. ENISA’s published CVD guidelines and the NIS Cooperation Group’s guidance documents are the authoritative EU-level references.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.