Every article on this blog so far starts 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.
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 the questionnaire playbook gets you further than a page nobody has asked for yet.
A trust page is a summary of things that are true. It is not a way to look further along than you are. Reviewers read these for a living and the gap between a page and a questionnaire answer is exactly what they are trained to find.
What belongs on it
- Where the data lives. Cloud provider, regions, and whether anything leaves them. First question, nearly every time.
- Subprocessors. The 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 when. Dated. "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, honestly. Held, 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 vulnerability. An address and a promise to reply. Cheap to publish, and its absence is noticed.
- What is available on request. The 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 |
|---|---|
| Software versions and internal hostnames | More useful to an attacker than to a buyer. Send under NDA if asked. |
| Undated claims | "We run regular penetration tests" invites "when was the last one?", which is the round trip you were removing. |
| Certifications you do not hold | Including logos you are "working towards". This is the one that ends deals. |
| A full findings list | Your open issues are not public information. The summary is; the detail is not. |
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.
Have something dated to put on it.
A trust page is only as good as the facts behind it. Vulnytics gives you an exploit-verified report on your external surface, a re-test after you fix, and a dated attestation letter you can reference publicly and send on request.
Common questions
What is a trust page?
Does a trust page replace the security questionnaire?
What should not go on a trust page?
Is a trust page worth it before you have any certification?
This describes how enterprise reviewers commonly treat public security pages and is general guidance, not legal or compliance advice; your buyer's policy and your own counsel govern what you publish. Vulnytics combines exploit-verified automated assessment with hands-on expert review by a person. We are not an accredited penetration-testing firm, so our report complements, and does not universally replace, one from an accredited firm where a buyer specifically requires it.