A /security Page Template for a Small SaaS, Line by Line

On 18 October 2026 the Rails project's security page was a few short paragraphs: one place to report, a stated fallback if nobody answers within 30 days, a promise to acknowledge reports "before or during our monthly security meeting depending on severity", and a link to where announcements appear. That is the whole page, and it is enough, because every sentence is something a researcher can act on.

Most small SaaS companies do the opposite. They write a page of badges and adjectives, with no way to report anything. Here is a better structure.

What's affected

Any company that has been asked by an enterprise customer for a vulnerability disclosure policy, or that expects to be. CISA's BOD 20-01, issued 2 September 2020 for federal agencies, is a useful yardstick. It does not mandate a response time, but its footnotes recommend acknowledging a report within 3 business days and resolving it within 90 days from receipt, and it calls those targets, not mandatory remediation dates.

Your /security page is where those promises live. The Policy field in security.txt should point to it.

How to check if you're exposed

Open your own site in a private window and try to do what a stranger would do.

1. Can you find a reporting address in two clicks from the footer?
2. Does the page say what you will do after a report arrives, with numbers?
3. Does it say what is in and out of scope?
4. Does /.well-known/security.txt exist and link to this page?
5. Does any sentence claim something you cannot show a customer on request?

curl -sL https://example.com/.well-known/security.txt | grep -i '^Policy:'
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/security

What to do now

1. Create /security with the sections below. Keep it under one screen on a laptop.

# Security at Example Co

## Report a vulnerability
Email security@example.com or use https://example.com/security/report.
Please include the affected URL or product version, steps to reproduce,
and what you could access. Do not access other customers' data.

## What happens next
We acknowledge within 3 business days. We send a first assessment
within 10 business days. We aim to fix confirmed issues within 90 days,
sooner for severe ones, and we will tell you if we need longer.

## Scope
In scope: app.example.com, api.example.com, our mobile apps.
Out of scope: social engineering, denial of service, third-party
services we use, automated scanner output without a demonstrated impact.

## Our commitments
We will not pursue legal action for good faith research that follows
this policy. We will credit you in our advisory if you wish.

## Security updates
Advisories: https://example.com/security/advisories
Subscribe: https://example.com/security/feed.xml

## For customers
Documents available on request: security overview, policy summaries,
penetration test summary under NDA. Contact: security@example.com

2. Fill in only numbers you will meet. The ones above are an example, not a recommendation. If you cannot staff 3 business days, write 5.
3. Add the safe harbor sentence only after your lawyer has read it.
4. Keep an advisories page, even if it says "None published yet."
5. Add the page URL to the Policy line in security.txt.

A short trust center checklist for the "For customers" block, once buyers ask:

Two notes on the sections. The Rails page gives a fallback path if the first channel goes quiet: after 30 days with no reply, the reporter may email a second address or contact a named coordinator directly. Copy that idea. A reporter with nowhere to escalate will go public sooner than one who can see the next step.

The "What happens next" block is the one customers read twice. State the acknowledgment time, the first assessment time and the fix target as three separate numbers, and say what you will do if you need longer. Telling the reporter early that a fix will take more than 90 days is far better than letting the date pass in silence.

How to avoid this trap

1. Do not claim a certification or attestation you do not hold. SOC 2 is an attestation report issued by a CPA firm, not a certificate, so describe it as "report available under NDA" once it exists.
2. Do not publish a response time you have not met. Measure your last five reports first.
3. Do not list every cloud service as in scope. A short, accurate list beats a hopeful one.
4. Do not bury the contact below marketing text.

Why it matters

A reviewer at a customer reads your page for about a minute, then decides how hard to push on the questionnaire. A clear page with a working contact and honest numbers shortens that conversation. A vague one lengthens it.

It also makes your life easier when something real arrives. The report lands in a mailbox that three people watch, with a template reply already agreed.

Try it yourself

Take the template, replace every example address and number, and have a colleague who has not seen it find the reporting address in under 20 seconds. Then click through a trust center walkthrough to see where the "For customers" block goes when you outgrow a single page.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Rails security policy
• CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
• RFC 9116: security.txt