TL;DR: Vulnerability disclosure policies create a structured path for external vulnerability reports, and Intigriti’s analysis shows many researchers still cannot find, trust, or use that path effectively. Without clear scope, safe harbor, and acknowledgement timelines, organisations leave vulnerabilities unreported and push remediation into firefight mode.
NHIMG editorial — based on content published by INTIGRITI: The critical role of vulnerability disclosure policies in cybersecurity
By the numbers:
- Cybercrime is projected to cost global enterprises $10.5 trillion annually by 2025, which is why structured vulnerability disclosure is no longer optional.
- 65% of respondents said they had found a vulnerability at a company without a vulnerability disclosure policy, showing how often gaps remain at the point of discovery.
- 13% chose to report the vulnerability via public disclosure, which shows how unclear or unavailable reporting channels can push researchers outside coordinated processes.
Questions worth separating out
Q: How should security teams implement a vulnerability disclosure policy?
A: Start with a single intake path, a narrow but clear scope, and an internal ownership model for validation and remediation.
Q: Why do vulnerability reports often go unreported or get delayed?
A: Because researchers cannot easily tell whether they are allowed to report, where to send the finding, or whether anyone will respond.
Q: What breaks when an organisation has no vulnerability disclosure policy?
A: Reports arrive through inconsistent channels, researchers hesitate to escalate findings, and security teams lose visibility into exposures that should be remediated quickly.
Practitioner guidance
- Publish a scoped disclosure policy Define in-scope systems, report formats, and a single authoritative submission path so researchers are not forced to guess through customer service or social media.
- Set response SLAs that triage can meet Commit to acknowledgement and update intervals that match your actual staffing and queue capacity.
- Route identity-related reports into the right owners Create a handoff from VDP intake to IAM, PAM, and secrets management owners when the report involves API keys, service accounts, OAuth apps, or credential exposure.
What's in the full article
INTIGRITI's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for writing scope, reporting, and response language that researchers can actually use.
- Examples of safe harbour and disclosure timeline wording that reduce ambiguity for external reporters.
- Operational options for hosting a VDP on a dedicated platform versus a standalone website.
- Survey findings on how researchers behave when a company has no disclosure policy.
👉 Read INTIGRITI's analysis of vulnerability disclosure policies and reporting gaps →
Vulnerability disclosure policies: what security teams are missing?
Explore further
VDP gaps are often identity governance gaps in disguise. When external researchers cannot find a clear reporting path, the exposed asset is often not just a bug but an access pathway, secret, or integration surface. That means the organisation is missing a control layer that should link vulnerability intake to identity lifecycle response. In practice, VDP maturity should be assessed alongside IAM and NHI response readiness.
A question worth separating out:
Q: Who is accountable when a vulnerability becomes an identity-driven breach?
A: Accountability spans application owners, cloud platform teams, and identity governance teams because the failure crosses security domains. Patch management addresses the flaw, but IAM controls determine the blast radius. A mature programme assigns ownership for workload permissions, trust relationships, and post-exploit containment so the same incident does not recur.
👉 Read our full editorial: Vulnerability disclosure policies reduce reporting gaps and response risk