Processes for receiving, analyzing, and responding to vulnerability disclosures are established
Security researchers, customers, and employees regularly discover vulnerabilities in your products or infrastructure. Without a clear process for receiving these reports, important findings get lost in support inboxes, reported to social media instead of your team, or trigger public disclosure before you have had a chance to fix the issue. A vulnerability disclosure program signals that you take security seriously and gives you control over how findings are handled.
Implementation steps
- 1
Establish a public security contact and disclosure policy
Create a security contact (typically security@yourdomain.com) and publish a security disclosure policy that tells researchers how to report vulnerabilities, what information to include, and how you will handle and respond to reports. Commit to timelines: acknowledge within 48 hours, provide a status update within 14 days. A public policy removes ambiguity for reporters.
- 2
Create an intake and triage workflow for disclosed vulnerabilities
Define how incoming reports are routed, triaged, and assigned. Validate each report (is this a real vulnerability in your system?), score the severity, assign to the appropriate owner, and track through to remediation. Set internal SLAs aligned with your external commitments to reporters.
jiralinearhackeronebugcrowd - 3
Communicate with reporters and close the loop
Keep reporters informed throughout the process: acknowledge receipt, confirm validity, provide a remediation timeline, and notify them when the fix is deployed. Thank reporters for valid findings. Consistent, professional communication builds trust and encourages continued responsible disclosure rather than public posting.
jirahackeronebugcrowd
Evidence required
Published vulnerability disclosure policy
A publicly accessible policy describing how to report security vulnerabilities, what the reporter can expect, and how the organization will handle disclosures.
- · security.txt file at /.well-known/security.txt
- · Security disclosure page on the company website
- · HackerOne or BugCrowd program policy page
Vulnerability intake and tracking records
Evidence of a process to receive, triage, and track vulnerabilities reported by external parties through to resolution.
- · Security inbox with triaged and tracked reports
- · HackerOne or BugCrowd report history showing intake and response
- · Jira tickets created from external vulnerability reports with response timeline
Related controls
Vulnerabilities in assets are identified, validated, and recorded
Risk Assessment
Critical suppliers are assessed prior to acquisition
Risk Assessment
Cyber threat intelligence is received from information sharing forums and sources
Risk Assessment
Internal and external threats to the organization are identified and recorded
Risk Assessment