What Is Responsible Disclosure?

A security researcher finds a serious vulnerability in your product. What happens next depends entirely on one decision: how they choose to tell you about it. They could publish it immediately, with no warning, exposing your users to a known, unpatched risk the moment the post goes live. They could sell it to someone who wants to exploit it. Or they could quietly notify your security team, give you time to fix it, and only go public once a patch is in place and your users are protected.

That third path is responsible disclosure. It is not a law, and it is not automatic. It is a practice, a set of norms that the security research community has developed over decades to balance two goals that are genuinely in tension: the public’s right to know about security risks, and an organization’s need for enough time to fix a problem before attackers can exploit it.

This post explains what responsible disclosure actually means, how it differs from the other ways a vulnerability can become public, and what both researchers and organizations need to understand to make the process work the way it is supposed to.

Key Takeaways

• Responsible disclosure is the practice of privately reporting a vulnerability to the affected organization and giving them a reasonable window to fix it before any public disclosure occurs.
• It sits between two less desirable alternatives: full disclosure, where the vulnerability is published immediately with no warning, and non-disclosure, where the finding is never reported at all.
• The standard coordination window in the security research community is 90 days, though the right timeline depends on severity, complexity, and how responsive the organization is.
• Responsible disclosure works reliably only when an organization has a formal channel, typically a Vulnerability Disclosure Program, that gives researchers legal safe harbor and a defined process to report into.
• In Bugstrix engagements, organizations that treat inbound disclosure reports with the same urgency as internally discovered findings build stronger researcher relationships and consistently close vulnerabilities faster than those that do not.

What Is Responsible Disclosure?

Responsible disclosure is the practice of a security researcher privately notifying an organization about a vulnerability they have discovered, giving that organization a reasonable period of time to investigate and fix the issue, and only disclosing the finding publicly after a fix is available or an agreed timeframe has passed.

The principle behind responsible disclosure is straightforward: publishing a vulnerability the moment it is found gives attackers the same information defenders have, before defenders have had any chance to act on it. Sitting on the finding forever and never telling anyone leaves the vulnerability in place indefinitely with no path to a fix. Responsible disclosure is the middle path that gets the finding fixed without handing attackers a head start.

The term is sometimes used interchangeably with “coordinated disclosure,” and in practice the two describe the same underlying behavior. Coordinated disclosure emphasizes that both the researcher and the organization actively coordinate the timeline together, rather than the researcher simply waiting on the organization’s schedule. Either term describes the same practical outcome: private notification first, public disclosure later, on a timeline both parties understand.

Responsible disclosure is a practice, not a legal requirement. Nothing obligates a researcher to follow it. It exists because the research community broadly recognizes that it produces better outcomes than the alternatives, and because organizations that engage constructively with researchers following this practice build the kind of relationship that keeps future findings coming through the same private channel.

What Are the Three Disclosure Models?

Every vulnerability a researcher finds eventually falls into one of three disclosure models: full disclosure, responsible (coordinated) disclosure, or non-disclosure. Understanding all three, not just responsible disclosure in isolation, is what makes it clear why the middle path is the one most of the security community has converged on.

Full disclosure means the researcher publishes the vulnerability publicly the moment they find it, or shortly after, with no advance private notice to the organization. The argument in favor of full disclosure is that it forces organizations to act, since public pressure and reputational risk motivate a fix faster than a private report that can be quietly ignored. The argument against it is that it gives attackers the exact same information at the exact same moment, before any patch exists, leaving every user of the affected system exposed for as long as remediation takes.

Non-disclosure means the vulnerability is never reported to anyone. The researcher either keeps the finding private for their own reasons, sells it, or simply does not bother reporting it. This is the outcome that responsible disclosure is specifically designed to prevent, because a vulnerability that nobody official knows about cannot be fixed, and it remains exploitable by anyone who independently discovers it, including threat actors who have no intention of reporting it either.

Responsible disclosure sits between the two. The researcher reports privately, the organization gets time to fix the problem, and public disclosure happens on a coordinated timeline, after the fix ships or after an agreed window closes, whichever comes first. This is the model that the majority of professional security researchers default to, and it is the model that most organizations should be actively building the infrastructure to support.

How Does the Responsible Disclosure Process Actually Work?

A responsible disclosure engagement moves through five stages from the moment a researcher finds a vulnerability to the moment it becomes public knowledge. Each stage has expectations attached to it, on both sides, that determine whether the process functions smoothly or breaks down into frustration and premature disclosure.

Discovery. The researcher identifies a vulnerability, either through independent research, participation in a bug bounty or VDP, or incidental discovery while using the product. At this stage, the researcher typically documents the finding in enough detail to demonstrate it is real: reproduction steps, evidence, and an initial severity assessment.

Private notification. The researcher reports the finding through whatever channel the organization provides, ideally a published disclosure policy with a defined submission process, though in the absence of one, researchers often resort to a generic security contact, a support form, or occasionally a direct message on social media when nothing more formal exists. The quality and speed of what happens from this point forward depends heavily on whether a proper channel exists.

Coordination window. The organization investigates, validates, and works on a fix, while the researcher agrees not to publish during this period. The widely recognized standard is 90 days, a convention popularized by major technology companies and security research groups, though the actual right length depends on the complexity of the fix and how responsive the organization is proving to be. A researcher who sees genuine progress is usually willing to extend the window. A researcher who is met with silence is not.

Fix and verification. The organization deploys a patch or mitigation, and ideally confirms with the researcher that the fix actually resolves the reported issue. Skipping this verification step is a common and avoidable mistake: fixes that address the symptom but not the root cause sometimes leave the vulnerability exploitable through a slightly different path, which the original researcher is well positioned to catch before public disclosure if given the chance to retest.

Public disclosure. Once the fix is live, or the coordination window closes without one, the finding can be published. In a well-run process, this stage is a formality that both sides have already agreed to, often including public credit to the researcher and, for organizations running paid programs, public acknowledgment through a security advisory. Our post on bug bounty program covers how organizations formalize this final stage, including researcher recognition, as part of a structured paid program.

Responsible Disclosure vs. Vulnerability Disclosure Program

Responsible disclosure is a practice. A Vulnerability Disclosure Program is the organizational infrastructure that makes that practice possible to follow reliably. The distinction matters because an organization cannot simply ask researchers to “please disclose responsibly” and expect the process to work without building the channel that supports it.

A researcher who wants to follow responsible disclosure norms but finds no published policy, no defined scope, and no legal safe harbor commitment from an organization is left improvising. They have to guess where to send the report, whether the organization will respond constructively or defensively, and whether reporting at all creates legal exposure for them personally. Some researchers proceed anyway. Many do not, and the finding either goes unreported or, in the more concerning case, gets published without any private notice because the researcher saw no safe alternative.

A VDP removes that improvisation. It is the published policy that defines scope, provides safe harbor, specifies the submission process, and commits the organization to a response timeline, which is exactly the infrastructure that turns responsible disclosure from a hopeful default into a reliable, repeatable process. Our complete guide to Vulnerability Disclosure Program covers what a VDP policy should include and how to build the internal triage process behind it.

Organizations that want to go further than a VDP by paying researchers for valid findings run bug bounty programs, which layer financial incentives on top of the same disclosure infrastructure. Our bug bounty service is structured for organizations ready to move from an unpaid disclosure channel to a managed, incentivized research program.

What Should Researchers Expect From a Responsible Organization?

A researcher following responsible disclosure practices should reasonably expect three things from the organization they report to: timely acknowledgment, genuine engagement during the coordination window, and public credit once the finding is resolved. When organizations fail to deliver on these expectations, they are the ones most likely to push researchers toward full disclosure on future findings.

Timely acknowledgment. A response within 24 to 72 hours confirming the report was received is the baseline expectation in the research community. Silence in the early days of a report is the single most common reason researchers lose confidence in an organization’s process and consider going public early.

Genuine engagement. Researchers do not expect instant fixes, but they do expect visible progress: confirmation that the finding was validated, an understanding of the remediation timeline, and responsiveness to follow-up questions. An organization that goes quiet for weeks after the initial acknowledgment signals that the report has stalled, which is exactly the situation that erodes a researcher’s willingness to keep waiting.

Public credit. Once a finding is resolved and disclosed, acknowledging the researcher publicly, whether through a security advisory, a hall-of-fame page, or a direct mention, costs the organization nothing and builds the kind of reputation in the research community that attracts more, and better, future reports.

What Should Organizations Do to Support Responsible Disclosure?

Organizations that want researchers to follow responsible disclosure practices need to actively build the conditions that make it possible, rather than assuming good intentions from researchers will compensate for the absence of a real process.

Publish a disclosure policy with safe harbor. The specifics of what this policy should include are covered in depth elsewhere. The practical point worth emphasizing here: this is the single highest-leverage step available, because every other item on this list only matters to researchers who feel safe enough to report in the first place, and safe harbor is what creates that safety. 

Know your own attack surface. A disclosure policy is only as good as the organization’s ability to act on what it covers, and that requires knowing what systems actually exist. Organizations frequently discover, only after a researcher reports a finding, that the affected system was not on their own asset inventory. Continuous attack surface management service closes that gap, and our post on attack surface management explains how ongoing discovery keeps an organization’s understanding of its own exposure current.

Test proactively, rather than relying on disclosure alone. Responsible disclosure from external researchers is a valuable supplement to security testing, not a substitute for it. Organizations that run regular penetration testing and vulnerability assessments catch the majority of exploitable issues before an external researcher ever needs to report them, and they arrive at every disclosure conversation with a security team that already understands its own environment well enough to validate and act on reports quickly.

Build the internal response capability before publishing the policy. A disclosure policy that generates reports nobody is prepared to triage produces exactly the slow, disengaged responses that push researchers toward full disclosure. The internal process, ownership, triage workflow, and remediation tracking need to exist before the external-facing policy goes live.

Get a free quote for security services that support your disclosure process

What Happens When a Disclosure Suggests Prior Exploitation?

Most responsible disclosure reports describe a clean finding: a real vulnerability that the researcher discovered through their own testing, with no indication it has been used against the organization before. Occasionally, a report includes something more serious: a signal that the vulnerability may already have been exploited by someone else before the researcher ever found it and reported it responsibly.

This possibility changes the disclosure process itself. The standard 90-day coordination window assumes the organization has time to investigate calmly and ship a considered fix. A report suggesting prior exploitation does not afford that luxury, because the organization now has to determine, urgently, whether an actual breach has already occurred alongside the theoretical vulnerability the researcher reported. Indicators worth escalating immediately include evidence of unusual activity the researcher stumbled across that they did not cause themselves, log anomalies the organization finds while validating the report, or the researcher explicitly flagging signs of prior compromise in their submission.

The disclosure etiquette does not disappear under these conditions; it compresses. The organization still owes the researcher acknowledgment and, eventually, credit and closure, but the coordination timeline shifts from weeks to hours, and the internal workflow shifts from standard vulnerability triage to active incident response running in parallel with the disclosure conversation. Organizations that have never planned for this scenario often lose valuable time in the first hours simply deciding which process applies. Our post on what to do in the first 24 hours after a data breach covers the immediate steps to take once a disclosure report has crossed from “vulnerability” into “possible active incident.”

What Should Organizations Learn From a Pattern of Disclosure Reports?

A single disclosure report is a fix to make. A pattern across many disclosure reports, accumulated over months or years of running a disclosure channel, is a signal about where an organization’s development process itself has a gap. Most organizations treat each report as an isolated ticket and miss this second, more valuable layer of information sitting in their own disclosure history.

The pattern worth watching for is repetition: the same vulnerability class showing up across different reports, different researchers, and different parts of the product, months apart. Recurring authorization bypass reports in different features, for example, rarely mean the organization is simply unlucky. They usually mean the underlying access control pattern used across the codebase has a structural weakness that keeps reproducing itself in new code, and that no single bug fix actually addresses, because each report is being treated as its own isolated incident rather than as another instance of the same root cause.

Organizations that periodically review their disclosure history for these patterns, rather than closing each report and moving on, get a genuine feedback signal for their development process: which vulnerability classes their own review practices are consistently missing before code reaches production. Feeding that signal into secure development practices, rather than only into the immediate fix, is what actually reduces the volume of future disclosure reports rather than just resolving the current one. Our post on secure code review covers the practice that catches these patterns before external researchers need to find them at all.

What Makes a Disclosure Process Fail?

Most responsible disclosure processes that break down do so for a small, predictable set of reasons, nearly all of which are within the organization’s control to prevent.

Silence. No acknowledgment, no updates, no response to follow-up questions. This is the single most common cause of researchers abandoning coordination and going public early. A researcher who has invested real time in finding and documenting a vulnerability is not going to wait indefinitely for an organization that appears to be ignoring them.

Legal threats instead of engagement. Organizations that respond to a good-faith disclosure with legal threats, cease-and-desist letters, or accusations of unauthorized access, rather than with a safe harbor commitment and genuine engagement, poison their relationship with the entire research community, not just the individual researcher. Word travels fast in security research circles, and an organization known for hostile responses to disclosure sees fewer future reports as a direct consequence.

Scope disputes after the fact. An organization that only defines what is in scope after a researcher has already reported a finding, rather than publishing scope in advance, invites disputes that damage trust regardless of how the specific disagreement resolves.

Fixes that do not actually fix the problem. Patching the symptom without addressing the root cause, and then disclosing the finding as resolved without confirming with the original researcher that it is genuinely fixed, sometimes results in the same vulnerability being rediscovered and disclosed again, publicly, by a researcher who is understandably less patient the second time.

No public credit. Organizations that fix the vulnerability and disclose it without any acknowledgment of the researcher who found it are treating a professional contribution as an obligation-free favor. This does not necessarily break the specific engagement, but it consistently reduces the likelihood that the same researcher, or others who hear about it, report to that organization again.

Frequently Asked Questions

Is responsible disclosure legally required?

No. Responsible disclosure is a voluntary practice within the security research community, not a legal mandate. Some jurisdictions and industries are developing regulatory expectations around coordinated disclosure as part of broader security governance requirements, but no general law compels a researcher to disclose responsibly rather than publishing immediately or not reporting at all. The practice persists because it produces better outcomes for both researchers and organizations, not because it is required.

What happens if an organization ignores a responsible disclosure report?

Researchers vary in how long they wait before disclosing publicly regardless of organizational response, but sustained silence, typically well beyond the 90-day standard coordination window, is widely accepted within the research community as sufficient grounds for the researcher to publish without further private notice. An organization that ignores a report is effectively forfeiting the benefit of the coordination window it was given.

What should a researcher do if they disagree with the organization’s timeline?

Disagreement over timing is common and does not need to end in an ultimatum. A researcher who believes an organization is stalling has room to escalate gradually before resorting to publication: requesting a specific update with a concrete date, asking directly whether the delay reflects genuine remediation complexity or simple inattention, and, where a formal program exists, escalating through its defined process rather than going straight to a public post. Organizations, for their part, should treat a researcher asking pointed questions about the timeline as a legitimate signal to communicate more, not as a threat to manage defensively. Most disputes over the coordination window are resolved by better communication long before either side needs to consider walking away from it.

If there’s no payment involved, why do researchers bother reporting at all?

Money is one motivator among several, and for most researchers following responsible disclosure norms without a paid program attached, it is not the primary one. Professional reputation is a significant driver: a public credit on a disclosed finding, especially a serious one, is a genuine career asset in the security field. Some researchers are motivated by the technical challenge itself, treating a hard-to-find vulnerability as a puzzle worth solving independent of any reward. Others simply use the product or service in question and want it to be safer, which is often enough on its own. Organizations that assume unpaid disclosure only happens because researchers have nothing better to do tend to undervalue the relationship and, as a result, treat the reports it produces with less urgency than they deserve.

Can a researcher disclose a vulnerability without the organization’s permission?

Yes, and this is precisely the tension responsible disclosure is designed to manage rather than eliminate. A researcher is under no legal obligation to wait for an organization’s permission before publishing. Responsible disclosure works because researchers voluntarily choose to wait, in exchange for the organization engaging constructively and fixing the issue within a reasonable window. When that exchange breaks down, on either side, the researcher retains the option to disclose regardless of whether the organization has consented.

Trust Is the Infrastructure Responsible Disclosure Runs On

Responsible disclosure works because enough researchers choose to give organizations a chance to fix what they find before the world knows about it, and enough organizations honor that chance by actually fixing the problem and treating the researcher who found it with respect. Neither side is obligated to hold up their end. The practice survives entirely on the expectation that both sides usually will.

An organization’s job in this relationship is to make holding up that end of the bargain as easy as possible: a clear policy, a fast acknowledgment, genuine engagement during the fix, and public credit when it is done. Get those right, consistently, and the research community responds in kind, with more reports, better reports, and more patience when a fix takes longer than expected.

Get them wrong, and researchers stop waiting. They publish first, they report to journalists instead of security teams, or they simply stop reporting at all and keep what they find to themselves. None of those outcomes serve anyone, least of all the users the vulnerability actually puts at risk.

Contact us to discuss building a responsible disclosure process for your organization