SaaS trust center: the security page that shortens enterprise deals
Before a B2B buyer signs, their security team will look for proof. A clear trust center answers most of their questions before they send you a long questionnaire.
By the Xuru Technologies team · 25 October 2026
Key takeaways
- A SaaS trust center is a public page (or small hub) that explains how you protect customer data, what you have been audited for and how to report a problem.
- Be precise about status: "SOC 2 Type I report available" and "Type II audit in progress" are very different claims, and buyers will check.
- The essentials are a security overview, compliance status, subprocessor list, data processing terms, a status page link and a vulnerability disclosure route.
- Gate sensitive documents (audit reports, pen-test summaries) behind an NDA request form, but keep the overview public.
- Keep it current. A stale trust center does more damage than no trust center.
What is a SaaS trust center?
A SaaS trust center is the page on your website where security, privacy and compliance information lives. Some companies call it a security page, a trust portal or simply /trust. Whatever the name, its job is the same: give a buyer's IT, security and legal reviewers what they need to approve your product without a week of back-and-forth email.
For an early-stage startup this matters more than it seems. Your champion inside the customer may love the product, but procurement will not move until security signs off. If your website shows nothing on the subject, the reviewer assumes the worst, or simply sends the longest questionnaire they have. A well-structured trust center does not replace due diligence, but it sets the tone: this team takes data seriously and is organized enough to prove it.
Who actually reads it
Write for three readers at once:
- The security reviewer wants specifics: encryption, access control, logging, incident response, audits and who your subprocessors are.
- The legal or privacy reviewer wants your data processing agreement (DPA), data residency options, retention and deletion terms.
- Your champion wants a single link they can forward internally to say "they have this covered."
That third reader is why plain language matters. Lead each section with a one-line summary, then link to the detail.
What to include: the trust center checklist
You do not need every item on day one. Use this as a staged plan.
| Section | What to show | Stage |
|---|---|---|
| Security overview | Hosting provider and region, encryption in transit and at rest, authentication (SSO, MFA), access controls, backups | From launch |
| Compliance status | Audits completed, in progress or planned, with dates and exact report type | As soon as you start one |
| Subprocessors | Named vendors that process customer data, their purpose and location, and how you notify changes | From first paying customer |
| Privacy and DPA | Privacy policy, a downloadable or request-based DPA, data residency options | From first paying customer |
| Vulnerability disclosure | How researchers report issues, a security contact and a security.txt file | From launch |
| Status and incidents | Link to a public status page and your incident communication approach | From launch |
| Document requests | Form to request audit reports, pen-test summaries or a completed questionnaire under NDA | Once you have documents |
| FAQ | Short answers to the questions sales hears most often | Ongoing |
The security overview
Describe controls in concrete terms. "We use industry-standard security" tells a reviewer nothing. "Customer data is hosted on [provider] in [region], encrypted in transit with TLS and at rest, and production access requires SSO with MFA and is logged" tells them exactly what to tick. Only state what is true today; if something is on the roadmap, label it as planned.
Compliance status, stated precisely
SOC 2 is the attestation most US buyers ask about. It is built on the AICPA's Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy, of which security is the only criterion required in every SOC 2 audit. There are two report types. A Type I report looks at whether controls are designed properly at a single point in time, while a Type II report covers an observation period, typically 3 to 12 months, and both are performed by an independent service auditor or CPA firm.
On your page, say exactly which you have and when it was issued. In the UK and Europe, buyers often ask about ISO/IEC 27001 certification instead, so if you sell there, say whether you hold it or are working towards it. Never display a badge you have not earned. That is the fastest way to lose a deal, and potentially to create legal exposure; ask a lawyer or compliance adviser if you are unsure what you can claim.
Pre-empt the questionnaire
Many reviewers start from a standard questionnaire. The Cloud Security Alliance's CAIQ is one widely used example: CSA describes it as "an industry-accepted way to document what security controls exist in IaaS, PaaS, and SaaS services", and providers can publish completed versions to its public STAR Registry. Filling one in once, and offering it on request, can save your team hours on every deal.
Add a security.txt file
This is a small, technical detail that reviewers notice. RFC 9116 defines a standard file at /.well-known/security.txt that tells researchers how to reach you. According to the RFC, it must be served over HTTPS and must include a Contact field and an Expires field, with the expiry date set less than a year ahead. A Policy link to your disclosure policy is recommended. Put a reminder in your calendar to renew the expiry date.
Public or gated: what to put behind a form
A good rule: anything that helps a buyer decide whether to proceed should be public; anything that would help an attacker should be gated.
| Keep public | Gate behind NDA or request |
|---|---|
| Security overview and principles | Full SOC 2 or ISO audit reports |
| Compliance status and dates | Penetration test summaries |
| Subprocessor list | Detailed architecture diagrams |
| Privacy policy and DPA terms | Completed security questionnaires |
| Status page and disclosure policy | Internal policies (incident response, access review) |
Make the request form short: name, work email, company and which documents they need. Route it to someone who replies within a business day. Slow responses here quietly stall deals.
Designing the page so it gets read
- Link it from the footer and from your pricing and demo pages. Reviewers look for "Security" or "Trust" in the footer first. If you have a demo request page, add a line such as "Security review? See our trust center."
- Use a summary grid at the top: hosting region, encryption, SSO, audit status, last updated date.
- Show a "last reviewed" date on every section.
- Keep it fast and accessible. Enterprise reviewers may also be checking accessibility; our guide to SaaS accessibility and VPATs covers that side.
- Match your brand. A trust center that looks bolted on undermines the message. Our Pulse SaaS template shows how a security section can sit naturally in a product site.
Build it yourself or use a platform?
Compliance automation tools often include a hosted trust center that updates from your monitoring data. That can be a sensible choice once you are mid-audit. Before then, a well-written page on your own site is enough and keeps you in control of the wording. Many startups do both: a branded /trust page on their website that links to a hosted portal for gated documents. Either way, someone on the team should own it and review it each quarter.
Frequently asked questions
Do we need SOC 2 before we can have a trust center?
No. Start with an honest security overview, a subprocessor list and a disclosure contact. Add audit status when you begin one, stating clearly whether it is planned, in progress or complete.
Should we publish our subprocessor list?
Most B2B SaaS companies do, because buyers' DPAs usually require it and it saves repeated requests. Include each vendor's purpose and location, and explain how customers are notified of changes. A privacy lawyer can confirm what your contracts require.
Where should the trust center live: subdomain or subfolder?
A subfolder such as /trust or /security is simplest to find and to maintain on your main site. A hosted portal on a subdomain works too; just link it clearly from your footer.
How often should we update it?
Review it at least quarterly and whenever you add a subprocessor, complete an audit or change hosting. Show the last-reviewed date so buyers know it is current.
Give buyers a trust center that closes the loop
We'll design a sample of your trust and security pages before you commit, with a fixed written quote for the build.
Websites, payments, digital marketing, AI automation, consultancy and practical technology training — for businesses and aspiring professionals worldwide.
Saturday – Sunday: closed