Vulnerability Disclosure Policy

This policy is a production-grade draft for counsel review. It should be published only after the monitored security contact, severity taxonomy, triage roster, evidence-retention workflow, and safe-harbor language have been approved.

Security reports should be sent through the published security contact for [Your LLC Legal Name]. If the contact route is not yet monitored, do not represent vulnerability intake as production-ready.

We welcome good-faith reports about vulnerabilities that could affect confidentiality, integrity, availability, tenant isolation, authentication, authorization, billing entitlements, deletion controls, security headers, or privacy-safe logging.

Reports should include a concise description, affected URL or component, reproducible steps, expected impact, evidence sufficient to validate the issue without exposing customer content, and contact information for coordinated follow-up.

Do not access, modify, delete, exfiltrate, disclose, or retain customer data; do not perform destructive testing, persistence, social engineering, phishing, spam, denial-of-service, physical attacks, or attacks against third-party providers.

Stop testing and report promptly if you encounter non-public data, secrets, private keys, payment data, personal data, workspace content, or evidence that another tenant may be affected.

For good-faith research that follows this policy, avoids privacy harm, avoids service disruption, and reports promptly, we will not intentionally pursue legal action solely because of the research. This safe harbor does not authorize violations of law, third-party rights, customer agreements, provider terms, or testing outside the stated boundaries.

A final counsel-approved version should define any bug-bounty status, reward eligibility, disclosure timing, duplicate handling, severity taxonomy, remediation communication, and exceptions.

We aim to acknowledge credible reports, triage severity, preserve metadata-only evidence, remediate verified issues according to risk, and coordinate disclosure when appropriate. Timelines may vary by severity, exploitability, customer impact, provider dependency, and legal obligations.

Security concerns may be sent to security@example.com. Do not include raw customer content, secrets, credentials, exploit payloads that cause harm, or third-party personal data.