Security researchers often discover vulnerabilities before the organisation responsible for the affected system knows they exist. What happens next can determine whether the issue is fixed responsibly or becomes a public security incident.
On 21 September 2026, Ireland's National Cyber Security Centre (NCSC) published a national Coordinated Vulnerability Disclosure framework, supported by detailed implementation guidance, a sample policy, a readiness checklist and a sample security.txt file.
The guidance gives Irish organisations a practical model for receiving, assessing and resolving vulnerability reports from independent researchers. It is also timely. Coordinated vulnerability disclosure is becoming an increasingly important part of European cybersecurity regulation, particularly under the NIS2 Directive and the EU Cyber Resilience Act (CRA).
However, publishing a contact address is not enough. An effective disclosure programme requires clear governance, technical triage, legal boundaries, communication procedures and integration with incident response and regulatory reporting.
Coordinated Vulnerability Disclosure (CVD) is a structured process through which a security researcher can privately report a suspected vulnerability to the organisation responsible for the affected product or system.
The organisation is then given a reasonable opportunity to validate the finding, assess its impact, develop and test a fix, and notify affected users where necessary. Public disclosure is coordinated so that useful information can be shared without unnecessarily increasing the risk of exploitation before a remedy is available.
A well-designed process benefits both sides. Researchers know where and how to submit reports, what testing is permitted and what response they can expect. Organisations receive earlier warning of weaknesses that might otherwise remain unknown until they are exploited by an attacker.
Without a clear process, a legitimate report may reach an unmonitored mailbox, be mistaken for a threat or be passed between legal, IT and customer-support teams while valuable remediation time is lost.
The NCSC guidance describes the complete disclosure lifecycle, from making a reporting channel discoverable to validating remediation and agreeing public disclosure. Its principal recommendations include the following.
Organisations should publish their vulnerability-reporting contact details in a standard security.txt file, following RFC 9116. This file is normally placed at https://example.com/.well-known/security.txt and can direct researchers to a dedicated email address, secure form, encryption key, disclosure policy and preferred languages.
This improves discoverability, but security.txt is only a signpost. It does not replace the underlying policy, trained personnel or internal remediation process. Note that RFC 9116 also requires an Expires field, so the file needs an owner and a review date.
The public CVD policy should specify which domains, products, APIs, IP ranges or other assets are in scope. It should also define excluded systems and prohibited activity.
The NCSC suggests considering restrictions on denial-of-service testing, social engineering, physical intrusion, access to unnecessary data and testing of third-party systems that the organisation does not own.
This is particularly important for organisations with complex supply chains or cloud environments. A company may use a service without having the legal or operational authority to permit researchers to test it.
Reports may contain exploit details, proof-of-concept code, personal data or information about unpatched systems. A general customer-service address is rarely suitable.
The NCSC recommends a secure web form or a dedicated email address supported by a PGP public key. Whatever channel is selected should be monitored, resilient and connected directly to people capable of initiating technical triage.
A CVD policy should explain how the organisation will treat good-faith research conducted within its stated boundaries. Clear safe-harbour wording can reduce uncertainty and encourage researchers to report findings privately.
This wording requires careful legal review. It should define the conditions that must be met and must not promise protection that the organisation lacks the authority to provide. The NCSC also advises against requiring researchers to sign non-disclosure agreements, as these discourage reporting, and recommends crediting researchers once the issue is remediated.
The policy should state what a researcher can expect after submitting a report. Internally, the organisation needs defined stages for:
The NCSC does not impose a single remediation deadline for every vulnerability. Complexity and risk vary considerably. The important point is to set realistic expectations, communicate throughout the process and prioritise high-risk findings appropriately.
Closing a ticket when a patch is created is not sufficient. The remediation should be tested to confirm that it resolves the vulnerability and does not introduce new problems elsewhere.
The organisation should also conduct a short post-incident review. Was the report acknowledged promptly? Did the right product owner become involved? Were regulatory reporting questions assessed? Did supplier dependencies delay the fix? These lessons should feed back into the policy and vulnerability-management process.
Direct contact between researcher and organisation remains the preferred route. However, as the national CSIRT, the NCSC can act as a neutral party where communication breaks down, where several organisations are affected or where a vulnerability has a cross-border element. It also offers anonymous reporting to build trust.
Two caveats matter. NCSC-facilitated anonymous reporting does not create general legal immunity for a researcher, and the NCSC notes that it may be legally obliged to share information with the appropriate authorities. The guidelines include a dedicated section on the legal context of CVD in Ireland, which both organisations and researchers should read before drafting or relying on safe-harbour terms.
The new Irish framework is official guidance. It does not create a universal legal requirement for every organisation to operate a public disclosure programme. Its regulatory importance should nevertheless not be underestimated.
NIS2. NIS2 requires in-scope essential and important entities to implement cybersecurity risk-management measures, including vulnerability handling and disclosure (Article 21). Ireland has not yet completed national transposition: the National Cyber Security Bill has not been enacted, and in July 2026 the European Commission referred Ireland to the Court of Justice of the EU over the delay. Organisations should distinguish readiness guidance from final Irish statutory requirements, but should not treat the delay as a reason to wait.
Cyber Resilience Act. The CRA goes further for manufacturers of products with digital elements. Its essential requirements include processes for handling and remediating vulnerabilities, a coordinated vulnerability disclosure policy and a contact address for reporting vulnerabilities. The CRA's main product obligations apply from 11 December 2027.
Separate CRA reporting duties have already applied to manufacturers since 11 September 2026 for actively exploited vulnerabilities and severe incidents affecting products with digital elements. These follow a staged timeline: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report (within 14 days of a corrective measure being available for an exploited vulnerability, or within one month for a severe incident). Notifications are submitted through ENISA's single reporting platform to the CSIRT designated as coordinator.
This creates an important operational connection: a vulnerability received through a CVD channel may require more than ordinary remediation. Triage must also determine whether there is evidence of active exploitation, whether a product available in the EU is affected and whether the CRA reporting process should be activated.
A reported vulnerability is not automatically reportable under the CRA. Equally, organisations must not allow a report to remain in an engineering queue without assessing whether a 24-hour legal notification clock has started.
For organisations operating an ISO/IEC 27001 information security management system, CVD should not become an isolated technical procedure. It can support existing ISO/IEC 27001:2022 Annex A controls, including:
ISO/IEC 27701 programmes should also address the privacy aspects of vulnerability research. A researcher may inadvertently encounter personal data while proving a weakness. The policy should instruct researchers to minimise access and stop testing when personal information is encountered, while the internal workflow should trigger an appropriate privacy and potential personal-data-breach assessment, bearing in mind the 72-hour GDPR notification window.
The researcher's own identity and contact details are also personal data. Organisations should explain how this information will be protected and obtain consent before publicly crediting an individual.
Organisations do not need to launch a large bug-bounty programme to implement coordinated disclosure. A proportionate starting point is to:
1. Assign ownership. Decide which function owns incoming reports and identify named technical, legal, privacy and communications contacts.
2. Publish security.txt. Provide a discoverable and monitored reporting route, ideally supporting encrypted submissions.
3. Create a public CVD policy. Define scope, exclusions, permitted testing, safe harbour, confidentiality, researcher credit and expected communications. The NCSC's sample policy is a good starting point.
4. Build an internal triage workflow. Record evidence, validate the issue, assess severity, identify affected products and systems, and check for duplicates.
5. Integrate regulatory escalation. Include explicit decision points for the CRA, NIS2, GDPR, contractual notification duties and sector-specific rules.
6. Connect suppliers. Establish how vulnerabilities involving hosted services, third-party components and open-source dependencies will be escalated and coordinated.
7. Run a tabletop exercise. Test the process using a scenario involving a serious product vulnerability, an unresponsive supplier and a researcher considering public disclosure.
Ireland's new CVD framework should be treated as more than a template-writing exercise. It is a practical bridge between security research, vulnerability management, incident response and emerging European regulatory obligations.
Publishing security.txt may take minutes. Building a process that ensures the report reaches the right people, receives a technically sound response and triggers the correct legal assessment requires considerably more preparation.
Organisations that establish this capability now will be better placed to address vulnerabilities before they become incidents and to demonstrate a structured, defensible approach under NIS2, the Cyber Resilience Act and their existing information-security management systems.
Cycubix helps organisations design and test practical vulnerability-management and coordinated-disclosure processes aligned with ISO 27001, NIS2 and the Cyber Resilience Act. Support can include CVD policy development, security.txt implementation, CRA reporting integration, roles and workflow design, and scenario-based tabletop exercises for product, security, legal and privacy teams.
Talk to us about your organisation's vulnerability-disclosure or CRA readiness requirements.
