A vulnerability disclosure policy should say what is in scope, what testing is allowed, how to report, what you promise in return, when reporters can expect a reply and the date the policy was issued. Then publish a security.txt file that points to it, so a researcher who finds a bug can reach you in minutes.
This cheat sheet leans on two primary sources: CISA's Binding Operational Directive 20-01, written for US federal agencies, and RFC 9116, the security.txt standard. A company is not bound by the directive, but its required elements are a sound checklist. Have counsel review the safe harbor language.
What does CISA require a policy to contain?
BOD 20-01 lists these elements:
- Location. A public web page, in plain text or HTML, at a standard path on the agency's site.
- Scope. "At least one internet-accessible production system or service must be in scope at the time of publication."
- Permitted testing. The types of testing that are allowed or specifically not authorized, and a statement prohibiting disclosure of any personally identifiable information found to any third party.
- How to report. Where to send reports, a request for the information needed to find and analyze the issue, and a clear statement that reporters may submit anonymously.
- Legal safe harbor. A commitment not to recommend or pursue legal action against anyone for good faith research that follows the policy.
- Response expectations. A statement setting expectations for when reporters can expect acknowledgement, and a pledge to be as transparent as possible about remediation steps.
- An issuance date.
It also says to consider noting that reporters receive no payment, and allows linking to a separate bug bounty policy.
What must the policy avoid?
The directive says the policy must not require submission of personally identifiable information, must not limit testing solely to vetted registered parties or US citizens, and must not restrict reporters from disclosing vulnerabilities beyond requesting a reasonably time limited response period. The same logic applies to a company: a policy that demands identity details or threatens researchers will not get reports.
What is security.txt?
RFC 9116 defines a small text file that tells researchers how to contact you. Serve it at /.well-known/security.txt over HTTPS as plain text in UTF-8. A top level /security.txt is allowed for legacy compatibility, and if both exist the well-known one takes precedence.
Required fields:
- Contact: how to report, as an email, phone number or web page. Multiple entries go in order of preference.
- Expires: when the file goes stale. It must appear once.
Useful optional fields: Policy (link to your disclosure policy), Encryption (a URI for a key, never the key itself), Acknowledgments (a thank-you page), Preferred-Languages, Canonical (where the file lives) and Hiring.
A minimal file looks like this:
Contact: mailto:security@example.com
Expires: 2027-10-18T00:00:00.000Z
Policy: https://example.com/security/disclosure
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
The Expires field is the one teams forget. A stale file signals neglect, so put a renewal reminder on a calendar.
What does the policy not cover?
It does not replace internal handling. Decide who triages reports, how fast you reply, how you track fixes and how you coordinate disclosure with reporters and affected vendors. If a report concerns an open source dependency you use, you may need to notify its maintainers, so name that step in your process.
What to do
- Decide which systems are in scope and name them.
- List allowed and prohibited testing, including no access to other users' data.
- Create a monitored mailbox or form for reports. Allow anonymous submission.
- Write the safe harbor sentence with counsel.
- Commit to an acknowledgement time you can keep.
- Add the issuance date and a review date.
- Publish the policy on your site and link it from the footer.
- Add
/.well-known/security.txtwith Contact, Expires and Policy. - Rehearse once: send a test report and time the response.
Quick check
Is security.txt required by law?
Not that we confirmed. RFC 9116 is a standard that defines the format. It is a voluntary way to make contact details easy to find.
Do I need a bug bounty to have a disclosure policy?
No. CISA's directive allows stating that reporters receive no payment, and a bounty can be a separate policy you link to.
Sources
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
Last reviewed: 18 October 2026.