A vulnerability disclosure policy your product team can operate

A public page needs an internal owner

A policy page cannot triage an issue or release a patch. Before publication, assign an owner for the security inbox, a deputy, an escalation path and an issue-tracking location. Send a harmless test report and verify that someone receives it.

Keep the contact separate from ordinary sales requests. Explain how a reporter can share sensitive technical details securely. Do not invite credentials, customer records or unrestricted exploit data through a marketing form.

What the public policy should contain

• The products and supported versions the policy covers.
• A verified security contact and a secure reporting option where available.
• The information needed to reproduce and locate the issue.
• The process for acknowledgement, assessment and updates.
• How publication of findings will be coordinated with remediation.
• The boundaries of authorised testing, reviewed with appropriate legal counsel.

A report format that reduces back-and-forth

Ask for the product/version, affected component, a concise impact description, reproduction steps and a way to contact the reporter. Mark optional material clearly. The reporter should not have to prove a legal classification before the team will investigate.

Internally, connect the report to the affected release, dependency inventory, investigation owner and remediation decision. Record why the team closed or deferred it. A closed ticket without a reason is weak evidence for the next investigation.

Avoid promises the team cannot deliver

Choose acknowledgement and update commitments based on real staffing and escalation coverage. A target copied from another company’s policy can become an operational problem if nobody monitors the inbox over a weekend.

A public disclosure policy is not blanket authorisation to test customer systems and does not replace legal terms. Have the relevant boundaries reviewed before publication.

From draft to a working process

Dotgrey Continent’s assessment includes a security contact page and a product-specific disclosure policy ready for your team to publish. The wider engagement can connect intake, triage, updates and evidence to your engineering workflow.

Use the downloadable outline below as a workshop input. Replace every placeholder, verify the mailbox and review the testing boundaries before publishing it.