how to write a public security policy page

how to write a public security policy page

TL;DR

Publish what you actually do for security, how to report a vulnerability, and what reporters can expect from you. Keep every claim verifiable and get legal to bless the safe-harbor language. A good security page turns nervous prospects into customers and random researchers into allies.

how to write a public security policy page

Use this when

• Prospects keep asking for your security posture and you have nothing to link
• You want vulnerability reports to come to you instead of going public first
• You are building the trust content for an enterprise motion
• Your current security page is three vague sentences from 2022

Not for this skill when

• You need the internal incident response runbook (that stays private)
• You are writing a whitepaper on your cryptography (deeper content, different audience)
• The goal is marketing copy with no substance (researchers see through it instantly)

Steps

1. Write the overview in plain language.

Two or three sentences on how you think about security: what you protect, the frameworks you follow, the practices you actually do. No superlatives, no "bank-grade." If a claim is on this page, someone on your team must be able to prove it.

Expected: an intro paragraph every engineer at the company would nod along with.

2. Describe your practices specifically.

Encryption at rest and in transit, access control and MFA, logging and monitoring, backups and restore testing, pen testing cadence, secure development practices. Name the specifics: algorithms, frequencies, standards. Vague practices read as no practices.

Expected: a practices section where each bullet names something checkable.

3. Add a clear reporting channel.

Tell researchers exactly how to reach you: a dedicated reporting form or contact page, what to include (affected URL or endpoint, steps to reproduce, impact), and what not to do (no data exfiltration, no disrupting service). Make it reachable without an account.

curl -s https://example.com/security | grep -i "report"

Expected: the page exists and a stranger can figure out how to report within a minute.

4. Publish response SLAs and a safe harbor.

Commit to acknowledgment and update timelines you can actually meet, like acknowledging within two business days. Add safe-harbor language: good-faith research following your rules will not get a legal threat. Get legal to review this section; it is the one with teeth.

Expected: published timelines plus reviewed safe-harbor wording.

5. Define scope and rewards if you have them.

Say what is in scope (your domains, your apps) and what is out (third-party services, physical attacks, social engineering). If you pay bounties, say the ranges; if you do not, say you offer recognition. Clear scope prevents wasted effort on both sides.

Expected: a scope list that answers "can I test this" for the common cases.

6. Serve a security.txt too.

The security page is for humans; security.txt is for tooling. Put contact and policy links in /.well-known/security.txt so scanners and researchers find you automatically.

cat .well-known/security.txt

Expected: a file with a contact link, a policy link, and an expiry date, all valid.

7. Keep it current.

Review the page whenever your practices change: new pen test, new certification, new reporting channel. A page claiming last year's practices is worse than no page because it is wrong in writing.

Expected: a review date on the page, refreshed at least annually.

Variant: security.txt file

A small text file at /.well-known/security.txt with contact info, policy link, and expiry. Ten minutes of work, and it is where automated tooling looks first.

Variant: responsible disclosure policy template

This skill's steps 3 through 5 are the disclosure policy: how to report, what happens next, what is authorized. Lift those sections into your own template.

Variant: vulnerability disclosure policy

Same thing under the more formal name. The critical parts are the safe harbor and the response SLAs; without those it is a policy in name only.

Variant: what goes on a /security page

Overview, specific practices, how to report, response timelines, safe harbor, scope, compliance badges you actually hold, subprocessor list link. In that order.

Why this happens

Researchers find vulnerabilities whether you invite them or not. Without a reporting channel, they go public, or to a customer, or nowhere, and you learn about it from Twitter. A clear page with a safe harbor converts that discovery into a private report with a head start on the fix. It also answers half of every enterprise questionnaire before it is asked.

Edge cases and pitfalls

• Claims you cannot prove: every sentence is a potential questionnaire answer and a potential lie. If the pen test lapsed, take the cadence claim down until the next one.
• Safe harbor without legal review: well-meaning wording that legal would not honor is a trap for researchers and a liability for you. Get the review.
• A reporting inbox nobody monitors: the page promises a response; an unmonitored inbox breaks the promise on day one. Route it to the on-call or a monitored queue.
• Scope arguments with researchers: publish the scope clearly and honor good-faith mistakes at the edges. Fighting over scope in public never looks good.
• The page becomes marketing's page: keep ownership with security or engineering. Marketing adjectives creep in fast ("unbreakable," "military-grade") and each one is a future embarrassment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstTBkrLHIFfR4lTWKchkCUw