What to publish on a trust center
Publish what answers a reviewer and does not help an attacker. Gate what is detailed. Date everything.
A trust centre should publish your certifications and report dates, a controls summary, your subprocessor list, where data is stored, your privacy policy, and how to report a vulnerability or incident. It should gate your SOC 2 report, penetration test output, full policies and completed questionnaires behind an NDA. Every public item should carry a date, because a reviewer's first check is whether the page is current.
What sections should a trust centre have?
| Section | Layer | Wording that ends the question |
|---|---|---|
| Compliance status | Public | SOC 2 Type 2, period 1 January to 31 December 2025, issued March 2026. Next period ends 31 December 2026. |
| Data residency | Public | Customer data is stored in AWS ca-central-1 (Montreal). Backups are replicated to ca-west-1 (Calgary). Data does not leave Canada in normal operation. |
| Access control | Public | Production access requires SSO with phishing-resistant MFA and is reviewed quarterly. |
| Encryption | Public | Data is encrypted in transit with TLS 1.2 or higher and at rest with AES-256 using cloud-managed keys. |
| Subprocessors | Public | A table of each subprocessor, its purpose and data location, with a date and a change-notice sign-up. |
| Incident response | Public summary, gated plan | Customers are notified of a confirmed breach affecting their data without undue delay, and within the time their contract states. |
| Vulnerability disclosure | Public | An address such as security@ and a statement of how reports are handled. |
| SOC 2 report, bridge letter | Gated | Available to customers and prospects under NDA. |
| Penetration test | Gated | Letter of attestation from the tester, with date and scope. Never the raw findings. |
| Policies | Titles public, text gated | List policy names and last review dates publicly. |
| Standard questionnaires | Gated | A completed SIG Lite or CAIQ, dated. |
Link your status page and state how you notify customers of security incidents; status pages and incident communication covers the wording.
What should never go on a trust centre?
- Raw penetration test findings. Even remediated ones show how your system is built.
- Network diagrams and internal hostnames. Useful to a reviewer under NDA at most, never publicly.
- Customer names without written permission.
- Claims you cannot evidence. A statement on a trust centre can be quoted back in a contract dispute.
- Expired documents. Replace them or remove them.
What should a Canadian company add?
Canadian reviewers ask three things American templates skip. State where personal information is stored and whether it leaves Canada, name your privacy officer and link your privacy policy, and if you handle Quebec personal information, publish the governance policies Law 25 requires. The data residency, PIPEDA and Law 25 pages have the wording.
Why date everything?
A reviewer checks dates before content. An undated controls statement could be from last month or three years ago, so it is treated as unverified. A dated one tells the reviewer the page is maintained. Date the page as a whole, each report, each policy review and the subprocessor list.
Common questions
Should we publish our full security policies?
Publish policy titles and review dates, and gate the full text. Full policies help a reviewer but also describe your defences in detail, and a reviewer who needs them will accept an NDA.
Should our trust centre name our customers?
Only with written permission. Logos on a trust centre suggest endorsement of your security, which most customers' legal teams will not agree to by default.
How detailed should the controls summary be?
One or two factual, checkable sentences per area. Enough to answer the first question on each topic in a standard questionnaire, not a full policy.
Get your trust centre content written
Providers draft the page from your reports and policies.
Get matched