What belongs on a trust page
Guide · Enterprise · 5 min read · last verified 2026-07-27
A trust page is the page where a company states, in one place and in plain language, how it handles customer data, how reliably its service runs, and what security posture it can actually demonstrate. It exists because modern B2B evaluation checks before it asks: by the time anyone from a buying committee talks to you, the committee has usually read whatever public evidence you offer — and increasingly, its AI assistants have read it first.
Who actually reads a trust page
The named audience is the security reviewer, but the working audience is wider: the IT administrator checking where data lives, the procurement lead assembling a risk file, the buyer's counsel skimming for red flags, and the AI assistants those people now use for their first pass. When a committee member asks an assistant whether a vendor is safe to use for customer data, the assistant answers from whatever public text it can find, which makes the trust page a citation surface: a page whose job includes being read, extracted, and quoted by machines summarizing you to a buyer you never meet. A trust page that exists only as a gated PDF is, for that entire audience, a trust page that does not exist. How the committee's roles and their assistants divide this diligence is covered in how AI research serves the whole buying committee.
Two consequences follow. The page must be public and readable as plain text. And every sentence on it should hold up when quoted out of context, because extraction is precisely what assistants do — the selection mechanics are examined in How AI engines pick which page to cite.
State what you have, in claims that survive checking
The affirmative half of the page is an inventory of demonstrable posture: how data is encrypted in transit and at rest, how internal access is controlled and logged, how authentication works for customers, what formal audits or certifications you actually hold, how you test your own defences, and how an outsider can report a vulnerability to you. Two disciplines separate a useful inventory from wallpaper. Precision: a sentence stating that customer data is encrypted at rest is a claim; a sentence stating that security is taken seriously is the absence of one. Dating: posture claims decay, and a visible last-reviewed date tells the reader whether anyone still stands behind the page.
The working rule: every sentence should be one your engineers would confirm without wincing, phrased so a non-specialist understands what is being promised. If a claim needs a euphemism to feel comfortable, it is not true yet — and belongs in the next section instead.
State what you do not have yet
The counterintuitive section is the honest gap list: the certifications not yet achieved, the capabilities — say, customer-managed keys or regional data residency — not yet shipped, each with a sentence of current status. The mechanical case for it: an evaluator's checklist contains a row for each of these whether your page mentions them or not. Silence does not delete the row; it fills the row with the reviewer's worst assumption plus an extra email cycle to confirm it. A stated gap, by contrast, is a claim you control. It says what exists today, what compensates in the meantime, and that you know the gap is there — which is information about your competence, not only your posture.
The same logic extends to the machine audience: assistants repeat what pages state, so a stated gap gets represented on your terms, while an unstated one is at best absent from the answer and at worst filled in wrongly. Gaps demand the one discipline everything else here demands — no promised dates you would not bet on, and no aspirational status dressed as current fact.
Data handling in plain language
The core of the page answers the reader's actual questions about their data, one at a time, without requiring a policy lawyer to translate:
| Reader's question | What the page should state |
|---|---|
| Where does my data physically live? | Hosting provider and regions, plainly named |
| Who inside the vendor can see it? | Access rules, and how access is logged and reviewed |
| Is it used to train AI models? | A direct yes or no, with scope |
| What happens when we leave? | Export format and deletion commitment |
| What third parties touch it? | The subprocessor list, linked from here |
The AI-training row deserves emphasis: buyers now raise it early, assistants get asked it constantly, and an explicit answer in either direction beats an inferable one. None of this replaces the privacy policy, and it should not read like it — the policy exists for lawyers; the trust page exists for the committee.
Subprocessors, uptime, and incidents
Three specifics earn dedicated space. Subprocessors: name the third parties that process customer data and what each one does. Evaluators will assemble this list with or without you, and a vendor-maintained version is the difference between transparency and forensics. Uptime: publish how availability is measured and where the reader can see history, rather than adjectives about reliability. A status page with visible past incidents tends to persuade more than a spotless claim, because experienced reviewers know what a spotless claim usually omits. Incidents: state how you communicate when something goes wrong — who gets notified, through which channel, within what committed timeframe. Buyers are not selecting the vendor that never has an incident; they are selecting the vendor that behaves well during one.
What to leave off
The page loses force through addition. Badges with nothing verifiable behind them; superlatives borrowed from banks and armies that no auditor would co-sign; certifications implied by logo proximity but not actually held; boasts about attacks repelled that mean nothing outside their context. One discovered overclaim converts the entire page from evidence into marketing — and because the trust page is where skeptical readers calibrate your honesty, an overclaim here discounts every other page you publish. This is the one page where under-promising is the winning move: state what is true, date it, name what is missing, and let the absence of varnish do the persuading.