Response times to promise security researchers, and which to skip

Promise three things: an acknowledgement, a first assessment and regular updates. Skip promised fix dates. Pick numbers you can meet with your smallest on-call week, publish them in your disclosure policy and measure against them. A missed public promise damages trust faster than a slower honest one.

What researchers want

Researchers mostly want to know the report arrived, that a person read it, and that they will hear back. Silence is what pushes people toward public posts. See what to do when a researcher goes public before your fix for that scenario.

The commitments worth making

Acknowledgement. A short reply confirming receipt. An automatic reply plus a human one within a few business days is reasonable for a small team.

Triage outcome. Tell them whether you can reproduce the issue, need more information, or consider it out of scope. Choose a window such as 10 business days, then match it to your capacity.

Status updates. A regular note, for example every two weeks, even if the message is "still working on it".

Closure. Tell the reporter when it is fixed, and whether and how you will credit them.

The commitment to skip

A fix date. Fix time depends on severity, release trains, upstream dependencies and testing. If you promise 30 days and the fix needs 60, the reporter hears a broken promise. Instead, promise to communicate and to share a target once you have one.

How to set the numbers

1. Count how many reports you got in the last year.
2. Look at how long each step actually took.
3. Take the slowest normal case, not the average.
4. Round up, and add a holiday buffer.

If you cannot staff a number, publish a longer one. You can tighten it later with pride.

Track and report

Keep a simple sheet: received date, acknowledged date, triage date, last update, closed date. Review it quarterly. If you miss targets two quarters in a row, change the staffing or the promise.

Quick check

Last reviewed: 19 October 2026.