Legal
Vulnerability Disclosure Policy
Last updated · Version vulnerability-disclosure-2026-09-06
Reporting a vulnerability
We welcome reports from security researchers, and we would rather hear about a problem from you than from an incident. Email [email protected]. Please do not open a public issue, post the details publicly, or contact individual staff.
A report is most useful when it includes:
- a description of the issue and the impact you believe it has,
- step-by-step reproduction, with a proof of concept if you have one,
- the affected component, URL, or endpoint,
- any relevant logs, screenshots, or request ids (we return one in the
x-request-idresponse header).
If you need to share something sensitive, say so in your first message and we will set up a secure channel before you send it.
What we commit to
- Acknowledgement within 2 business days.
- Initial assessment and a severity rating within 5 business days.
- Status updates at least every 7 days until the report is resolved.
- Critical issues prioritized, with a coordinated disclosure timeline agreed with you.
Severity is triaged on the same SEV-1 through SEV-4 scale we use for our own incidents, so a report is handled with the same urgency as an internally-found issue of the same severity.
Scope
In scope.
The Smart Site Plan web application and API, the public Open Data API, and the public share and form surfaces, all under smartsiteplan.com and its subdomains.
Out of scope.
Please do not test any of the following:
- denial-of-service, volumetric, or stress testing,
- social engineering, phishing, or physical attacks against our staff or offices,
- findings that require a compromised device or a privileged network position,
- automated scanner output with no demonstrated, exploitable impact,
- third-party services we depend on. Report those to the vendor; our Sub-Processor Register lists who they are.
Safe harbor
We will not pursue or support legal action against a researcher who:
- makes a good-faith effort to follow this policy,
- avoids privacy violations, data destruction, and degradation of the service,
- interacts only with accounts they own or have explicit permission to test,
- gives us a reasonable opportunity to remediate before disclosing publicly.
If you are unsure whether something is in bounds, ask first. We are glad to authorize a testing scope in advance, and asking never counts against you.
Disclosure and credit
We practice coordinated disclosure and will agree a timeline with you rather than impose one. Once a fix has shipped we are happy to credit you by name if you would like to be named, and equally happy not to if you would not.
Machine-readable contact
This policy is published for automated discovery as an RFC 9116 security.txt at /.well-known/security.txt, which names this page on its Policy: line. Our security controls are documented in the Trust Center.