Security vulnerabilities exist in every production system. The question is not whether they will be found — it is whether the people who find them have a clear, safe way to tell you before someone else finds out first. A Vulnerability Disclosure Policy answers that question. This guide walks through every element you need to build one that researchers will actually use, that holds up under legal scrutiny, and that satisfies the auditors reviewing your ISO 27001 or SOC 2 evidence package.
HackerOne 2024
Bugcrowd 2024
HackerOne 2024
What Is a Vulnerability Disclosure Policy?
A Vulnerability Disclosure Policy is a published statement that tells security researchers how to report vulnerabilities they discover in your systems, what to expect in response, and what legal protections they have for acting in good faith. It is the structured front door for coordinated vulnerability disclosure.
Without a VDP, a security researcher who finds a critical vulnerability in your system faces an uncomfortable choice: report it anyway and risk legal action under computer crime laws, publish it publicly to force a response, or stay silent. None of these outcomes serve you or the researcher. A VDP creates a fourth option — a clear, safe, structured path to responsible disclosure.
"Security researchers find vulnerabilities whether you want them to or not. A VDP is not permission for them to test your systems — it is a commitment about what you will do when they find something and come to you."
VDP vs Bug Bounty — What Is the Difference?
These terms are often confused. The distinction is simple but important for deciding where to start.
Vulnerability Disclosure Policy
- Defines how to report vulnerabilities
- Provides legal safe harbour for researchers
- Sets response time commitments
- No financial reward for findings
- Low report volume — manageable for any team
- The right starting point for most organisations
Bug Bounty Programme
- VDP plus financial incentives per valid finding
- Significantly higher report volume
- Requires dedicated triage capacity
- Attracts professional researchers at scale
- Can cost thousands to hundreds of thousands
- Build on top of a mature VDP, not before it
Most organisations should build a VDP first and run it for 6-12 months before introducing monetary rewards. A bug bounty programme launched without mature internal triage processes will generate more reports than the team can handle — leading to slow responses, frustrated researchers, and a programme that damages rather than builds trust.
The 6-Step Build Process
- 1Define your scope explicitlySpecify exactly which systems, domains, and assets are in scope — and equally importantly, what is explicitly out of scope. Ambiguous scope is the number one reason researchers stop reporting. If they are unsure whether a system is in scope, most will not risk testing it.
- 2Write your safe harbour clauseCommit in writing that researchers acting in good faith within your defined scope will not face legal action. This is the single most important element of a VDP — without it, researchers assume legal risk under computer crime laws and most will simply not report.
- 3Create a dedicated submission channelSet up a security reporting email address (security@yourdomain.com) or use a managed platform like HackerOne, Bugcrowd, or Intigriti. Publish a security.txt file at /.well-known/security.txt pointing to it. Make it easy to find — a disclosure process nobody can locate is not a disclosure process.
- 4Set and publish response time commitmentsResearchers need to know their report will not disappear. Commit to specific timelines: acknowledge within 3 business days, provide a status update within 10 days, resolve critical findings within 30 days. These commitments are also what auditors look for as evidence of a functioning programme.
- 5Build your internal triage process firstThe internal process must exist before you publish the policy. Define who receives reports, how they are assessed for severity using CVSS, which team owns remediation, how the researcher is kept updated, and what happens if a finding requires coordinated disclosure with a third party. Publishing without this ready guarantees you will miss your own SLAs on the first report.
- 6Publish, promote, and maintain itPublish the VDP at a stable URL such as /security or /responsible-disclosure. Add a security.txt file. Reference it in your security documentation and ISO 27001 ISMS. Review it annually and update it when your scope changes. A VDP is a living document — set it once and forget it and it will become inaccurate and unenforceable.
Defining Your Scope
Scope definition is where most VDPs fail. Overly broad scope creates legal uncertainty — researchers do not know where they can and cannot test. Overly narrow scope makes the programme useless — it excludes the systems that matter most. Here is what a well-defined scope looks like:
Example VDP Scope Definition
✓ In Scope
- *.seccomply.net (all subdomains)
- app.seccomply.net (web application)
- api.seccomply.net (REST API)
- iOS and Android mobile applications
- Authentication and access control issues
- Data exposure and injection vulnerabilities
✗ Out of Scope
- Physical security attacks
- Social engineering of employees
- Denial of service (DoS/DDoS)
- Third-party services not owned by SecComply
- Issues requiring privileged physical access
- Automated scanner output without proof of concept
DoS testing, social engineering, and physical intrusion attempts should always be explicitly out of scope unless you have dedicated capacity to handle them. Leaving them ambiguous means a researcher who attempts them will claim they were in scope — and you will have no clear basis to disagree.
Writing an Effective Safe Harbour Clause
The safe harbour clause is your commitment to researchers that good-faith security research will not result in legal action. Without it, the Computer Fraud and Abuse Act (CFAA) in the US, the Computer Misuse Act in the UK, and equivalent laws in India make it technically illegal to access systems without explicit authorisation — even to report a vulnerability you accidentally found.
A strong safe harbour clause includes four elements:
- 1Authorisation statementExplicitly state that testing activity within the defined scope, conducted in accordance with the policy, is authorised. This directly addresses the "without authorisation" element of computer crime laws.
- 2Non-prosecution commitmentState that the organisation will not pursue civil or criminal action against researchers acting in good faith within scope. This should be unconditional within the defined boundaries — qualified safe harbours ("we reserve the right to...") undermine researcher confidence.
- 3Good faith definitionDefine what "good faith" means in your context: no accessing user data beyond what is necessary to demonstrate the vulnerability, no disrupting production systems, no modifying or deleting data, no public disclosure before remediation is complete.
- 4Law enforcement statementCommit that if a third party initiates legal action against a researcher who acted in good faith under your policy, the organisation will take steps to clarify that the research was conducted in accordance with your authorisation.
The safe harbour clause is the most important element of any VDP. Without legal protection, researchers who act responsibly face the same legal risk as those who act maliciously — a situation that benefits nobody.
The security.txt File
A security.txt file is a standardised text file defined by RFC 9116, published at /.well-known/security.txt on your web server. It tells security researchers — and automated scanning tools — exactly how to contact you about a vulnerability. It is the single most effective way to ensure your disclosure channel is discoverable.
The Expires field is mandatory under RFC 9116 — it tells researchers when to check for an updated version. Set it to 12 months from publication and update it annually. An expired security.txt signals to researchers that the programme may be inactive.
Building Your Internal Triage Process
The internal triage process is what determines whether your VDP is functional or just a document. It must exist and be tested before you publish the policy. Here are the response timelines that define a credible programme:
VDP and Compliance Requirements
| Framework | Relevant Control | What a VDP Provides |
|---|---|---|
| ISO 27001 | A.8.8 — Management of technical vulnerabilities; A.5.6 — Contact with special interest groups | Formal external vulnerability reporting channel, documented triage process, evidence of engagement with security research community |
| SOC 2 | CC7.1 — Identify and respond to vulnerabilities; CC7.3 — Evaluate security events | Evidence that vulnerabilities are identified through external channels as well as internal testing, documented response process |
| PCI DSS | Req 6.3 — Identify security vulnerabilities and address them | External vulnerability identification channel complementing internal scanning and penetration testing requirements |
| DPDP Act | Section 8(5) — Reasonable security safeguards | Demonstrates proactive vulnerability management as part of reasonable security safeguards — directly relevant to breach prevention |
| NIST CSF | DE.CM — Continuous monitoring; RS.AN — Analysis | External detection input into your vulnerability management programme, coordinated response capability |
A VDP is most effective when it sits inside a mature vulnerability management programme. If you are still building that foundation, our guide to vulnerability management for startups covers the full process — CVSS scoring, triage workflows, and tooling — that your VDP will feed directly into.
When ISO 27001 auditors assess A.8.8 (technical vulnerability management), they look for evidence that your organisation has a systematic process for receiving and acting on vulnerability information from all sources — including external researchers. A published VDP with documented triage records and researcher acknowledgements is among the strongest evidence you can provide for this control.
Frequently Asked Questions
A Vulnerability Disclosure Policy is a published statement that tells security researchers how to report vulnerabilities they find in your systems, what to expect in response, and what legal protections they have for doing so in good faith. It is the front door for coordinated vulnerability disclosure — without one, researchers who find vulnerabilities in your systems have no safe, structured way to tell you about them.
A VDP is a policy that defines how to report vulnerabilities and the safe harbour protections for researchers who do so. A bug bounty programme is a VDP plus financial incentives — researchers are paid for valid findings. A VDP is the foundation; a bug bounty is built on top of it. Most organisations should start with a VDP before introducing monetary rewards, which significantly increase report volume and triage complexity.
ISO 27001:2022 Annex A.8.8 requires organisations to manage technical vulnerabilities, and A.5.6 requires contact with special interest groups including security research communities. A VDP directly satisfies both controls. SOC 2 CC7.1 requires that vulnerabilities are identified through system monitoring and testing — a VDP extends this to external researchers.
A safe harbour clause should explicitly state that the organisation will not pursue legal action against researchers who discover and report vulnerabilities in good faith, acting within the defined scope and following the policy guidelines. It should reference that the organisation considers such research authorised under applicable computer crime laws. It should also state what researchers must not do — such as accessing user data beyond what is necessary to demonstrate the vulnerability.
A security.txt file is a standardised text file published at /.well-known/security.txt on your web server that tells security researchers how to contact you about vulnerabilities. It is defined by RFC 9116 and typically includes your security contact email or URL, a link to your VDP, an expiry date, and optionally a PGP key for encrypted submissions. It is the single most effective way to ensure researchers can find your disclosure channel.