Trust center or trust page? What to publish for buyer security reviews.

A trust center is a page or portal where a software company publishes its security, privacy, and compliance evidence for buyers to check without a sales call. Security review is the most cited source of delay in B2B software purchases, so this guide shows SaaS marketing leads and founders what to publish, what to gate, and where, as of October 2026.

What is a trust center, and how is it different from a trust page?

A trust center is a centralized hub for security and compliance information: certifications, audit reports, policies, subprocessors, and a way to request documents gated behind a non-disclosure agreement (NDA). A trust page is one page on your marketing site that summarizes those facts in plain language and points to the evidence. Many companies run both.

The difference is depth and access. A trust page answers "do they take security seriously?" in two minutes. A trust center gives a security reviewer, a legal team, or procurement self-serve access to the key documents they need for due diligence, without the back and forth over email.

Atlassian shows the combined model: a trust center at atlassian.com/trust plus a separate trust portal for vendor risk documentation. Webflow keeps its security documentation in a hosted trust center at trust.webflow.com, where reviewers request access.

When is a trust page enough, and when do you need a trust center?

A trust page is enough until you hold audit reports that buyers can only read under an NDA, or until the same document requests reach your inbox every week. Once you have a SOC 2 Type II report and enterprise deals in the pipeline, a trust center with gated access saves time on both sides and signals operational maturity.

Waiting has a cost. In G2's buyer research published July 22, 2026, based on more than 1,000 B2B software buyers, IT security review was the single biggest source of delay in software purchases. 39% of buyers named it, and so did 50% of enterprise buyers.

Signs you have outgrown a trust page:

• You hold a SOC 2 Type II report or an ISO/IEC 27001 certificate that prospects ask for.
• Sales sends the same PDFs by email after most first calls.
• Security questionnaires arrive faster than your security team can answer them.
• You sell to EU customers, and their legal teams ask for your subprocessor list and data processing agreement.

If you are earlier than that, keep the trust page honest about your security and compliance posture: explain how you handle customer data and name a security contact. "SOC 2 Type II audit in progress" is a fine line if it is true. Transparency builds customer trust only when it is accurate: a badge you have not earned costs you the deal the moment a reviewer asks for the report.

What security documents should a trust center include?

Start with the security documentation reviewers ask for first: certifications and audit reports, a completed standard questionnaire, a penetration test summary, core security policies, a subprocessor list, your data processing agreement, a system status page, and a way to report vulnerabilities.

List every certification you actually hold, such as SOC 2, ISO certifications, or PCI DSS if you take card payments, with its date. A few items need more than a table row:

• Questionnaire. The Cloud Security Alliance (CSA) released version 4.1 of its Cloud Controls Matrix on January 28, 2026, and the matching Consensus Assessments Initiative Questionnaire (CAIQ) has 283 questions. Posting a completed CAIQ to the STAR Registry, which CSA describes as publicly accessible, is its complimentary Level 1 self-assessment.
• Subprocessors. The European Data Protection Board's Opinion 22/2024, adopted October 7, 2024, says controllers should have the identity of all processors and sub-processors readily available at all times. An updated subprocessor list, public and dated, with a change log, is the simplest way to give customers that view of your third-party vendors.
• Vulnerability reporting. RFC 9116 defines a security.txt file at /.well-known/security.txt, served over HTTPS, with required Contact and Expires fields. The Cybersecurity and Infrastructure Security Agency (CISA) asks signers of its Secure by Design pledge to publish a vulnerability disclosure policy with a clear reporting channel and no legal action against good-faith research.
• AI. Atlassian's trust center gives AI its own section. If your product uses AI, say which providers process customer data and whether that data trains their models.

Which compliance documents should be public, and which should sit behind an NDA?

Default to transparency. Publish the security and compliance facts that help a reviewer start: what you hold, when it was issued, what it covers, and how to get the rest. Gate the sensitive documents that show how your controls work in detail, such as the SOC 2 report, penetration test results, and full security policies, behind an access request and an NDA.

The American Institute of Certified Public Accountants (AICPA) draws the same line for audit reports. It classifies SOC 3 reports as general use reports that "can be freely distributed," and says they cover the same areas as SOC 2 without the same level of detail. If your auditor issues a SOC 3, it is the natural public document for your trust center.

Gating has a cost, so make the gate fast. Webflow's help center (updated May 22, 2025) says requests for its security documentation are usually approved within 2 to 3 business days, may require an NDA, and give access for 8 weeks. A smaller vendor in a competitive deal should move faster: decide who approves access requests and how quickly, and have your sales teams share the link at the first call rather than at procurement. Keep as much of the trust center public as you safely can, because every gate adds a step to the review process.

Some things belong on no trust center at all: network diagrams, IP ranges, detailed penetration test findings, and incident reports that name customers. A reviewer who needs them can ask in a call under an NDA.

Where should a trust center live on your website?

Put a short trust page on your main domain, for example at /security or /trust, and link to it from the footer, the pricing page, and every enterprise page. If you run a hosted trust center on a subdomain, the trust page links to it and repeats the key facts as plain text.

This matters for AI answers: if a hosted trust center renders its content with JavaScript, many AI crawlers never see it. A December 2024 analysis by Vercel and MERJ found that none of the major AI crawlers rendered JavaScript, with two exceptions: Gemini, which uses Googlebot's infrastructure, and Applebot. When a buyer asks an AI assistant about your security posture, for example whether you have SOC 2, it can only find answers in text a crawler can read.

What that means for the page:

1. Write each certification as text with its date and scope, not only as a badge image.
2. Answer common questions in plain sentences, such as whether you have SOC 2 Type II, where customer data is stored, and whether customer data trains any model.
3. Keep the trust page indexable and in your sitemap, and keep the gated documents gated.
4. Check that AI crawlers can reach the page. Our post on which AI crawlers to allow in robots.txt covers the settings.

We design websites for B2B SaaS and cybersecurity companies, including trust pages, so we have an interest in the topic. Our guide to the pages a B2B SaaS website needs treats security and trust as a page type of its own, and our cybersecurity website design page covers the version for security vendors.

How does a trust center shorten security reviews and accelerate sales?

A trust center streamlines security reviews by moving the first round of security and compliance questions out of email. That saves internal teams repetitive work and takes a common delay out of the sales cycle. When a reviewer can read your certifications and audit summaries, download a SOC 3, and request the SOC 2 report from one self-serve link, the review process can start on the day of the first call.

Sales teams should share the trust center link in the first follow-up email, before procurement asks, and send existing customers to the same page when vendor reviews come around at renewal.

A trust center will not end security questionnaires, since enterprise and regulated buyers often send their own. A completed standard questionnaire still reduces the volume of custom questionnaires and answers common questions up front. For the wider picture, see what B2B buyers need from your website before they talk to sales.

How do you keep a trust center accurate?

Give every item clear ownership and a review date, and show the date on the page. Stale evidence is worse than none: an expired certificate or an old subprocessor list tells a reviewer that nobody maintains the page, while an actively maintained one builds confidence. Let your security and GRC teams, the people who run governance, risk, and compliance, own the evidence, and let marketing own the page.

A routine that works for most B2B SaaS companies:

1. Show the audit period for each SOC 2 report and the expiry date for each certificate.
2. Replace ISO/IEC 27001:2013 badges. SGS, a certification body, states that 2013 certifications expire or should be withdrawn by October 31, 2025.
3. Keep the Expires date in security.txt less than a year ahead, as RFC 9116 recommends.
4. Renew a CSA STAR Level 1 self-assessment every year, and move from CAIQ v4.0 to v4.1 before CSA stops accepting v4.0 in December 2027.
5. Log every subprocessor change with a date, and notify customers who subscribed to updates.
6. Review the page with the rest of the site each quarter: links, contact address, and request-form routing. Our website maintenance checklist covers the site side.

Questions about trust centers