In the first 30 days, test the intake path, name owners, answer every report fast, record dates, and review scope at the end. Expect few reports at first and a few noisy ones. The goal is to prove the process works, not to hit a volume target.
Week 0: before the page goes live
- Send a test report to the address and time the reply.
- Confirm the rota owner and backup, as in who should own the security inbox.
- Make sure support staff know the forwarding rule.
- Create a private case tracker with the fields from the tracking record post.
- Prepare templates: acknowledgment, request for details, closure.
- Agree who approves advisories and who speaks to customers.
CISA's directive makes a related point. Before a policy is published, an agency must already be able to receive unsolicited reports. Build the capability first.
Week 1: publish and link
Publish the policy and link it from the footer and your security.txt file. OWASP stresses that the easier it is to contact you, the more likely you will receive reports, and that more mechanisms are better. Check that each link works.
Week 2: handle the first reports
| Task | Target |
|---|---|
| Acknowledge every report | A named reply, ideally same business day |
| Triage | Follow the 24 hour routine |
| Update researchers | Even if nothing changed |
| Record dates | Received, first reply, validated |
| Keep a list of questions | Which parts of the policy confused people |
Do not be alarmed if the first reports are scanner output or low value. Treat them politely and use them to tune your templates. See replying to a scanner dump.
Week 3: fix and close one case end to end
Even a small case teaches you the whole path: triage, fix, retest, advisory or release note, credit and closure. Time each handoff. Where did it wait? That is where to improve.
Week 4: review
Hold a 45 minute review with the owner, an engineering lead and whoever speaks for the company:
- How many reports arrived, and how many were valid?
- What was the median time to first reply?
- Which reports were out of scope, and should scope change?
- Which questions did reporters ask that the policy did not answer?
- Did any report reach the wrong inbox?
- Is the rota sustainable?
Use the metrics in which metrics to track.
Common first month surprises
- Reports about third party systems you do not own.
- Requests for rewards even though you do not run a bounty.
- Reports from customers who are not researchers.
- A flood of similar findings after someone posts about your policy.
Safeguard note
If your product has open source dependencies, scan before launch so that known issues do not arrive as reports. Safeguard offers dependency scanning and reachability analysis, and a free scan is available.
Quick check
What if we get no reports in 30 days?
That is common. Check that the policy is findable and the address works, then keep going. Silence does not prove you are secure.
Should we announce the policy publicly?
A short post or note is fine. Make sure you are ready for the reports it may bring.
Sources
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
- OWASP Vulnerability Disclosure Cheat Sheet
Last reviewed: 19 October 2026.
