An email arrives from someone you have never heard of. It says they found a vulnerability in your product, includes a screenshot, and asks who to send the details to.
What happens in the next twenty-four hours decides whether this becomes a fixed bug and a useful relationship, or a public disclosure with a thread about how badly you handled it. Most companies get it wrong in the first reply.
This post is the operational playbook for receiving a report. Writing the policy is a separate exercise; this is what to do when one lands and you have not written one yet. For whoever the email reaches, which is often support or sales.
The first hour
Acknowledge within hours, not days. A short human reply, before you have assessed anything:
Thanks for this. We take it seriously and are looking now. I will come back to you within two working days with an initial assessment, and sooner if I have questions. Who should I credit if this is confirmed?
That message does four jobs: a human is engaged, a timeline exists, questions are invited, and credit is on the table. Most researcher frustration comes from silence, not from disagreement.
Route it to someone technical immediately. These arrive at support@, info@, and via LinkedIn to whoever looks senior. If your front line does not know where to send it, that is the first thing to fix, and it costs one line in their runbook.
Do not ask them to sign anything yet. An NDA as the opening move reads as an attempt to suppress, and researchers discuss it publicly. There may be a place for an agreement later; it is not the first reply.
Never respond with legal language. The single most reliable way to convert a cooperative researcher into an adversarial one, and it makes the news. If your instinct or your lawyer's is to send a warning about unauthorised access, pause and get a second opinion from someone who has handled disclosures before.
Triage
Reproduce before judging. Not from the description, from the steps. A surprising share of reports are real but described confusingly, and a smaller share are misunderstandings of intended behaviour.
If you cannot reproduce it, say so specifically and ask. "I tried X on version Y and saw Z. Can you tell me what I am doing differently?" Researchers generally respond well to this, because it shows genuine engagement. "We could not reproduce it" with no detail reads as a brush-off.
Assess severity in your own context, and share the reasoning. If they rated it critical and you think it is medium because the affected endpoint is internal-only, say that, with the mechanism. They may know something you do not: that the endpoint is reachable in a configuration you forgot about.
Check whether it generalises. One instance of an issue is often a pattern. A researcher who found IDOR on one endpoint has told you about your authorization model, not about that endpoint, and fixing only what they reported means the next person finds the next one.
Communication while you fix
The cadence matters more than the speed.
Set a date and keep it. Ninety days is the widely understood default for coordinated disclosure. If you need longer, ask, with a reason and a specific new date. Researchers usually grant extensions to teams communicating honestly, and almost never to teams that have gone quiet.
Update them even when nothing has changed. "Still working on it, fix is in review, expect it deployed by the 14th" costs a minute and prevents the assumption that you have stopped caring, which is the assumption that precedes an early disclosure.
Tell them when it ships, and let them verify. They found it; they are the best person to confirm the fix is complete. This step catches partial fixes surprisingly often.
Credit them, in the form they want. Ask whether they want to be named, and where. A security advisory, a release note, a hall of fame page. It costs nothing and it is most of what many researchers are working for.
Money
If you have no bounty programme, say so early and plainly. "We do not currently pay bounties" is a fine answer given at the start. What damages you is discovering it after the work, or implying payment and then negotiating it down.
If a report arrives with a payment demand before details, that is a different situation. Ask for a description of the class of issue without exploitation details, involve your legal team, and be aware that a demand with a deadline and no disclosure intent looks less like research and more like extortion. Most reports are not this. Some are.
The two artifacts to have ready
Both are small and both save the whole conversation from being improvised.
A security.txt file at /.well-known/security.txt, giving a contact address and your policy link. It is a five-line file and it means a researcher does not have to guess where to send it, which is the step where reports get lost or end up on social media.
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00.000Z
Policy: https://example.com/security/disclosure
Preferred-Languages: en
A monitored inbox with an owner. security@ forwarding to a person, with a documented response expectation. An address that nobody reads is worse than no address, because a researcher who gets no reply has done their part and is now free to publish.
The concession
Handling this well takes time you have not budgeted, from people already busy, for a bug you did not plan to fix this sprint. There is a real argument that a small team should not invite the traffic at all.
That argument loses to one fact: the reports arrive whether or not you invite them, and the only variable you control is whether there is a path. Without one they reach a salesperson, or a public post. A monitored inbox and a two-day acknowledgement are the minimum viable version, and they are genuinely most of the value.
The implication
A researcher who contacts you is doing you a favour, usually unpaid, and has already chosen coordination over publication. That choice is reversible, and the first reply is where it gets reconsidered.
Answer quickly, engage with the technical detail, commit to a date, keep it, and give credit. Everything else, including the policy document, is refinement on top of that.
