A trust center is a public page, often with gated documents, where you show customers how you protect their data. To build one, decide what to publish openly and what to gate, collect the documents, write plain answers to common questions, add a security contact, and assign an owner who keeps it current.
Key takeaways
- A trust center cuts repeated questionnaire work by answering common questions once.
- Public content builds trust. Sensitive reports go behind a request and NDA flow.
- Only publish claims you can prove today. Never imply an audit or certificate you do not hold.
- A stale page is worse than none. Give it an owner and a review date.
- A small version live this week beats a perfect one next quarter.
What is a trust center?
It is a single place for security and privacy information that buyers, auditors and security teams can read without waiting for a reply. It usually has an overview, policies, sub-processors, compliance status, a contact route and a way to request reports.
What should a trust center include?
| Section | Public or gated | Content |
|---|---|---|
| Security overview | Public | Hosting, encryption, access control, backups, how you handle vulnerabilities |
| Compliance status | Public | Exactly what you hold, with dates and scope, and what is in progress |
| Reports and test summaries | Gated | SOC 2 report, penetration test summary, shared under NDA |
| Policies | Public or gated | Short plain language versions |
| Sub-processors | Public | Name, purpose, location |
| Privacy | Public | DPA, data retention, how to send a request |
| Incident and status | Public | Link to status page, breach notification approach |
| Security contact | Public | An email, and a security.txt file |
| FAQ | Public | Answers to the questions sales hears every week |
How do you build one, step by step?
- Name an owner and a reviewer. Security plus sales or customer success.
- Collect questions. Take the last 10 questionnaires and note the repeats.
- Gather evidence. Policies, reports, test summaries, architecture notes.
- Decide visibility. Public by default. Gate only what could help an attacker or that your auditor or contracts restrict.
- Write plain answers. Short, specific, no marketing language.
- Be exact on status. For SOC 2, say a CPA firm's report exists, for which period and scope. For anything not done, say in progress or not started.
- Add the contact route. Publish a monitored mailbox and a security.txt file as described in RFC 9116.
- Set up access requests. A form, an NDA step and a named approver.
- Launch and tell sales. Link it in questionnaire replies and email signatures.
- Review monthly. Update sub-processors, report dates and the FAQ.
What mistakes make a trust center fail?
- Logos or badges for audits that are not complete.
- Documents that expired and were never replaced.
- No owner, so changes never reach the page.
- Too much detail about internal tooling.
- No route for a researcher to report a vulnerability.
Should you build it or buy it?
A static page with a request form is enough to start. A product helps when many customers request reports or you need access logging. You can see how one is structured in the trust center walkthrough.
Click through it at your own pace, or open it full screen.
How does a trust center help with questionnaires?
Link to it first in your reply, then answer only what remains. The questionnaire demo shows reuse of earlier answers.
Frequently asked questions
Do we need a SOC 2 report to have a trust center?
No. Start with your security overview, sub-processors and contact route. Add reports when you have them.
What should be gated?
Reports under NDA, detailed penetration test results and anything that reveals sensitive internals.
How often should we update it?
Review monthly and update on any change in sub-processors, hosting, reports or status.
Who owns the trust center?
Security usually owns content, and sales or customer success owns the request workflow.
Sources
- NIST Risk Management Framework overview
- FTC cybersecurity for small business
- GDPR Article 28
- RFC 9116 (security.txt), referenced by name, not fetched for this draft.
Last reviewed: 19 October 2026.
