When a vulnerability report arrives, acknowledge it quickly, reproduce it, rate it, tell the reporter what you found, and keep them updated until it is fixed. CISA's directive for federal agencies suggests targets of three business days to acknowledge, seven days for an initial assessment, and ninety days to resolve.
Receive and acknowledge
Step 1: Recognise the report
Reports often land in a general contact form or a support queue. The OWASP disclosure guidance says to make sure front line staff know how to recognise a security report and who to escalate it to. Write a short rule for support: anything mentioning a vulnerability, exploit or "I found a bug in your site" goes to the security owner the same day.
Step 2: Acknowledge
Reply with a short, plain message. Say you received it, name one person as the contact, and say when they will hear from you next. CISA's targets in BOD 20-01 are footnotes rather than mandates, but they make a decent starting point: acknowledgment within three business days of receipt.
Do not ask the reporter to sign anything before you will look at the report. Do not mention lawyers.
Assess and fix
Step 3: Reproduce and assess
Ask for missing detail if you need it. A report should say what the issue is, where it is, the impact, how to reproduce it, and any proof of concept. Then try it yourself.
Decide three things:
- Is it real?
- Is it in scope for your policy?
- How bad is it for your product, given how you run it?
CISA's target for the initial assessment is seven days from receipt. Tell the reporter the outcome even when the answer is "not a vulnerability" or "out of scope", and explain why.
Step 4: Fix and keep talking
Open a tracked ticket with an owner. The OWASP guidance recommends regular status updates, even when you have no firm fix date, so the reporter knows the issue has not been dropped. CISA's directive sets a resolution target of ninety days from receipt, with room for complex cases.
Ask the reporter to retest if they are willing, and make it a clear and reasonable request.
Close out
Step 5: Close and credit
Confirm the fix to the reporter. If you publish an advisory, credit them unless they ask you not to. If you have no bounty, credit, thanks or a hall of fame are still real rewards, according to the OWASP guidance.
Step 6: Look back
BOD 20-01 asks agencies to assess past impact for each report. Do the same: check logs for earlier exploitation, and ask whether the same flaw exists elsewhere in the code.
A one page tracker
Keep a spreadsheet with these columns: date received, reporter contact, summary, scope decision, severity, owner, date acknowledged, date assessed, fix date, advisory link. If a report goes quiet for more than a week, the sheet makes it obvious.
Quick check
Do we have to pay for reports?
No. Many organisations run a disclosure policy with no payment. The OWASP guidance suggests credit, swag or a hall of fame as alternatives, and warns to be wary of anyone demanding payment before sharing details.
What if the report is wrong?
Say so, politely, with your evidence. A clear "we could not reproduce this, here is what we tried" keeps the relationship intact.
For the dependency side of triage, Safeguard's reachability analysis can show whether a vulnerable library is actually called by your code, which helps with the "how bad is it for us" question.
Sources
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
- OWASP Vulnerability Disclosure Cheat Sheet
Last reviewed: 19 October 2026.
