A useful trust page answers the first ten questions a buyer's security reviewer would ask, in plain language, with dates. It needs a security overview, a list of certifications and attestations you actually hold, a subprocessor list, a way to report vulnerabilities and a named contact. Everything else can wait.
Start with what reviewers search for
Reviewers do not read your trust page for pleasure. They scan it for reasons to proceed or to send a longer questionnaire. The goal is to remove the need for the longer questionnaire where you can.
The minimum set
- A short security overview. Two or three paragraphs on how data is stored, who can access it, how changes are reviewed and how incidents are handled. Specific beats impressive.
- Attestations and certifications. List only what you hold, with the scope and the date. If an audit is in progress, say "in progress" and not more. Never describe an attestation as a certification if it is not one.
- Subprocessors. The vendors that process customer data, what they do and where. Buyers who are processors themselves need this for their own obligations.
- Data handling. Where data lives, retention, deletion on request, encryption in transit and at rest.
- Vulnerability reporting. A contact and a short policy. See the post on security.txt and disclosure pages.
- Security contact. A monitored mailbox, not a personal address.
- Downloadable documents. A standard questionnaire response and a policy summary.
What to gate
Reports from auditors, penetration test results and detailed architecture diagrams are commonly shared after an NDA or a request form. Gating is fine if the request process is fast. A form that takes a week to answer defeats the point of having a page.
What to leave off
- Claims you cannot evidence.
- Customer names without permission.
- Logos of frameworks you do not meet.
- Anything that goes stale quickly without an owner, such as uptime numbers you do not update.
Show your dates
Add "last updated" to the page and to each document. A page dated two years ago reads as abandoned, and a reviewer will assume the same about your controls.
Keep it honest at the edges
If you are early, a thin honest page beats a thick vague one. Say what you do today, what is in progress, and what you will share on request. Reviewers read that as maturity.
Quick check
Do we need a trust page before our first audit report?
No, but a short page still saves time. A security overview, subprocessor list and contact details answer many first-round questions.
Who should own the page?
One named owner, usually the security lead, with a quarterly review reminder and a rule that any control change triggers a check of the page.
Last reviewed: 19 October 2026.
