Review your disclosure program once a year. Check that the policy is findable, the contact works, security.txt is current, response times are met, scope matches your assets, safe harbor has been read by counsel, and past reports were handled as promised. Fix gaps and date the new version.
The checklist
- Findability. Search for your policy as a stranger would. Is it linked from the footer and security page?
- Contact test. Send a test message to the security address. Time how long it takes a human to see it.
- security.txt. Check that Expires is in the future, Contact works, Policy points to the current page, and the file is served over https as text/plain. See keeping the file fresh.
- Encryption key. If you publish one, confirm it decrypts and has not expired.
- Scope. Compare it against your current asset list. Add new products, retire dead ones.
- Safe harbor. Ask counsel to confirm the wording still matches reality. See what safe harbor means.
- Response times. Measure acknowledgement, triage and update times against what you published.
- Case review. Read every report from the year. Which took longest, and why?
- Researcher feedback. Ask a few researchers what it was like to report to you.
- Advisories. Check they are complete and still online. See what an advisory contains.
- Training. Re-brief support and engineering on routing and confidentiality.
- Recognition. Update the acknowledgments page.
Why a calendar entry
OWASP stresses that a published policy, easy intake and prompt response go together. Programs fail through drift: staff leave, mailboxes change, products launch outside scope. A yearly pass catches it.
Keep evidence
Auditors and customers sometimes ask how you handle vulnerability reports. A dated review record, plus the case log, is a straightforward answer. Safeguard's compliance and evidence automation can hold such records alongside other controls, if you already use it for that.
What to measure
Count reports, valid reports, median time to acknowledge, median time to fix, and repeat reporters. Keep it simple and compare year on year.
Quick check
Is a yearly review enough?
For most teams, yes, plus a review after any major incident or product launch.
Who owns the review?
The security lead, with input from engineering, support and legal.
Sources
Last reviewed: 19 October 2026.
