How to respond to a security researcher who reports a vulnerability

By Kike Gandia · Co-Founder & CEO, OSCP

You get an email from a security researcher saying they found a vulnerability in your system. What do you do? How you respond in the next few hours will determine whether the incident gets resolved professionally or turns into a reputational problem. This practical guide covers the exact steps you should follow.

Why the first response matters so much

Security researchers share their experiences with the community. A hostile, slow or evasive response can push a researcher to disclose the vulnerability publicly before you've patched it. A professional, agile response builds a trust relationship that can turn the researcher into an ally.

The cost of responding badly

Ignoring the report, replying with legal threats, or taking weeks to acknowledge it are mistakes that researchers document and share. There are documented cases of companies that lost valuable researchers and suffered premature disclosures because they mishandled the initial communication.

What to do in the first 4 hours

Send an initial response within 4 hours during business days. The message should confirm you've received the report, that you're evaluating it, and that you'll get back to the researcher within a set timeframe (usually 5-10 business days). Include: contact name, ticket reference number, estimated timeline for the technical response, and confidentiality confirmation. Don't promise anything about payment or severity yet. Never threaten legal action or ignore the report.

Technical evaluation and communication process

Reproduce the issue in a controlled environment, assess severity using CVSS, determine the real impact, and prioritize the fix. Keep the researcher informed of progress. The industry standard is a 90-day window from notification to public disclosure (coordinated disclosure). If you need more time, negotiate with the researcher — most accept reasonable extensions if the communication is transparent.

Coordinating disclosure and crediting the researcher

If the vulnerability is significant, coordinate the date and format of public disclosure with the researcher. Offer them credit in the security advisory. Public recognition is one of the biggest incentives for researchers and turns the experience into positive publicity for your company.

When and how to offer a reward

If you have a bug bounty program, the reward should be assigned according to your severity tables. If you don't have a formal program, consider whether the vulnerability deserves financial recognition. Even a small payment can make a real difference in your relationship with the researcher.

FAQ

What do I do if the researcher has no proof of exploitation, just a description of the vulnerability?

Evaluate the report on its technical merits. The discovery method (passive vs active) can affect legal considerations, but in many cases researchers find vulnerabilities through perfectly legal techniques (code analysis, controlled fuzzing, review of public APIs). Consult your legal team before making decisions based on the discovery method.

Am I legally required to respond to vulnerability reports?

Under NIS2, if you're an operator of essential or important services, you must have a vulnerability management process. Under the CRA, if you manufacture digital products, you must have a reporting channel. In both cases, ignoring reports can amount to regulatory non-compliance.

What happens if the researcher discloses the vulnerability without giving me time to patch it?

If you've responded professionally and the researcher discloses before the agreed deadline (or without ever agreeing one), your options are limited, but documenting the communication protects you reputationally. If the disclosure happened with no prior contact with you at all, consult your legal team — though the options are usually limited.

Sources

We design the security-researcher response process for your company