When a public security page saves time, the six things worth putting on one, the four that make it backfire, and how a reviewer reads it in thirty seconds.
- Published
- Updated
- Reading time
- 8 min read
- By
- Zaaf review desk
In this guide
Most security review guides start the same way: a review lands and you respond. This one is about the other direction. At some point you notice you are answering the same fifteen questions for every deal, and the question becomes whether to answer them once, in public.
What a trust page actually is
A page on your own domain that answers the security questions buyers ask most often. Where data is stored, who your subprocessors are, what you hold or are working towards, how someone reports a vulnerability. Larger companies call it a trust center and put a portal behind it. For a startup it is usually one page.
It is not a certification, there is no standard format, and nobody grades it. Its only job is to remove a round trip.
- PublicStable facts any buyer can read.
- On requestReports and letters shared under an agreed process.
- CurrentAssign an owner to keep it accurate.
When it earns its keep
The honest answer is: later than founders expect, and for a narrower reason.
- You are answering the same questions repeatedly. Three or four reviews in, the overlap is obvious. That repetition is the signal, not the deal count.
- You sell to people who research before they contact you. A security-conscious buyer often checks before the first call. Nothing to find reads as nothing to say.
- Your champion has to sell you internally. They forward a link. A page they can forward is worth more than an email they have to summarise.
When it does not earn its keep: your first enterprise deal. One review is faster answered directly, and a careful questionnaire answer gets you further than a page nobody has asked for yet.
What belongs on it
- Where the data livesCloud provider, regions, and whether anything leaves them. First question, nearly every time.
- SubprocessorsThe list, what each one touches, and a way to be told when it changes. Legal asks for this even when security does not, so publishing it removes a request from every future review.
- What you have tested, and whenDated. "Last external assessment: June 2026" beats a paragraph about your commitment to security, and it pairs with an attestation letter you can send on request.
- Certification status, honestlyHeld, in progress with a date, or not pursued. Whether you need SOC 2 at all depends on the buyer, but the page should not be vague about where you are.
- How to report a vulnerabilityAn address and a promise to reply. Cheap to publish, and its absence is noticed.
- What is available on requestThe report, the letter, a completed questionnaire. This is the line that turns a public page into a shortcut.
What to leave off
| Leave off | Why | Instead |
|---|---|---|
| Software versions and internal hostnames | More useful to an attacker than to a buyer. | Send under NDA if asked. |
| Undated claims | "We run regular security testing" invites "when was the last one?", which is the round trip you were removing. | Give the date of the last assessment. |
| Certifications you do not hold | Including logos you are "working towards". This is the one that ends deals. | State the status and the date honestly. |
| A full findings list | Your open issues are not public information. | Publish the summary; keep the detail on request. |
How a reviewer reads it
Quickly, and looking for two things: whether the claims are dated, and whether the page and the questionnaire agree. A reviewer who finds one contradiction stops treating the page as a shortcut and starts treating it as a source of questions, which is the opposite of what you built it for.
That is also why the page is downstream of having something to say. A page listing four dated facts and one artifact you can send beats a page of assurances, and the fastest way to get the dated facts is to have run the review process once deliberately rather than reactively.
The smaller version that usually works
Most startups do not need a trust center. They need one page with six headings, a date on each, and an email address, linked from the footer and from the security question in their own sales deck. Fifteen minutes of writing against a week of saved round trips, and you only build the bigger version when a buyer asks for something the page cannot hold.
Before you publish
A quick final check
Common questions
What is a trust page?
A public page on your own domain that answers the security questions buyers ask most often: where data lives, who your subprocessors are, what certifications you hold or are working towards, and how to report a vulnerability. Some companies call it a trust center. It is not a certification and it has no standard format; its only job is to save both sides a round trip.
Does a trust page replace the security questionnaire?
No. Buyers with a formal process will still send their own questionnaire, because their answers have to sit in their system in their format. A good trust page shortens the exchange rather than removing it: the reviewer can pre-fill or skip the questions you have already answered publicly, and the ones left are the ones specific to their deployment.
What should not go on a trust page?
Anything you cannot back if asked, anything undated, and any detail that helps an attacker more than a buyer. Specific software versions, internal hostnames and network topology belong in a report sent under NDA, not on a public page. Claims without evidence are worse than saying nothing, because a reviewer who catches one starts checking everything else.
Is a trust page worth it before you have any certification?
Often yes, and that is when it does the most work, because it gives you somewhere to be concrete while the audit is still months away: what you actually do, what you have tested and when, and a dated commitment for the rest. A page that says "SOC 2 in progress, readiness started March, evidence pack available on request" is more useful to a reviewer than silence.
NoteThis describes how enterprise reviewers commonly treat public security pages. It is general guidance, not legal or compliance advice; your buyer's policy and your own counsel govern what you publish.