Trust center versus a security page
Most companies should start with a security page and graduate to a trust centre when reviews start costing real time. Here is where the line sits.
A security page is a static description of how you protect customer data. A trust centre is a security page plus the machinery around it: gated documents behind an NDA, a request and approval flow, an access log, and content such as the subprocessor list kept current on a schedule. You need a security page from the first enterprise conversation. You need a trust centre when reviews arrive often enough that emailing documents and retyping answers costs real hours.
What is the difference between a trust centre and a security page?
| Capability | Emailing documents | Security page | Trust centre |
|---|---|---|---|
| Public answers to common questions | No | Yes | Yes |
| Gated documents behind an NDA | Only if someone remembers | No | Yes |
| Record of who received the SOC 2 report | Scattered through inboxes | No | Yes |
| Subprocessor list kept current | No | Sometimes | Yes, usually with change notices |
| Viewer analytics | No | Web analytics only | Often, by account |
| Effort to set up | None | Days | Two to four weeks with content in hand |
When is a security page enough?
A security page is enough when you get a few reviews a quarter, have no SOC 2 or ISO 27001 report to gate, and can answer the occasional request by hand. It should still be specific: where data is hosted, how access is controlled, whether data is encrypted in transit and at rest, who your main subprocessors are, and how to report a vulnerability. Vague reassurance invites a questionnaire.
When should we move to a trust centre?
- You have a report to share. A SOC 2 report is restricted use. Once you hold one, you need a controlled way to release it.
- Requests repeat. The same prospect asks twice, or three prospects ask the same thing in a week.
- Someone asks who has your report. A customer, an auditor or your board. If you cannot answer from a log, you have outgrown email.
- Deals wait on security. Any deal that slipped because an answer was slow.
How do we write a security page that ends reviews?
Write it the way a reviewer reads: short sections under the headings their questionnaire uses, each with a factual statement and a date. "Production data is stored in AWS ca-central-1 (Montreal) and backed up to ca-west-1 (Calgary)" ends a question. "We take security seriously" starts one. The what to publish page lists the sections, and they carry straight over when you upgrade.
Common questions
Can a security page include a document request form?
Yes, and it is a good halfway step. A form that captures the requester, their company and the document, with your NDA attached, gives you a log without a platform. It stops working when volume means nobody approves requests quickly.
Should the security page and trust centre live on our main domain?
A subdomain such as trust.yourcompany.com is common and makes it clear the page is official. What matters more is that your main site links to it from the footer and from sales emails, so reviewers find it without asking.
Does a trust centre replace our privacy policy?
No. The privacy policy is a legal document you must publish anyway. A trust centre links to it and adds the operational detail: data locations, subprocessors and how requests are handled.
Get help moving from a page to a trust centre
Providers can build on what you already publish.
Get matched