Skip to main content
Oversight Institute
Category: Incident Management

Coordinated Disclosure

Also known as: CVD, Coordinated Vulnerability Disclosure, Responsible Disclosure
Simply put

Coordinated disclosure is a process in which someone who finds a security vulnerability reports it privately to the vendor or affected party and gives them time to fix it before the details are made public. This approach is intended to protect users by reducing the window during which a flaw is known but unremediated. It requires cooperation between the person who discovers the vulnerability and the organization responsible for addressing it.

Formal definition

Coordinated Vulnerability Disclosure (CVD) is a vulnerability disclosure model in which finders (such as security researchers) and the relevant stakeholders (typically the affected vendor, and in some cases a coordinating body such as CISA or a national CSIRT) work together to share information about a vulnerability, allowing time for remediation before the vulnerability is publicly disclosed. It is sometimes referred to as responsible disclosure, though the coordinated framing emphasizes multi-party cooperation rather than obligation. CVD governs the timing and communication of disclosure between the parties; it does not by itself guarantee that a fix is developed, deployed, or effective, and the specifics, such as disclosure timelines and coordinator roles, vary by policy, program, and jurisdiction. In the third-party and supply chain context, coordinated disclosure is a mechanism affecting how vulnerabilities in a supplier's products or services become known, but it is distinct from a supplier's internal patching, ongoing monitoring, or contractual notification obligations. Regulatory and policy expectations around CVD differ across regions (for example, EU-level guidance discussed by ENISA versus U.S. programs run by CISA).

Why it matters

For third-party and supply chain risk professionals, coordinated disclosure shapes how and when an organization learns that a vulnerability exists in a supplier's product or service. Because most organizations have limited visibility into the internal development and security practices of their vendors, the disclosure process is often one of the few structured channels through which flaws in externally sourced software or services become known. A well-functioning CVD process can shorten the window during which a vulnerability is known but unremediated, but it does not by itself confirm that a supplier has developed, deployed, or verified an effective fix. Those remain distinct from the disclosure event itself.

CVD is also important because the timing of public disclosure directly affects downstream exposure. When a vulnerability in a widely used supplier component becomes public before affected organizations have applied remediation, the disclosure can accelerate exploitation attempts across every organization that depends on that component. This is particularly relevant where a single supplier or component is embedded across many products, so a coordination breakdown at one vendor can propagate risk through multiple tiers of a supply chain. Coordinated disclosure governs communication and timing, but it does not substitute for a supplier's internal patching, ongoing monitoring, or contractual notification obligations, and gaps in any of these can leave residual exposure even when disclosure is handled well.

Because expectations around disclosure differ by policy, program, and jurisdiction, professionals should not assume a uniform standard. Programs such as CISA's Coordinated Vulnerability Disclosure Program in the United States and EU-level guidance discussed by ENISA reflect different regional approaches, and a supplier operating across regions may be subject to more than one set of expectations. Understanding whether and how a critical supplier participates in coordinated disclosure, and how it commits to notify customers, can be a meaningful input into vendor assessment, though it should be treated as one signal among several rather than a guarantee of security.

Who it's relevant to

Third-Party Risk and Vendor Management Teams
These teams can use a supplier's participation in coordinated disclosure, and its commitments around customer notification, as one input when assessing a vendor's security maturity. It is important to distinguish the existence of a disclosure policy from independent verification that vulnerabilities are actually remediated, and to recognize that disclosure practices do not by themselves cover a supplier's internal patching or contractual notification obligations.
Vulnerability and Patch Management Practitioners
Practitioners responsible for tracking and remediating vulnerabilities in externally sourced components rely on disclosure timing to plan their response. Because public disclosure can accelerate exploitation attempts, understanding when and how a supplier discloses is relevant to prioritizing remediation, though the disclosure event does not confirm that a fix has been deployed or is effective in a given environment.
Security Researchers and Finders
Researchers who discover vulnerabilities in supplier products are central participants in coordinated disclosure, reporting privately and cooperating with the vendor or a coordinating body before public release. The applicable expectations and timelines depend on the specific policy or program, and may differ where a coordinator such as CISA or a national CSIRT is involved.
Compliance and Policy Teams Operating Across Regions
Teams working across jurisdictions should account for differing regulatory and policy expectations around disclosure, for example, EU-level guidance discussed by ENISA versus U.S. programs run by CISA. A supplier active in multiple regions may face more than one set of expectations, and professionals should avoid treating any single regime as a global standard.

Inside CVD

Reporter Intake Channel
A defined, published method (such as a security.txt file, dedicated inbox, or disclosure portal) through which internal or external researchers can report suspected vulnerabilities. In a third-party context, this includes knowing whether a supplier maintains such a channel and how findings about the supplier's products or services are routed.
Triage and Validation
The process of confirming, reproducing, and assessing the severity of a reported issue before remediation. Validation typically distinguishes genuine vulnerabilities from false positives, though the depth and speed of triage vary by organization and are often opaque to outside parties relying on a vendor.
Remediation Window
The negotiated or policy-defined period between report and public disclosure during which the affected party is expected to develop and deploy a fix. Windows differ across programs and may be extended for complex or widely deployed components; they represent an expectation rather than a guarantee of timely resolution.
Disclosure Terms and Safe Harbor
The stated conditions under which a reporter may act without fear of legal action, including scope of authorized testing and rules on public discussion. Safe harbor language varies by program and jurisdiction and does not uniformly protect reporters across all legal regimes.
Multi-Party Coordination
The handling of vulnerabilities that affect multiple downstream or upstream parties, such as a flaw in a shared library, platform, or supplier product. This extends beyond a single third-party relationship and can involve fourth-party or Nth-party dependencies, complicating notification and timing.
Notification and Advisory Publication
The communication of confirmed issues to affected customers and the broader public, often through a security advisory. For third-party risk purposes, the timeliness and completeness of vendor advisories affect a receiving organization's ability to assess exposure.

Common questions

Answers to the questions practitioners most commonly ask about CVD.

Is coordinated disclosure the same as public disclosure of a vulnerability?
No. Coordinated disclosure refers to a process in which a party who discovers a vulnerability reports it privately to the affected organization (or an intermediary) and agrees to withhold broad public details until a remediation or mitigation is available, or until an agreed timeframe elapses. Public disclosure is only one possible outcome at the end of that process. Conflating the two overlooks the coordination phase, the negotiation of timing, scope, and communication between the reporter and the affected parties, which is the defining feature of the practice.
Does coordinated disclosure guarantee that a vulnerability will be fixed before it becomes public?
No. Coordinated disclosure structures communication and timing, but it does not compel remediation. Depending on the parties involved, a vulnerability may be publicly disclosed after an agreed period even if a fix is incomplete, and reporters may disclose independently if coordination breaks down. The process typically improves the odds that a mitigation exists before wide disclosure, but it confers no guarantee, and outcomes vary with the willingness and capacity of the affected organization to remediate.
How does coordinated disclosure fit into a third-party or supply chain risk program?
In many programs, coordinated disclosure is relevant both to how an organization handles vulnerabilities reported in its own products and services and to how it expects suppliers to handle vulnerabilities in theirs. Contractual terms or vendor security requirements may ask suppliers to maintain a disclosure process and to notify the organization of relevant vulnerabilities. It is worth noting that a supplier's disclosure policy typically governs the supplier's direct products and may not extend visibility into fourth-party or Nth-party components embedded further down the supply chain.
What elements are typically defined when establishing a coordinated disclosure process?
Programs commonly define a reporting channel (such as a security contact or intake form), scope statements indicating what systems or products are in and out of scope, expectations around acknowledgement and response timing, the intended remediation and disclosure timeline, and terms addressing legal safe harbor for good-faith researchers. Depending on the organization, an intermediary or coordinating body may be involved. What a policy covers and excludes should be stated explicitly, since gaps in scope can create ambiguity for both reporters and the organization.
How should timelines be handled when a supplier is slow to remediate a reported vulnerability?
Timelines are typically set as expectations rather than fixed guarantees, and disputes over pace are among the most common friction points. Where a supplier is unable or unwilling to remediate within an agreed window, organizations often escalate through the coordination channel, involve a coordinating intermediary, or reassess their own compensating controls and exposure. The available response depends on contractual leverage and the risk tier of the supplier, and it may not fully address residual risk while remediation remains outstanding.
What are the practical limitations of relying on coordinated disclosure for supply chain visibility?
Coordinated disclosure depends on someone discovering and reporting a vulnerability, so it provides no assurance of completeness, unreported or undiscovered issues remain outside its reach. Its effectiveness also depends on the affected party maintaining a functioning intake and response capability. In a supply chain context, visibility is typically strongest at the direct supplier tier and diminishes across deeper tiers, so a disclosure process is best treated as one component alongside ongoing monitoring and other controls rather than a substitute for them.

Common misconceptions

Coordinated disclosure is the same as full public disclosure of a vulnerability.
Coordinated disclosure typically involves withholding public details until a remediation window has elapsed or a fix is available, whereas full disclosure releases details immediately. They represent different philosophies about timing, and confusing them can misstate a vendor's actual practice.
A supplier having a disclosure policy means its products are independently verified as secure.
A published disclosure program is a process commitment, not an attestation or independent verification of security. It does not confirm that reported issues are validated thoroughly or remediated within stated windows, and it should not be treated as evidence of a security certification.
A coordinated disclosure agreement with a direct third party covers all vulnerabilities in the supply network.
Direct third-party disclosure arrangements typically address that party's own products and services. Flaws originating in fourth-party or Nth-party components may fall outside the direct relationship, and visibility beyond the first tier is often limited, leaving multi-party coordination dependent on the upstream provider.

Best practices

During due diligence, assess whether a supplier maintains a published vulnerability disclosure channel and documented triage process, and treat its presence as a process indicator rather than proof of secure products.
Include contractual expectations for timely notification of confirmed vulnerabilities affecting the supplier's products or services, recognizing that remediation windows are expectations subject to extension, not guarantees.
Map dependency on shared components and platforms so that multi-party vulnerabilities involving fourth-party or Nth-party providers can be identified, since direct third-party terms may not cover these.
Establish an internal process to ingest and act on supplier security advisories promptly, since a vendor's disclosure timing directly affects your ability to assess and remediate your own exposure.
Where you operate a disclosure program, define scope, safe harbor terms, and intake channels clearly, and note that safe harbor protections vary by jurisdiction and may not shield reporters uniformly.
Re-verify supplier disclosure and remediation practices periodically rather than relying on onboarding assessments, since point-in-time reviews become stale as programs and personnel change.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide