Reviewed 17 August 2026
Vulnerability disclosure policy template
A coordinated disclosure policy is one of the few CRA-adjacent artefacts you can finish in an afternoon. Copy the text below, fill the brackets, publish it at a stable URL, and make sure the inbox behind it is actually monitored.
Last updated · Written and reviewed by Jonatan Tensetti · Tensetti Tools
Why it matters beyond the paperwork
A published policy changes what happens when someone finds a flaw in your product. It gives the reporter a route that is not a public tweet, it gives you a defensible timeline, and it produces the evidence trail you need if a vulnerability turns out to be actively exploited and reporting clocks start.
| Section | What reviewers look for |
|---|---|
| Contact route | A monitored address or form, not a personal mailbox, plus an encryption option. |
| Response times | Concrete numbers you can actually meet. Three working days beats an aspirational 24 hours you miss. |
| Safe harbour | A clear statement that good-faith research will not be pursued legally. |
| Scope | Named products and versions, and an honest out-of-scope list. |
| Internal handling | Evidence that reports are triaged and assessed against reporting obligations, not just filed. |
Copy this
Coordinated Vulnerability Disclosure Policy — [Company name]
Version 1.0 · Effective [date] · Owner: [role, not a person]
1. Purpose
We want security researchers and users to be able to report potential
vulnerabilities in our products safely and get a timely, human response.
2. Scope
In scope: [product names and versions], including their update mechanisms
and the services they depend on that we operate.
Out of scope: third-party services we do not control, physical attacks on
our premises, social engineering of our staff, and volumetric denial of
service testing.
3. How to report
Email: security@[company].[tld]
Encryption: [PGP key fingerprint or secure form URL]
Please include: affected product and version, a description of the issue,
reproduction steps, and the impact you believe it has. Do not include
personal data of third parties or live customer data.
4. What we commit to
- Acknowledgement within [3] working days.
- An initial assessment, including our severity view, within [10] working days.
- Regular status updates at least every [30] days until resolution.
- Credit in the advisory if you want it, and none if you do not.
5. Safe harbour
If you act in good faith, follow this policy, avoid privacy violations,
avoid degrading our services and do not exploit the issue beyond what is
needed to demonstrate it, we will not pursue or support legal action
against you for your research.
6. Disclosure
We aim to publish an advisory and a fix within [90] days of a valid report.
We will tell you if we need longer and why. We ask that you do not disclose
publicly before the advisory, unless we have failed to respond as promised.
7. What we do internally
Valid reports are triaged, tracked to closure, and assessed against our
regulatory reporting obligations, including whether the vulnerability is
being actively exploited and therefore triggers time-bound reporting.
8. Changes
This policy is versioned. Material changes are recorded with a date.After you publish it
- Put the URL in your product documentation and on your website footer.
- Add a
security.txtfile so scanners and researchers can find the contact route automatically. - Test the inbox by sending a report to yourself from an external address.
- Decide who assesses whether a report indicates active exploitation, and how quickly.
- Rehearse the escalation once, so the first real report is not also the first rehearsal.
This template is a starting point, not legal advice. Have counsel review the safe-harbour wording against your jurisdiction before publishing. Questions about the template can go to jtensetti@protonmail.com.
Reviewed 17 August 2026 · assessment version 1.0.0