What is Responsible Disclosure?
Responsible disclosure is a policy and process by which ethical hackers, researchers and suppliers confidentially report a vulnerability they have found to the owner or manufacturer of a system, so that it can be fixed before the details become public. Today the same approach is usually called Coordinated Vulnerability Disclosure (CVD): in 2018 the Dutch NCSC replaced its 2013 responsible disclosure guideline with the Coordinated Vulnerability Disclosure Guideline. The word “coordinated” stresses that the reporter and the organisation agree together on when and how details are published. CVD matters even more in OT and ICS environments, where patches can take months or years to arrive.
🎯 Why does responsible disclosure matter?
No organisation finds all of its own flaws. External researchers extend the reach of your security monitoring, but only if they know where to go and need not fear legal consequences.
| Benefit | Explanation |
|---|---|
| Fast detection | External reporters find vulnerabilities that internal testing and a pentest miss |
| Coordinated mitigation | You get time to patch or put measures in place before disclosure |
| Less risk of full disclosure | A reporter without a channel is more likely to publish straight away, or sell the flaw |
| Community relationship | Demonstrates openness and cooperation with ethical hackers |
| Compliance and reputation | NIS2, the Cyber Resilience Act and IEC 62443-4-1 (part of the IEC 62443 series) all call for a form of CVD |
The alternatives are unattractive. With full disclosure, the researcher publishes everything at once, so attackers and defenders start at the same moment. With non-disclosure, the flaw stays unknown or reaches attackers through exploit brokers as a zero-day.
🔄 What is the difference between responsible, coordinated and full disclosure?
| Model | Who decides on publication? | Typical deadline | Risk |
|---|---|---|---|
| Responsible disclosure | The organisation; the reporter waits for the fix | Often 60–90 days | The organisation can drag the process out indefinitely |
| Coordinated vulnerability disclosure | Reporter and organisation together, possibly with a coordinator | Agreed deadline, extended for complex fixes | Requires trust and good communication |
| Full disclosure | The reporter, immediately and completely | None | Attackers get a head start |
| Bug bounty | Platform or organisation, with a financial reward | Per programme rules | Reporters may be bound by confidentiality |
Well-known research teams use fixed deadlines. Google Project Zero publishes after 90 days, with an extra 30 days for users to install the patch. CERT/CC works with 45 days and the Zero Day Initiative with 120 days. The Dutch NCSC acknowledges a report within one working day, gives an initial assessment within three working days and aims for a fix within 60 days.
🛠️ What belongs in a responsible disclosure policy?
| Element | Description |
|---|---|
| Contact channel | A dedicated email address or form, preferably with a PGP key for encrypted reports |
| Scope | Which systems and domains may be researched, and which explicitly may not |
| Rules of engagement | No downloading or changing data, no DoS, no social engineering, go no further than necessary |
| Legal commitment | The organisation will not file a criminal complaint if the reporter follows the rules |
| Timelines | Acknowledgement, initial assessment and target resolution time (for example 90 days) |
| Publication | Whether and when the reporter may publish, and whether the organisation issues an advisory or CVE |
| Reward or recognition | Optional: a hall of fame mention, a small gift or a bug bounty |
Note that an organisation cannot grant immunity from prosecution. Only the public prosecutor decides whether to prosecute. An organisation can, however, promise not to report the researcher to the police.
Make the policy easy to find with a security.txt file. Under RFC 9116 (2022) it lives at
/.well-known/security.txt, is served over HTTPS and must contain at least the Contact and Expires fields. The expiry date should preferably be less than a year
ahead, so stale contact details do not linger.
⚙️ How do you apply responsible disclosure in an OT environment?
In OT, even a harmless scan is risky: a fragile PLC can crash on unexpected network traffic. The policy must therefore draw tighter boundaries than in IT.
- ✅ In scope - public web portals, remote access gateways, test environments and information that turns out to be publicly exposed (for example through internet exposure)
- ✅ In scope - flaws in supplier firmware or software, reported to the supplier itself
- ❌ Out of scope - active testing, brute-forcing or exploits against live SCADA and PLC systems
- ❌ Out of scope - physical access to production sites or operating plant equipment
A practical approach in five steps:
- Define roles - appoint an owner, route reports to your CSIRT or incident team and involve the OT owner in every OT-related report.
- Publish the policy and security.txt - with an explicit OT exclusion for production systems.
- Triage - rate severity with CVSS, check whether the flaw is already on the KEV catalogue and determine which installations are affected.
- Mitigate - because an OT patch often has to wait for a planned shutdown, temporary measures such as segmentation or firewall rules are important; record everything in your vulnerability management and patch management processes.
- Close and publish - inform the reporter, publish an advisory where appropriate and review the process.
If the flaw concerns a product, the report belongs with the supplier. Major OT manufacturers run their own PSIRT; Siemens ProductCERT, for example, publishes its advisories on the second Tuesday of each month. Machine-readable advisories in CSAF format and an SBOM help asset owners see quickly whether they are affected. In the United States, CISA coordinates CVD for industrial control systems and publishes ICS advisories.
🔐 Which laws and standards are relevant?
| Regulation / standard | Relationship with responsible disclosure |
|---|---|
| NIS2 / Dutch Cybersecurity Act (Cbw) | Art. 21 lists “vulnerability handling and disclosure” as a duty of care; art. 12 has each member state designate a CSIRT as CVD coordinator, to which you can report anonymously if you wish |
| Cyber Resilience Act | Manufacturers need a CVD policy and a contact address (Annex I, Part II, points 5 and 6); fully applicable from 11 December 2027 |
| CRA Reporting Obligations | Actively exploited vulnerabilities are reported via ENISA’s Single Reporting Platform from 11 September 2026 |
| ISO 27001 & ISO 27002 | Control 8.8: management of technical vulnerabilities, including reports from outside |
| ISO/IEC 29147 and 30111 | International standards for disclosing (29147) and internally handling (30111) vulnerabilities |
| IEC 62443-4-1 | The defect management practice requires suppliers to receive, assess and disclose reports of security issues |
| IEC 62443-2-1 | The asset owner’s security programme, where vulnerability and patch management fit in |
In the Netherlands, the NCSC acts as CVD coordinator. It handles reports about central government systems and coordinates vulnerabilities affecting multiple organisations or suppliers. For other systems, you report to the owner first and involve the NCSC if you get no adequate response. In addition, the volunteer organisation DIVD (Dutch Institute for Vulnerability Disclosure) notifies owners of vulnerable systems exposed on the internet.
Assurance reports such as ISAE 3402 cover a service provider’s controls. They can show that a supplier manages vulnerabilities, but they do not replace a CVD policy.
⚖️ Is ethical hacking legal in the Netherlands?
Accessing a system without permission is computer trespass (computervredebreuk, article 138ab of the Dutch Criminal Code), even with good intentions. In its policy letter on ethical hacking of 14 December 2020, the Dutch Public Prosecution Service (OM) set out how it treats reporters. If an ethical hacker reports a vulnerability in line with the organisation’s CVD policy or the NCSC guideline, the OM in principle does not open a criminal investigation. The OM applies three criteria:
- Public interest - did the hacker act in a substantial public interest?
- Proportionality - did the hacker go no further than necessary to demonstrate the flaw?
- Subsidiarity - were there no less intrusive ways to achieve the same goal?
If an organisation without a CVD policy files a complaint anyway, the OM does not see that as a reason to treat the reporter as a suspect straight away. An investigation may still follow into whether it really was ethical hacking, in which the contribution of CVD to a safe digital society weighs heavily. Keeping a log of every step helps a reporter show afterwards that they acted proportionately.
✅ What should ethical hackers and reporters keep in mind?
- Read the policy first - the organisation’s own, or otherwise the NCSC guideline
- Stay within the rules - take no data, change nothing, do not disrupt production systems
- Exploit nothing - do not use a vulnerability further than needed to demonstrate it
- Report fully - provide enough technical detail to reproduce the flaw
- Use official channels - and keep the report confidential until the agreed publication
- Be patient - coordinating OT vulnerabilities between suppliers and users in particular takes time
Organisations should also watch externally: reports of leaked data can arrive through darknet monitoring or leak detection. A mature security organisation also uses its own red team and security by design to reduce the number of reports needed in the first place.
❓ Frequently asked questions
Is responsible disclosure the same as coordinated vulnerability disclosure?
In practice, yes: both involve reporting a vulnerability confidentially so it can be fixed before publication. Coordinated vulnerability disclosure (CVD) puts more emphasis on equal consultation between reporter and organisation. The Dutch NCSC has used the term CVD since 2018.
Does my organisation need a responsible disclosure policy?
For manufacturers of products with digital elements, the Cyber Resilience Act requires a CVD policy from 11 December 2027. Organisations under NIS2 and the Dutch Cybersecurity Act (Cbw) must handle and disclose vulnerabilities as part of their duty of care. Even without an obligation, a responsible disclosure policy is a low-cost measure that channels reports in the right direction.
What is a security.txt file?
A security.txt file is a text file at /.well-known/security.txt that, under RFC 9116, tells
people how to report security issues to you. The Contact and Expires fields are
mandatory; linking to your responsible disclosure policy via Policy is optional but common.
How long does an organisation get to fix a vulnerability?
The usual range is 60 to 90 days: the Dutch NCSC aims for 60 days, Google Project Zero applies 90 days. For OT products coordination often takes longer, because suppliers and asset owners need to test patches and roll them out during planned shutdowns.
Is a bug bounty the same as responsible disclosure?
No, a bug bounty is a responsible disclosure programme that pays a financial reward per valid report, often through a platform such as HackerOne or Intigriti. Exploit brokers such as ZERODIUM are the opposite: they buy vulnerabilities to resell them, not to get them fixed.
Where do I report a vulnerability in an industrial product?
Report a vulnerability in an industrial product first to the manufacturer’s PSIRT, via its security.txt or security page. If the manufacturer does not respond, or the flaw affects multiple suppliers, you can involve the NCSC as coordinator in the Netherlands; in the United States, CISA plays that role.
📌 In summary
Responsible disclosure gives ethical hackers a safe, legal route to report vulnerabilities and gives organisations time to fix them before attackers exploit them.
A good policy names a contact channel, scope, rules of engagement, timelines and publication arrangements, and is easy to find through security.txt. NIS2, the Cyber Resilience Act and IEC 62443-4-1 increasingly make CVD an obligation. OT environments need extra care: exclude live production systems from active research and bridge the time until a patch with temporary measures.