Reply to every report, even duplicates, invalid claims and out of scope targets. Say what you decided and why, in a few plain sentences. CISA's directive asks agencies to define how out of scope reports are handled, and OWASP says to stay professional and keep reporters informed.
A decision order
Run each report through the same questions, in order.
- Is it a security issue at all? Missing headers on a static page, or a feature working as designed, may not be.
- Can we reproduce it? If not, ask for more detail before rejecting.
- Is it in scope? Check your policy.
- Is it a duplicate? Check your tracker, including closed items.
- If real, rate it and fix it.
Keeping the order fixed makes decisions consistent between triagers.
Sample replies
Sample reply: needs more information
"Thanks for your report. We could not reproduce the behaviour with the steps given. Could you tell us the exact URL, the account type used, and the time of testing? We will look again as soon as we hear back."
OWASP says to ask for clarification when a report lacks the detail needed to verify it.
Sample reply: invalid
"Thank you for the report. We looked at the behaviour you described. It is working as designed, because the data shown is visible to every signed in user by intent. If you believe a different case is affected, please send the steps and we will review them."
State the reason. A bare "not a vulnerability" invites arguments and public posts.
Sample reply: out of scope
"Thank you. The system you tested is outside the scope listed in our policy, so we will not treat this as an eligible report. We forwarded it to the owner we know of, and we recommend you also contact them directly."
Where you can, route it. BOD 20-01 asks agencies to describe how out of scope reports are handled, so decide your rule in advance rather than case by case.
Sample reply: duplicate
"Thanks for reporting. We already received a report of this issue on an earlier date, and a fix is in progress. We will credit the first reporter. We appreciate you taking the time, and we welcome other findings."
Do not share the earlier reporter's identity. Credit rules should be in your policy.
Handling junk volume
The OWASP guidance notes that smaller organisations can struggle with triage volume and junk reports, and suggests a managed triage service as one option. Before that, try these steps:
- A structured intake form that asks for impact and steps.
- A list of commonly rejected findings in your policy, such as missing security headers with no demonstrated impact, so reporters can self check.
- Templates for the four replies above.
Watch for pressure
Be wary of anyone demanding payment before sharing details. OWASP suggests redirecting such reporters to a mediated platform. Stay calm, repeat the policy, and do not engage in threats either way.
Track the outcome
Add a status field to your tracker: valid, invalid, out of scope, duplicate. Review counts each quarter. A high rate of out of scope reports means your scope text is unclear. A high rate of invalid ones means your policy should list non issues.
Quick check
Should duplicates get credit?
Usually the first valid reporter gets credit. Thank the others, since their report confirms the issue is easy to find.
How long can we take to reply?
State your own target. CISA's suggested figure for agencies is acknowledgment within three business days of receipt.
Sources
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
- OWASP Vulnerability Disclosure Cheat Sheet
Last reviewed: 19 October 2026.
