If someone reports a security vulnerability in your application/infrastructure — whether a security researcher, a concerned user, or an automated bug bounty submission — how you respond matters significantly. This guide covers a sound response process.
Why Response Process Matters
A poor response (ignoring reports, being hostile to reporters, taking excessive time) discourages responsible disclosure and can lead researchers toward public disclosure without giving you time to fix the issue first — a good process encourages continued responsible reporting and protects you and your users.
Step 1 — Acknowledge Receipt Promptly
Respond quickly (within a day or two at most) simply confirming you've received the report and are looking into it — even before you've fully assessed the issue, prompt acknowledgment shows the reporter their effort is being taken seriously.
Step 2 — Assess the Report's Validity and Severity
Attempt to reproduce/verify the reported issue — not every report is accurate or exploitable as described; assess genuinely, neither dismissing valid concerns nor overreacting to non-issues.
Step 3 — Communicate Your Assessment and Timeline
Once assessed, communicate back: whether you've confirmed the issue, its severity, and a reasonable timeline for remediation — researchers generally understand that fixes take time, but appreciate honest, concrete communication over silence.
Step 4 — Prioritize and Remediate
Address the vulnerability with urgency appropriate to its actual severity — a critical, actively exploitable issue warrants immediate attention; a lower-severity theoretical issue can follow a more normal prioritization process.
Step 5 — Verify the Fix Actually Resolves the Issue
Before considering the matter closed, verify your fix genuinely addresses the reported vulnerability — ideally by attempting to reproduce the original issue against the patched system.
Step 6 — Communicate Resolution to the Reporter
Let the reporter know the issue has been addressed — this closes the loop respectfully and maintains a positive relationship for any future reports.
Step 7 — Consider Coordinated Disclosure Timing
If the reporter intends to publicly disclose (common practice among security researchers after a reasonable remediation period), coordinate timing so public disclosure happens after your fix is deployed, not before — most researchers are willing to coordinate reasonably if you're being responsive.
Setting Up a Clear Reporting Channel in Advance
Having a clear, documented way for researchers to report issues (a dedicated security contact email, a documented disclosure policy) makes it more likely reports reach you promptly and through an appropriate channel, rather than researchers being uncertain how to responsibly report or defaulting to public disclosure.
Consider a Bug Bounty Program (If Appropriate for Your Scale)
For organizations with sufficient scale/resources, a formal bug bounty program incentivizes and structures responsible disclosure — not necessary or appropriate for every organization, but worth considering as your application/user base grows.
What Not to Do
- Don't threaten legal action against good-faith researchers reporting responsibly
- Don't ignore reports hoping they'll go away
- Don't publicly dismiss a report without genuine investigation
Documenting the Incident Internally
Treat significant vulnerability reports similarly to How to Write an Effective Incident Postmortem — document what happened, how it was addressed, and what process improvements might prevent similar issues going forward.
Continue Reading
- How to Handle a Data Breach: An Incident Response Framework
- How to Write an Effective Incident Postmortem
- Understanding and Mitigating the OWASP Top 10 Vulnerabilities
Browse more articles in Advanced Security & Compliance.
