Reply quickly with a short, human acknowledgement: thank the reporter, confirm you received the report, name one owner, say what happens next, and state when they will hear from you again. Do not argue severity, promise a fix date, or ask the reporter to sign anything in the first message.
Why the first reply matters
The first message sets the tone for the whole case. A reporter who hears nothing may assume the report went into a void. The CERT Guide to Coordinated Vulnerability Disclosure describes a process that starts with reporting and moves to validation and prioritization, and the reporter is a participant in that chain, not a bystander. If your intake is silent, the reporter has little reason to stay inside the process.
An acknowledgement is not an admission that the report is correct. It only says a person has seen it.
What a good first reply contains
Keep it to a few lines. Include:
- A thank you, in plain words.
- Confirmation that you received the report and the date you received it.
- The name or role of the person who owns the case.
- What you will do next, for example reproduce the issue.
- A date by which you will write again, even if you have no news.
- A request for anything missing: affected version, steps, proof of concept, and how they would like to be credited.
What to leave out
| Leave out | Why |
|---|---|
| A severity verdict | You have not reproduced it yet |
| A fix date | You do not know the scope of the fix |
| Requests to keep quiet forever | An open ended silence is not a fair ask |
| Blame or doubt about the reporter's motives | It damages trust before you have facts |
| Any mention of payment unless your policy offers it | Set expectations from your published policy |
If your policy states a response target, follow it. If you do not have one, pick a target you can meet on a bad week and publish that, rather than one that sounds impressive.
A short template
Thanks for reporting this. We received your message on the date above and Priya is looking at it. We will try to reproduce it and write back by Friday with what we found, or with an update if we are still working. If you have a version number, a proof of concept, or a preferred credit name, please send them. We will not share your report outside the security team.
Adjust the names and dates, and keep your own voice.
Try it yourself
Open the vulnerability management demo to see how an incoming finding becomes a tracked item with an owner and a status. Look at how each item carries its state, because your report tracker needs the same fields.
Click through it at your own pace, or open it full screen.
After you reply
Log the report in your tracker the same day, with the received date, the owner and the next promised update. Then move to validation. The related posts on disclosure intake and the six phases of coordinated disclosure cover the steps on either side of this one.
Safeguard can help with the part that comes after validation, since its dependency scanning and reachability analysis show whether a reported weakness sits in a library you ship. You can try the free scan at gold.safeguard.sh/scan.
Quick check
Should we reply to a report we think is wrong?
Yes. Acknowledge it, then say you could not reproduce it and ask for more detail. Silence turns a mistaken report into a public complaint.
Do we need a response deadline in our policy?
It helps. A stated target gives reporters something to hold you to and gives your team a clear rule. Choose one you can keep.
Sources
Last reviewed: 19 October 2026.
