Vulnerability Disclosure Policy Setup Guide: Template, Process, and Researcher Relations
A vulnerability disclosure policy is the document that tells external security researchers what they can test, how to report what they find, and what the organization commits to do with their reports. Without one, researchers who find vulnerabilities in your systems have no safe channel to report them and no legal protection for doing so. A basic VDP takes one week to implement: draft the policy, publish it, set up an intake mailbox, and write the researcher response templates.
VDP Policy Template
Publish at https://yourdomain.com/security and in your security.txt file at /.well-known/security.txt.
SECURITY VULNERABILITY DISCLOSURE POLICY
Introduction
[Company] is committed to the security of our systems and data. We welcome
reports from the security research community about vulnerabilities in our
products and services.
Scope
In scope: *.yourdomain.com, yourapp.com
Out of scope: Internal systems not publicly accessible, third-party services,
physical security, social engineering attacks
Guidelines
We ask that researchers:
- Provide detailed reports with sufficient information to reproduce the issue
- Give us reasonable time to address the issue before public disclosure
- Avoid accessing, modifying, or deleting data that is not yours
- Avoid disrupting or degrading our services
- Do not perform denial of service testing
Safe Harbor
We will not pursue legal action against researchers who:
- Comply with this policy in good faith
- Report findings promptly without exploiting them
- Make a good-faith effort to avoid privacy violations and service disruption
Process
1. Submit your report to: security@yourdomain.com
2. We will acknowledge receipt within 2 business days
3. We will provide an initial assessment within 5 business days
4. We will communicate our fix timeline and keep you updated
5. We will notify you when the vulnerability is resolved
We do not offer monetary rewards at this time.
Setting Up Your security.txt File
RFC 9116 defines the standard location: /.well-known/security.txt. Generate a signed or unsigned file at https://securitytxt.org/.
Minimum required fields:
Contact: mailto:security@yourdomain.com
Expires: 2027-05-20T00:00:00.000Z
Recommended fields:
Contact: mailto:security@yourdomain.com
Preferred-Languages: en
Policy: https://yourdomain.com/security
Expires: 2027-05-20T00:00:00.000Z
Sign with PGP if you have a key (optional, but it signals maturity and verifiability to experienced researchers).
Validate after publishing:
curl https://yourdomain.com/.well-known/security.txt
Update the Expires field at least 30 days before it lapses. An expired security.txt signals neglect to researchers and some automated scanners.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Intake Process Setup
Minimum setup: a dedicated email alias (security@yourdomain.com) forwarding to a shared mailbox or ticketing system.
Better: Jira Service Management or Linear with a submission form at yourdomain.com/security/report.
Best for scaling: HackerOne or Bugcrowd offer free-tier VDP programs with built-in triage workflows, researcher identity verification, and duplicate detection.
Required fields in any intake form:
- Vulnerability type (XSS, SQLi, IDOR, misconfiguration, etc.)
- Affected URL or system
- Steps to reproduce
- Impact assessment (what data or function is affected)
- Reporter contact (optional -- some researchers prefer anonymous submission)
Set up an email auto-acknowledgment immediately after publishing your VDP:
"Thank you for contacting our security team. We received your report and a team member will review it within 2 business days. If you have additional information to share, please reply to this message."
This auto-reply alone reduces researcher frustration significantly because the most common complaint is never knowing if the report was received.
Researcher Communication Templates
Acknowledgment (send within 2 business days of receipt): "Thank you for your report. We have assigned it reference number VDP-[YYYY]-[NNN]. We will review it and provide an initial assessment within 5 business days. If you have additional information, reply to this email with the reference number."
Valid finding acknowledgment: "We have validated the vulnerability you reported (VDP-[NNN]). We classify it as [Low/Medium/High/Critical]. Our engineering team is working on a fix. We expect to resolve this by [date]. We will notify you when the fix is deployed."
Out of scope response: "Thank you for your report. The system you reported ([system]) is not within our current VDP scope. We have noted the finding internally. We are not in a position to take action on out-of-scope reports at this time, but we appreciate you taking the time to report it."
Duplicate response: "Thank you for your report. We are already aware of this vulnerability and are working to address it. We appreciate your report and your adherence to responsible disclosure."
Fix deployed notification: "We are writing to let you know that the vulnerability you reported (VDP-[NNN]) has been resolved as of [date]. Thank you for helping improve the security of our systems. May we credit you on our security acknowledgments page?"
Have all five templates ready before publishing the VDP. The first few reports often arrive within 24 hours of publication.
Tracking and Metrics
Maintain a VDP tracking log in Jira, Notion, or a spreadsheet with these fields: Report ID, Date received, Reporter, System, Vulnerability type, Severity (CVSS or Low/Med/High/Critical), Status, Fix date, Researcher credited.
Metrics to report quarterly to leadership:
- Total reports received
- Valid vs. invalid ratio (signals program health)
- Average time to acknowledge (target: less than 2 business days)
- Average time to fix by severity (Critical: 30 days, High: 60 days, Medium: 90 days)
- Critical and high findings vs. low findings
Optional but high-value: publish an annual transparency report with aggregated numbers. It signals maturity to customers, auditors, and regulators without disclosing specific vulnerabilities.
Researcher credits: a "Hall of Thanks" page on your security site costs nothing to maintain and substantially increases researcher goodwill. Researchers who feel recognized return and report more findings.
The bottom line
A VDP is a policy first and an email address second. Publish the policy with clear scope and safe harbor language, set up the intake channel, write your response templates before the first report arrives, and commit to response timelines you can actually meet. A VDP with slow or inconsistent responses is worse than a clear statement that you're not ready yet -- researchers who feel ignored publish.
Frequently asked questions
What is the difference between a vulnerability disclosure policy and a bug bounty program?
A VDP is a policy that defines how researchers can report vulnerabilities and what the organization commits to do with reports. No payment is required. A bug bounty program is a VDP with cash rewards attached. Start with a VDP; add bounties later if you want to incentivize volume.
Do I need a VDP?
CISA requires federal agencies to have a VDP under BOD 20-01. For private companies, it is best practice. Without a VDP, a researcher who finds a vulnerability in your systems has no safe way to report it -- they may disclose publicly or sit on the finding. A VDP creates a structured channel.
What should be in scope for a VDP?
Start narrow: your primary public-facing domain and any customer-facing web applications. Explicitly exclude: internal systems, third-party infrastructure you don't control (AWS, Cloudflare), and systems that would be dangerous to test (payment processing under PCI scope). Expand scope as your intake process matures.
What safe harbor language should I include in my VDP?
Safe harbor should state that you will not pursue legal action against researchers who follow the policy in good faith, will work with researchers to understand findings, and will not share researcher information with law enforcement without notice. CISA's template at cisa.gov/vulnerability-disclosure-policy-template provides model language.
How do I triage incoming vulnerability reports?
Three-question triage: (1) Is it a real vulnerability in our systems, not a scanner false positive? (2) Is the reported system in scope? (3) What is the severity? Respond to all reports within 5 business days even if the answer is 'this is a duplicate' or 'out of scope.' Silence frustrates researchers and leads to public disclosure.
What should I commit to in terms of response timelines?
CISA's standard: acknowledge within 24 hours, provide status update within 1 week, communicate fix timeline. 90-day resolution deadline is researcher community norm. If you cannot fix in 90 days, communicate why and agree on an extension. Unresponsive organizations regularly get public disclosures.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.