When a customer reports a possible vulnerability, acknowledge it quickly, move it out of the general support queue, assign one owner, reproduce it, decide severity, and keep the reporter updated until it is fixed. The first day matters most, because that is when trust is won or lost. Here is a sequence an engineering manager can follow.
Step 1: acknowledge within a day
Reply in plain words: you received it, someone is looking, and when they will hear next. Do not argue about whether it is a vulnerability, and do not ask the reporter to stay quiet. Thank them. If you have a disclosure policy, point to it. If you do not, write one soon; a short security page with a contact is a good start.
Step 2: move it to a private channel
A report can contain details that would help an attacker. Make a restricted ticket or thread, and limit access to the people who need it. Ask support staff not to discuss it in shared channels or public tickets.
Step 3: assign one owner
Name a single person responsible for driving it to closure. That person coordinates, but need not fix the code. Having one named owner prevents the common failure where everyone assumes someone else replied.
Step 4: reproduce
Try to reproduce using the reporter's steps in a safe environment, never against another customer's data. If you cannot, ask for more detail rather than dismissing it. Record what you did and what you saw.
Step 5: decide severity and scope
Ask what an attacker gains, what they need to start, and how many customers could be affected. Check whether the problem exists elsewhere in the code. Often the same mistake appears in several places. If it involves a dependency, check whether the vulnerable function is reachable in your product; the demo below shows one way to judge exploitability.
Try it yourself
Click through it at your own pace, or open it full screen.
Step 6: fix and verify
Schedule the fix based on severity, and pull in the right people. Add a test that fails before the fix and passes after. Confirm with the reporter if they offer to retest. Many are glad to.
Step 7: keep the reporter informed
Send brief updates at agreed points, even if the update is that work is ongoing. Tell them when the fix ships. Ask how they would like to be credited, and respect a request for none.
Step 8: decide on customer communication
If customers need to act, such as rotating a key or updating a client, write clear instructions. If data may have been exposed, involve legal counsel early, since notification duties depend on your contracts and the jurisdictions you operate in. Do not guess at the rules.
Step 9: learn from it
After the fix, run a short review: how was it introduced, why did tests miss it, what class of issue is it? Add a check if a pattern emerges.
Quick check
Should support respond to a vulnerability report?
Support can acknowledge and route, but the substantive response and updates should come from the named owner in a private channel.
What if the report turns out not to be a vulnerability?
Explain why, politely and specifically, and keep the door open. Reporters who feel respected come back with real findings.
Last reviewed: 19 October 2026.
