Bug Bounty Response Templates: Copy-Paste Replies for Program Teams

Silence, terse closures, and the feeling that nobody read the report frustrate researchers more than bounty amounts do. Good response copy fixes a surprising amount of that at almost no cost. A verdict that references their work, names a reason, and points to a next step lands completely differently from a one-word status change, and it costs you a couple of sentences.

Below are the templates we actually reach for, grouped by verdict. Copy them, swap the bracketed fields, and keep your own voice. Two rules that make all of them work: be specific (report IDs, field names, versions, never "we've reviewed this") and never sound like a form letter even when you're using one. The researcher can tell.

For the reasoning behind these verdicts (when something is a duplicate, what actually makes a finding Informative), see the triage workflow and severity guide. This page is the wording; those are the judgement.

First response / acknowledgement

When: Immediately on receipt, before you've fully triaged. This is the single highest-leverage message you send: it's what your response-time SLA is measured on, and it sets the tone for everything after.

Tone: Warm, brief, no commitments on outcome or severity yet. You're confirming a human has it, not pre-judging.

Thanks for the report, and for taking the time to write it up clearly.

We've received this and it's in our triage queue. A triager will
validate and reproduce it, and you'll hear back with a status and any
questions within [X business days per our policy].

If anything material changes on your end (new impact, a working
exploit chain, or you realise it's a dupe of your own earlier report),
reply here and we'll factor it in.

Needs more info

When: The report is plausible but you can't reproduce it as written, or a key detail is missing. Ask for exactly what you need, not "more details."

Tone: Collaborative, specific, no blame. The reporter isn't a suspect; they're a partner who left out a step.

This looks promising but we can't reproduce it yet, and we'd rather get
it right than guess.

Could you provide:
- [The full HTTP request that triggers it, headers included]
- [Which account/role you were authenticated as]
- [A step we're missing, e.g. does this need a pre-existing X?]

Once we can reproduce on our side we'll move it forward. The report
stays open and your submission timestamp is unaffected while we sort
this out.

The last line matters more than it looks: researchers worry that a needs-info round resets their priority or lets a duplicate slip in front of them. Reassure them it doesn't.

Duplicate verdict

When: The finding shares a root cause with an earlier report, meaning one fix resolves both. Not "same endpoint" or "same class"; same broken thing.

Tone: Respectful and evidence-backed. Duplicate is the verdict researchers distrust most, because some programs have abused it. Carry proof.

Thanks. This is a valid issue, but it duplicates [#1204], reported
[2026-01-18].

Both findings stem from [the missing tenant scope in the shared
authorization middleware]; the fix for [#1204] resolves this path as
well. Current status of the original: [triaged, fix in progress].

We know a dupe verdict is a letdown when the work was real. It was.
If you believe there's a distinct root cause or novel impact here that
the original doesn't cover, point us to it and we'll re-open.

Always reference the original concretely and name the shared root cause. If part of their report is genuinely novel (new impact on top of a known bug), split that out and reward it rather than closing the whole thing. More on getting this right in our duplicates deep dive.

Informative verdict

When: The report describes something real but not independently actionable or impactful: best-practice deviations, self-XSS with no chain, missing headers with no demonstrated exploit, verbose errors that leak nothing sensitive.

Tone: Appreciative but clear on the "no bounty, no fix ticket" outcome. Explain why it doesn't clear the bar without dismissing the observation.

Thanks for flagging this. We're marking it Informative.

We agree [the X header is missing / this behaviour isn't ideal], but on
its own it doesn't have a demonstrable security impact in our
environment: [reason, e.g. the endpoint requires auth and the value it
reflects isn't sensitive / this is self-XSS with no delivery vector].

If you can chain it into something with concrete impact, [e.g. a way
for an attacker to trigger this against another user], we'll happily
re-assess as a new submission. Genuinely appreciate the eyes on this.

Not applicable (N/A) verdict

When: The report doesn't describe a real vulnerability: sanitised output mistaken for XSS, intended behaviour, out-of-scope asset, or a scanner result that isn't reproducible.

Tone: Factual and kind. N/A means "you were mistaken," which stings; the specific reason is what keeps it from feeling like a brush-off.

We've reviewed this and we're closing it as Not Applicable, with the
reasoning so you can check our work.

[The payload appears in the response HTML-encoded (`<script>`),
so it doesn't execute: the output encoding is working as intended.]

We reproduced [your exact request] and confirmed [the encoded output /
the 403 / the intended behaviour]. If you're seeing something different
on your end, send the raw response you got and we'll take another look.

Offering to look again if they have contradicting evidence is what separates a defensible N/A from a dismissive one. It also filters the genuinely-mistaken from the genuinely-onto-something.

Severity downgrade explanation

When: The finding is valid but rated lower than the reporter claimed: self-contained instead of cross-tenant, non-enumerable IDs, reflected instead of stored.

Tone: Transparent about the mechanism. Researchers accept downgrades when the reasoning is checkable; they escalate when it feels arbitrary.

This is a valid finding. Thank you. We're rating it [Medium] rather
than [Critical], and here's the reasoning:

[The IDOR is confirmed, but the object identifier is a random UUID, not
enumerable, so an attacker needs a known reference rather than being
able to walk the dataset. Impact is per-known-object, not bulk.]

Our severity model weighs [enumerability and data sensitivity] here.
If you can show [the IDs are obtainable in bulk / the object holds more
sensitive data than we assessed], that changes the rating and we'll
adjust. Bounty will be issued at the [Medium] tier per the table.

Tie the number to a named factor and to your published rubric. "We're rating it Medium because of enumerability" invites a factual counter; "we're rating it Medium" invites a fight.

Bounty award note

When: Paying out. Close the loop with a note, not just a status flip. This is the message that makes researchers come back.

Tone: Genuine appreciation, concrete on what happens next.

Confirmed and rewarded: [Bounty amount] at the [High] tier for [a
clear description of the impact, e.g. cross-tenant read of customer
PII via enumerable invoice IDs].

Nice find, and a clean write-up made triage fast, which we appreciate.
The fix is [tracked as / already deployed]. You're welcome to [request
disclosure / retest once the fix ships]; ping us here for retest.

Thanks for making the product safer. Hope to see you back.

A note on using templates well

Templates save time and keep tone consistent across a team, but a template pasted with the brackets still in it is worse than no template. The fields aren't optional: the report ID, the specific reason, the named severity factor are the entire value. A well-run intake process, in-house or outsourced, uses these as scaffolding for a specific reply, never as a substitute for reading the report.

Consistent, specific responses are most of what researchers mean by "a program worth submitting to," and they're the hardest thing to keep up when the queue spikes. TRIAGERS™' on-demand triage teams handle validation and researcher comms in your program's voice, so every reply lands like these do. If your response times or tone need backup, get in touch.