Vulnerability disclosure policy: what to publish before a researcher finds something

A researcher who finds a flaw in your product has to decide what to do with it, and your organisation gets a say in that decision only if you told them how to report it. Without a published policy the realistic outcomes are that they give up, post it publicly, or reach a journalist - none of which you control.

It is increasingly a requirement, not a courtesy

ISO 27001 expects vulnerability handling and disclosure processes. The EU Cyber Resilience Act imposes obligations on products with digital elements. Government supplier requirements in several jurisdictions ask for one. What was a maturity signal is becoming a control you are assessed on.

What the policy must contain

• How to report - a dedicated address, ideally a security.txt file at a well-known location so it is findable without searching.
• Scope - which domains, products and versions are in, and what is explicitly out.
• Prohibited testing - denial of service, social engineering of staff, accessing other users' data, physical intrusion. Be specific; vagueness here is what causes disputes.
• What you commit to - acknowledgement within a stated period, updates at a stated cadence, and a target for resolution.
• Safe harbour - the clause that decides whether anyone reports at all.
• Recognition - whether you credit reporters, and whether they may publish afterwards.

Safe harbour is the clause that matters

Researchers in most jurisdictions face genuine legal exposure under computer misuse laws for testing systems they do not own. Without an explicit assurance that you will not pursue action for good-faith research conducted within your stated scope, a cautious researcher walks away and a reckless one publishes.

Have the wording drafted by counsel, but do not water it down to meaninglessness. A safe harbour clause hedged into uselessness is worse than none, because it signals that you consulted lawyers and chose not to protect the person helping you.

VDP is not a bug bounty

• A VDP is a published route for unsolicited reports. Free, and every organisation should have one.
• A bug bounty pays for findings and actively invites testing. It generates volume, which is only useful if you can triage and fix at that rate.

Running a bounty before you can handle a VDP is a common and expensive mistake. If reports already sit unanswered for weeks, paying for more of them will not help.

The internal process behind it

Publishing the policy is the easy part. Behind it you need a monitored inbox with an owner and a deputy, a triage path that reaches engineering rather than sitting in a support queue, an internal timeline that matches your public commitment, a decision on coordinated disclosure timing, and a route to notify affected customers where relevant.

The failure mode is a published policy with a promise of a five-day response and an unmonitored mailbox behind it. That is worse than silence - you made a commitment publicly and visibly broke it.

When a report arrives

1. Acknowledge quickly, even before you have assessed it. Researchers escalate mainly when ignored.
2. Validate and assess impact before arguing about severity.
3. Keep the reporter informed on the cadence you promised.
4. Agree disclosure timing rather than asking for indefinite silence, which is what turns a cooperative reporter adversarial.
5. Credit them if they want it. It costs nothing and builds a reputation that brings you future reports.

Key takeaways

• Without a published route, findings reach someone else.
• Safe harbour decides whether anyone reports; do not hedge it into uselessness.
• Build the triage process before publishing the commitment.
• Run a VDP well before considering a bounty.