Write the boundary before inviting reports
A vulnerability disclosure policy (VDP) explains what a team authorizes, where a researcher can send a report, and what happens next. A mailbox by itself does not define permission. Before publishing, make sure every listed asset and response step has an owner.
Start small. A policy your team can monitor is more useful than a broad promise no one can keep. NIST’s SP 800-216 describes a structured approach to receiving, assessing, coordinating, and communicating vulnerability reports; a small SaaS team can adapt those ideas to its own size and authority.
1. Name a monitored owner and reporting channel
Choose a team mailbox or form that someone checks on business days, then name a backup. Say which languages you can support and whether an anonymous report is accepted. Avoid publishing an address that forwards to an unattended inbox.
Ask for only what helps reproduce and assess a finding: affected asset and version, concise steps, observed impact, and a minimal proof of concept. Tell reporters not to send real customer data, passwords, or unnecessary personal information.
2. Make scope understandable at a glance
List production domains, applications, APIs, or repositories the organization controls. State whether a whole domain, selected subdomains, or exact hosts are in scope. Do not leave wildcard behavior to guesswork. If a vendor or cloud service owns an asset, name it as excluded unless you have written authority to include it.
Separate staging from production and describe any limits for accounts, test data, or features. A researcher should be able to decide “in scope” or “out of scope” before sending a request.
3. Say what testing is allowed—and what is not
Set a low-impact baseline: test only the assets listed, use accounts you own or were given, keep request rates modest, and stop if an action could affect another user or service availability. Explicitly prohibit denial-of-service testing, social engineering, spam, persistence, destructive changes, and accessing, changing, or downloading another person’s data unless a specific test is authorized.
Explain what to do if a researcher encounters sensitive data or an out-of-scope system: stop testing, preserve only the minimum evidence needed, and report the exposure privately. Have counsel review any safe-harbor or legal language; a template is not a substitute for advice about your systems and jurisdiction.
4. Set response expectations you can meet
Publish a realistic acknowledgment window and a cadence for updates. Define who validates a report, who owns the fix, and how the reporter learns that the issue was resolved. If your team cannot promise a fixed remediation deadline, promise a status update instead.
For triage, record reproducibility, affected versions, exposure, likely impact, and any compensating control. Keep the report private while investigating, and coordinate a disclosure date with the reporter when appropriate.
5. Publish, test, and revisit the policy
Put the policy at a stable public URL and link it from your security or contact page. Consider a security.txt file to help people find the reporting channel; RFC 9116 defines that format. Then test the process with a harmless internal report: does it reach the right person, get acknowledged, and create a trackable issue?
Review the scope whenever products, domains, vendors, or monitoring capacity change. Remove promises the team cannot honor. A policy should match the authority you have and the work you can support.
Primary references
- NIST SP 800-216: Recommendations for Federal Vulnerability Disclosure Guidelines — process reference; written for the federal context.
- CISA Vulnerability Disclosure Policy Template — reference language to adapt, not publish unchanged.
- RFC 9116: security.txt — a format for publishing security contact information.