A vulnerability disclosure policy should say which systems are in scope, what testing is allowed, how to report, what happens next and when, and that good faith research will not draw legal action. It should carry an issue date and a monitored contact. This page lists each element and where it comes from.
Where do the required elements come from?
The clearest public model is CISA's Binding Operational Directive 20-01, which required US federal agencies to publish a policy. It is written for agencies, but the list is a sound baseline for anyone. The directive says the policy must include:
- Which systems are in scope, with at least one internet-accessible production system at publication.
- The types of testing that are allowed or specifically not authorized, and a statement prohibiting disclosure of personally identifiable information found during testing.
- How to submit a report, including where to send it, a request for the information needed to find and analyze the issue, and a clear statement that reporters may submit anonymously.
- A commitment not to recommend or pursue legal action against anyone whose research the organization concludes was a good faith effort to follow the policy.
- A statement of when the reporter can expect acknowledgement, and a pledge to be as transparent as possible about remediation.
- An issuance date.
The directive also says the policy must not require personally identifiable information from the reporter, and must not limit testing to vetted parties or to US citizens.
What does the OWASP cheat sheet add?
OWASP's Vulnerability Disclosure Cheat Sheet speaks to both sides. For organizations it says to provide a clear and secure method to report, set out scope and bounty terms, respond within a reasonable timeline, communicate openly, avoid threatening legal action, request CVEs where appropriate, publish advisories and offer credit. For researchers it asks for authorized testing, respect for privacy and enough detail to reproduce.
It also describes the disclosure models: private, full and coordinated. It notes that Google's Project Zero policy generally allows vendors 90 days to make a patch available. Your policy should state your own timeline instead of leaving it to be assumed.
How do you make it findable?
RFC 9116 defines a security.txt file, served from a well-known location on your site. Two fields are mandatory: Contact, which says how to report, and Expires, a date after which the file is considered stale. The RFC recommends an expiry less than a year ahead. An optional Policy field links to your disclosure policy.
A file with an expired date looks abandoned, so put its renewal on a calendar.
What is safe harbor, and do you need it?
disclose.io describes safe harbor as language that lets people acting in good faith report issues without fear of legal repercussions, and publishes a lawyer-reviewed framework you can adapt. Have your own counsel review whatever wording you adopt. The point is to remove the chilling effect that keeps honest reporters quiet.
What to do
- List the systems in scope and the ones explicitly out of scope.
- Write what testing is allowed and what is not, such as denial of service and social engineering.
- Provide one monitored reporting channel and say reports may be anonymous.
- Add good faith, safe harbor language reviewed by counsel.
- Commit to acknowledgement and update times you can really meet.
- State whether you pay rewards. If not, say so.
- Publish the policy with an issue date and publish a security.txt with Contact, Expires and Policy.
- Name an owner, and review the policy each year.
Quick check
Is a disclosure policy the same as a bug bounty?
No. A policy invites and governs reports. A bounty adds payment and its own terms.
What if we cannot fix issues quickly?
Say so in the policy and give a realistic response timeline. Silence pushes researchers toward full disclosure.
Sources
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy, fetched 18 October 2026
- OWASP Vulnerability Disclosure Cheat Sheet, fetched 18 October 2026
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, fetched 18 October 2026
- disclose.io, fetched 18 October 2026
Last reviewed: 18 October 2026.
