What happens when an external researcher finds a vulnerability in your system? Without a published responsible disclosure policy (also called coordinated vulnerability disclosure), that person has no safe way to report it — and you have no process to catch it. The European Cyber Resilience Act (CRA) and a growing number of enterprise contracts require such a process, and without it your ISO 27001 incident management is incomplete.
Why this is now a requirement
Two developments turn responsible disclosure from a “nice to have” into an obligation. First the CRA, which requires manufacturers of products with digital elements to catch and handle vulnerabilities across the lifetime. Second the procurement terms of large customers, who increasingly demand a reporting channel and a handling process. Without it, you miss demonstrable due diligence — exactly what an auditor or client checks.
The minimum policy
You do not need to build a bug-bounty programme with rewards. A workable policy contains four things:
- Contact: a clear channel, such as a security@ address or a dedicated reporting form, that is easy to find.
- Scope and safe harbour: which systems are in scope, and the commitment that you will not pursue researchers who behave properly.
- SLA: you acknowledge receipt within, say, 48 hours, and you tie a fix timeline to the severity of the report.
- Registration: reports become tickets, not loose emails that disappear into someone’s inbox.
Link this to your incident management process and your ISMS.
Publish it where people look
A disclosure policy no one can find does not exist. Put it in a fixed, logical place on your website (for example /responsible-disclosure or via a security.txt file). Researchers, but also auditors and customers, actively look for this. The mere presence of a public policy is already a positive signal of maturity.
From report to remediation
The policy is the start; the handling is what matters. Make sure every report follows the same route: acknowledge, assess for severity, link to your vulnerability and patch process, remediate within the agreed timeline, and inform the reporter. A report that is handled and documented well is strong evidence that your process works — stronger than a polished policy document without practice.
Exercise the process
As with incident response: a process that has never been used is an assumption. Once a year, send a fictitious report through your own channel and see if the chain works — does the mail arrive, is a ticket created, is the SLA met? Record the outcome and take two metrics into your management review: the number of reports and the average fix time. That shows the process is alive.
Common mistakes
- Only an email address with no process behind it — reports then vanish into an inbox.
- No safe harbour — without the commitment not to prosecute, serious researchers would rather not report.
- Not publishing the policy — an internal document does not help the outside world and does not count as a channel.
- Never testing — you would rather discover a broken reporting channel with a test report than with a real 0-day.
Getting started
This week, set up a security@ address, write a short policy page with scope, safe harbour and SLA, and publish it. Link incoming reports to your incident process. That covers a concrete CRA and customer requirement. Want to know more about incident management? See our page on ISO 27001 or take the free readiness scan.