The reporting section should say where to send a report, what details to include, which languages you read, whether encryption is supported, and what the reporter can expect next. Keep it to a short page so people read it before they write.
What the sources ask for
CISA's directive says a disclosure policy must describe how to submit reports, including where reports go, such as a web form or email address, and a request for the information needed to find and understand the issue. It also asks the reporter to allow a reasonably time-limited response period before any public disclosure.
OWASP's list of useful reporting guidelines includes: specific information that helps confirm and fix the issue, categories or confidentiality marking on a bug tracker, PGP keys for encrypted communication, a timeline for initial response and triage, and safe harbor terms.
An outline you can copy
| Part | Example content |
|---|---|
| Where | One address or form, with a backup |
| What to include | Product, version, steps, requests and responses, impact |
| What to leave out | Real personal data, large data downloads |
| Language | The languages you can read |
| Encryption | Whether you offer it, or prefer the web form |
| Response | When they will hear from you first, and how long you ask them to wait before going public |
| Next steps | Triage, fix, advisory, credit |
| Rules | Link to scope and testing rules |
Details to ask for
Make the request specific, so reporters do not guess:
- The affected product, URL or component.
- The version or build, if known.
- Step by step instructions to reproduce.
- Raw requests and responses or logs.
- What an attacker gains.
- Whether the issue is already public or planned for publication.
- How they want to be credited, if at all.
Language and format
The security.txt standard, RFC 9116, defines a Preferred-Languages field listing the languages you prefer for reports, and says that if it is absent, researchers may assume English. Mirror that in the policy. Say plainly if you can handle reports only in some languages, and consider offering a translation route. See handling reports in other languages.
Encryption
CISA's guidance on the federal mailbox says you may make a PGP key available but strongly recommends the web instead. If you offer a key, keep it current and test decryption. If you do not, say so, so researchers do not wonder. Compare channels in web form or email: which to offer.
Promise only what you can do
If you write "we reply within two business days", you must reply within two business days. The reply need not be a fix. It can be an acknowledgment and a next step. See what to promise researchers.
Link to it from everywhere
Put the policy URL in your security.txt Policy field, the website footer and your support pages. Our security.txt guide shows how.
After you publish
Run a test report through the full path. If you build software with open source dependencies, Safeguard's compliance and evidence automation can help you show customers the controls behind your process, and a free scan gives a quick view of your dependencies.
Quick check
Is a web form better than email?
CISA's guidance prefers the web over encrypted email, mostly because key handling is hard. Offering both is fine if both are monitored.
Do I need to publish a response time?
It helps. CISA's directive asks reporters to allow a reasonably time-limited response period, which only works if you say what you will do in that time. Choose numbers you can keep.
Sources
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
- OWASP Vulnerability Disclosure Cheat Sheet
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
Last reviewed: 19 October 2026.
