By Mehdi HassanWhich trust pages does a B2B SaaS website need?
A B2B SaaS website needs trust pages that answer the questions of everyone who must approve a purchase, not just the person who wants to buy. That usually means a security page, a trust center or compliance summary, a status page, privacy and legal pages, a data processing agreement, a subprocessor list and an accessibility statement.
The champion who found your product reads the home and product pages. Their security team, legal counsel and procurement lead read something else entirely, often weeks later, with a checklist in hand. If they can't find answers, they send a questionnaire, and the deal waits. This checklist is written from that reviewer's side. For where these pages sit in your overall structure, see our website information architecture guide.
Trust page | Who reads it | What they look for |
|---|---|---|
Security overview | Security team | Encryption, access control, hosting, incident response |
Trust center / compliance | Security and procurement | Certifications held, audit reports on request, policies |
Status page | IT and operations | Current uptime, incident history, how incidents are reported |
Privacy policy | Legal and privacy | What data you collect, why, and how long you keep it |
DPA and subprocessors | Legal and privacy | Data processing terms and every third party that touches data |
Terms of service / MSA | Legal and procurement | Liability, renewal, termination, governing law |
Accessibility statement | Procurement and public-sector buyers | Standard you target, known gaps, contact for issues |
What is the B2B website trust pages checklist?
Work through this checklist in order. The first items are needed by almost every B2B company that sells to businesses with a security or legal team; the later ones matter more as you move upmarket.
- Privacy policy and terms of service. Required from day one. Make them readable, dated and linked from every page footer.
- Security overview page. A plain-language summary of how you protect customer data: hosting, encryption in transit and at rest, access control, backups, employee access and incident response.
- Data processing agreement. A published DPA, or a clear way to request one, for customers subject to GDPR or similar laws.
- Subprocessor list. Every third party that processes customer data, what it does and where, with a way to get notified of changes.
- Status page. A public page showing system status and incident history, linked from the footer and your app.
- Trust center or compliance page. The certifications and attestations you actually hold, how to request reports, and your key policies.
- Accessibility statement. The standard you target, known limitations and a contact for accessibility issues.
- Responsible disclosure page. How security researchers can report a vulnerability to you.
- Enterprise or procurement page. Optional, but useful: SSO, roles, audit logs, data residency and how to start a security review.
What should a SaaS security page include?
A SaaS security page should explain, in plain language, how you protect customer data and how a reviewer can get more detail. It's not a marketing page, so keep it factual and specific, and avoid adjectives that can't be checked.
- Where data is hosted and which cloud provider and regions you use.
- Encryption in transit and at rest, in plain terms.
- How employee access to customer data is controlled and logged.
- Authentication options for customers, such as SSO and two-factor authentication.
- Backup, recovery and incident response, including how customers are notified.
- A named contact or form for security questions and questionnaires.
Our guide to the SaaS security page you need before your first enterprise deal goes section by section. For industries with sensitive employee or health data, the bar is higher; our article on the HR software trust and compliance page shows an industry-specific version.
Do you need a trust center or just a security page?
Most companies should start with a security page and add a trust center when enterprise deals become regular. A trust center gathers security, compliance, privacy, subprocessors and status into one hub, often with gated access to audit reports. It's worth building when reviewers repeatedly ask for the same documents.
Pros
- One place to send every security reviewer
- Lets you share audit reports under NDA without email back-and-forth
- Reduces repeated security questionnaires
- Signals maturity to enterprise and regulated buyers
Cons
- Needs real documents and policies to be worth visiting
- Must be kept current, or it becomes a liability
- Overkill for a seed-stage company with no enterprise pipeline
- Third-party trust center tools add another subscription
Our guide to trust center design covers the layout, the sections and how to handle gated documents.
Why does an accessibility statement belong with trust pages?
An accessibility statement belongs with trust pages because buyers increasingly treat accessibility as a compliance and legal risk, not only a design quality. Public-sector and large enterprise buyers often ask about accessibility in procurement, and legal exposure is growing.
In the US, Seyfarth Shaw counted 3,117 federal website accessibility lawsuit filings in 2025, up 27% on the previous year. In the EU, the European Accessibility Act has applied since 28 June 2025 to businesses selling covered products and services to EU consumers, with an exemption for microenterprises. A clear statement shows reviewers you know the standard you're working to. Our guides to website accessibility compliance and ADA website compliance explain what's actually required.
Where should trust pages live in your site structure?
Trust pages should live in their own section, linked from the footer on every page and from the places buyers start evaluating risk: pricing, the enterprise or plans page and the demo confirmation. Reviewers rarely arrive through the home page; they get a link or search your domain for "security".
- Group them under clear, short URLs such as /security, /trust, /privacy and /legal/dpa.
- Add a Security or Trust column to the footer instead of burying links under Legal.
- Link to the security page from your pricing page's enterprise tier.
- Make sure each page answers its main question in the first paragraph, which helps both reviewers and answer engines; see our guide to answer-first page structure.
Our SaaS website sitemap template shows when each trust page joins the sitemap, from the seed stage to Series B.
For example, suppose a Series A company gets its first enterprise security questionnaire
For example, suppose a Series A SaaS company lands its first serious enterprise prospect. Two weeks into the deal, the prospect's security team sends a long questionnaire and asks for the DPA and the subprocessor list. The company has a privacy policy and terms, and nothing else.
The fastest path is to answer the questionnaire once, carefully, then turn those answers into public pages: a security overview from the infrastructure and access-control answers, a subprocessor list from the vendor answers, and a published DPA. The status page can come from the uptime tool the team already uses.
The next prospect gets links instead of a blank questionnaire, and many of their questions are already answered. The work is the same; it's just done once and published.
How do you keep trust pages accurate?
Keep trust pages accurate by giving each one a named owner, a visible last-updated date and a review on a fixed schedule, plus an extra review whenever your infrastructure, vendors or certifications change. Out-of-date trust pages are worse than missing ones, because reviewers notice the mismatch.
- Assign security pages to engineering or security, and legal pages to whoever owns contracts.
- Update the subprocessor list whenever you add or remove a vendor that touches customer data.
- Review the security page after any infrastructure change or incident.
- Keep the marketing site's own security basics in order too; our guide to website security basics covers them.
