SaaS Trust Centre: Why You Need One and What to Include in 2026

What is a Trust Centre?

A Trust Centre (or Trust Center, Security Page, or Security & Compliance page) is a public-facing page on your website that documents your security posture, compliance certifications, data handling practices, and how you protect customer data.

For SaaS companies selling to enterprise or mid-market buyers, a Trust Centre is no longer optional. Procurement teams, security reviewers, and legal departments will look for it before they sign a contract. If it doesn't exist, you fail their vendor assessment before the conversation starts.

The good news: a well-crafted Trust Centre doesn't require SOC 2 or ISO 27001. It requires honesty, specificity, and coverage of the topics your buyers care about.

Why Your SaaS Needs a Trust Centre in 2026

Three trends have made Trust Centres table-stakes for B2B SaaS:

Enterprise procurement has formalised. Large organisations now run structured vendor security reviews. A missing Trust Centre triggers a lengthy questionnaire process (or a rejection). A strong Trust Centre cuts that to minutes.
GDPR and global privacy law pressure. Customers — particularly EU buyers — need to verify your GDPR compliance before sharing customer data with you. Your DPA, sub-processor list, and data residency details need to be publicly accessible.
AI features raise the bar. If your product uses AI features (like most SaaS products in 2026), buyers want to know whether their data is used to train models, who the AI sub-processors are, and what your EU AI Act compliance posture looks like.

What Enterprise Buyers Actually Check

Here's what a typical security reviewer will look for when they visit your Trust Centre. Missing any of these creates friction in your sales process:

Section	What They're Looking For	Why It Matters
Certifications	SOC 2, ISO 27001, PCI DSS, HIPAA BAA	Third-party validation of security controls
Data residency	Where is data stored? EU only? Multi-region?	GDPR Chapter V, data sovereignty requirements
Encryption	At rest and in transit, key management	GDPR Art. 32, HIPAA §164.312(e), SOC 2 CC6.7
Pen testing	Frequency, scope, third-party provider	SOC 2 CC7, due diligence standard
Sub-processors	Full list with purpose and data regions	GDPR Art. 28(4), contractual DPA chain
Access controls	MFA, SSO, RBAC, internal access to customer data	Insider threat, SOC 2 CC6.1/CC6.3
Incident response	Do you have a plan? Breach notification timeline?	GDPR Art. 33 72-hour rule, HIPAA BNR
DPA availability	Can we sign a GDPR DPA with you?	GDPR Art. 28 mandatory for processors
Data deletion	What happens to data on cancellation?	GDPR Art. 17, contractual requirement
AI & data usage	Do you use customer data to train AI?	EU AI Act Art. 10, GDPR Art. 5(1)(b) purpose limitation

The 13 Sections of a Strong Trust Centre

1. Quick Summary / Security Highlights

Put your key stats upfront in a scannable card grid. Buyers make a quick first impression judgment. If you have SOC 2 Type II, lead with it. If not, lead with what you do have: data stored in EU, TLS 1.3, annual pen testing, MFA enforced.

2. Certifications & Compliance Frameworks

List every certification with its scope and status. Be honest about "in progress" vs "achieved". A table works well:

SOC 2 Type II: Third-party audit of operational security controls over a 6-12 month period. The gold standard for B2B SaaS.
ISO 27001: International information security management standard. Common requirement for EU government and large enterprise buyers.
PCI DSS: Required if you handle payment card data. Most SaaS companies use a PCI-compliant payment processor (Stripe, Paddle) and qualify for SAQ A.
HIPAA: Required for US healthcare data. Demonstrate that you sign BAAs and have the technical safeguards in place.

No certifications yet? Don't hide it. Write: "We are currently working towards SOC 2 Type II certification. Our expected completion date is [Q3 2026]. In the meantime, here is what we have in place..." Honesty builds trust; vagueness destroys it.

3. Infrastructure & Data Residency

Name your cloud provider(s) and the specific regions where customer data is stored. "AWS" is not enough. "AWS EU (Frankfurt) eu-central-1" is what a GDPR-aware buyer needs. If you offer data residency options (EU, US, etc.), describe the mechanism.

4. Encryption

Specify both at rest and in transit:

At rest: AES-256 (industry standard). Mention key management (AWS KMS, Google Cloud KMS, customer-managed keys if applicable).
In transit: TLS 1.2+ minimum; TLS 1.3 preferred. HSTS enforced. Note if any legacy protocols are disabled.
Database-level encryption: Mention if relevant (field-level encryption for sensitive fields, encrypted backups).

5. Access Controls & Authentication

Enterprise buyers care deeply about insider access to their data. Cover:

MFA enforcement for all internal accounts
SSO availability (SAML 2.0 or OIDC) for customer accounts
RBAC implementation
Principle of least privilege — who can access production, and under what conditions
Audit log of internal access to customer data
Privileged access management (PAM) if applicable

6. Application Security

Cover your SDLC security practices: code review requirements, dependency scanning (Dependabot, Snyk), SAST/DAST tools, vulnerability management process, and patch SLAs (e.g. critical vulnerabilities patched within 24 hours).

7. Penetration Testing

Frequency, scope (external, internal, web app), provider type (named third party if possible), and what you do with findings. If you have a letter of attestation or summary report you share with enterprise customers under NDA, mention that.

8. Vulnerability Disclosure / Bug Bounty

Even a simple responsible disclosure policy (security@yourcompany.com with a 90-day disclosure timeline) is better than nothing. Bug bounty programmes (HackerOne, Bugcrowd) are a positive signal for enterprise buyers.

9. Monitoring & Incident Response

Describe your security monitoring approach (SIEM, alerting, on-call). Most importantly: describe your breach notification commitments. GDPR requires 72 hours to your supervisory authority. Most enterprise contracts require 24-72 hour customer notification. State this explicitly.

10. Data Privacy & GDPR

This section matters enormously for EU buyers:

DPA availability: "We sign GDPR Data Processing Agreements. Request at privacy@yourcompany.com."
Sub-processors: link to your public sub-processor list or include it here
Data retention policy summary
Data deletion on request or account termination (30-day window is standard)
DPO or privacy contact details
Whether you process data as a controller or processor

11. AI & Data Usage Policy

In 2026, this is no longer optional. Address explicitly:

Do you use customer data to train AI models? (If no: say so explicitly. If yes: explain how and with what consent.)
Which AI sub-processors have access to customer data? (OpenAI, Anthropic, etc.)
EU AI Act: what is your risk classification for AI features?
Do you have an AI Acceptable Use Policy?

12. Availability & Business Continuity

Your SLA uptime commitment, where to find your status page, backup frequency and tested recovery, RTO/RPO targets if you have them, and your BCP/DRP approach.

13. Security FAQ

Include 6-10 Q&A pairs that answer the most common questions before they become a questionnaire. Key questions every Trust Centre should answer:

Do you sell or share my data? (No — state this clearly)
Can I sign a DPA? (Yes / how)
Where is my data stored? (Specific region)
Who has access to my data internally? (Access controls summary)
What happens to my data if I cancel? (Deletion timeline)
How do you handle security incidents? (Notification commitment)

Trust Centre vs. Security Questionnaire Responses

A Trust Centre reduces but does not eliminate security questionnaires. Large enterprises with structured procurement (banks, healthcare, government) will still send you a VSAQ, SIG Lite, or CAIQ. The difference is:

Without a Trust Centre: Every question is answered from scratch, taking 2-5 days of team time per questionnaire.
With a Trust Centre: You link to it for ~70% of questions. The remaining 30% are deal-specific (custom DPA terms, data isolation, etc.).

Common Mistakes SaaS Companies Make

Vague security statements. "We take security seriously" with no specifics is worse than nothing — it signals you have nothing concrete to say.
No last-updated date. Buyers need to know the page is current. Include a visible "Last updated: May 2026" date.
Missing sub-processor list. The #1 gap in most Trust Centres. EU buyers need this for their own GDPR compliance.
No contact information. Your Trust Centre must have a security email and a privacy email. "Contact us" with a form is not sufficient.
Burying the DPA. If you offer a DPA, make it easy to find. "Request at privacy@..." is fine, but some companies prefer a self-serve DPA download.

Getting Started: Your Minimum Viable Trust Centre

No SOC 2 yet? No ISO 27001? Here's the minimum viable Trust Centre that will pass most SME-to-mid-market security reviews:

Data stored in EU (AWS eu-central-1 or similar)
AES-256 at rest, TLS 1.3 in transit
MFA enforced for all internal accounts
Annual penetration test by named third party
Responsible disclosure policy with security email
GDPR DPA available on request
Sub-processor list (AWS, Stripe, etc.)
72-hour breach notification commitment
Explicit statement: customer data not used to train AI

Use the ComplyKit Trust Centre Generator to build your page in minutes. It covers all 13 sections above and outputs HTML you can paste directly into your website.