An enterprise buyer’s security team doesn’t take your word for it. Before a contract gets signed, someone on their side has to answer a specific question: can we trust this vendor with our data. A trust page is the document built to answer that question without a phone call, a public page that lays out what audit you’ve completed, what it actually covers, and what a reviewer needs to know before they escalate to a full security questionnaire. Done well, it turns a multi-week back-and-forth into a five-minute read. Done poorly, or skipped entirely, it turns into exactly the multi-week back-and-forth it was supposed to prevent.
What a Trust Page Is (and Isn’t)
A trust page is not your SOC 2 report. The report itself, whether Type I or Type II, is a confidential document produced by an independent auditor, usually 40 to 100 pages, and it’s shared under NDA with customers who specifically request it, not published on the open web. The trust page is a public summary that tells a prospect enough to decide whether requesting the full report, or moving forward with a deal, makes sense, and it’s the page most security reviewers check first before they ever ask you for anything.
That distinction matters for what belongs on the page. Specific control test results, exception details, and auditor findings stay in the report. What the trust page states is scope: which Trust Service Criteria your audit covers, what type of report you hold, the audit period, and a plain-language summary of your control categories, plus practical details a reviewer needs early, like your subprocessor list and how to request the full report.
Type I vs Type II: State It Clearly, Don’t Bury It
The single most important fact on the page is which type of SOC 2 report you hold, because the two mean very different things to a reviewer and conflating them (intentionally or not) is the fastest way to lose credibility with a security team that already knows the difference.
SOC 2 Type I vs Type II
| Type I | Type II | |
|---|---|---|
| What it tests | Controls exist, designed properly | Controls worked effectively over time |
| Audit window | A single point in time | Observation period, 6 to 12 months |
| What it proves | Correctly designed as of audit date | Controls worked in practice, day to day |
| Enterprise weight | A starting point for newer companies | The bar most enterprise buyers require |
A company early in its compliance journey often starts with a Type I report to establish that controls are in place, then moves to a Type II after the first audit period closes. Both are legitimate SOC 2 reports, and stating which one you hold, plainly, near the top of the page, is more useful to a reviewer than any amount of marketing language about how seriously you take security. If you’re mid-transition, holding a Type I while a Type II observation period is running, say that too. A reviewer who finds out later that “SOC 2 compliant” meant Type I when they assumed Type II loses trust faster than a company that was specific from the start.
The Five Trust Service Criteria
SOC 2 is built around five Trust Service Criteria defined by the AICPA, and no audit is required to cover all five. Security is the only one every SOC 2 report includes, since it’s the baseline; the other four are optional add-ons scoped to what’s relevant to your product.
Security (sometimes labeled the Common Criteria) covers access controls, network security, and change management, the baseline every report has. Availability covers uptime commitments and disaster recovery, relevant if your product is infrastructure your customers depend on staying up. Processing Integrity covers whether your system processes data completely, accurately, and on time, relevant for products that calculate, transform, or route data on a customer’s behalf, like a payments or billing platform. Confidentiality covers how you protect data designated as confidential beyond regular access controls, relevant if you handle contracts, source code, or other sensitive business information. Privacy covers how personal information is collected, used, retained, and disclosed, relevant if you process significant volumes of personal data directly, though many SaaS companies handle this through a separate DPA instead of adding Privacy to their SOC 2 scope.
Listing exactly which criteria your audit covers, not just “we’re SOC 2 compliant,” is what lets a reviewer skip a question they’d otherwise have to ask directly. A vendor whose product doesn’t touch uptime-sensitive infrastructure and skips Availability isn’t hiding anything; they’re scoped correctly. The problem is when the page doesn’t say which criteria are in scope at all, forcing the reviewer to ask.
Structuring the Control Summary
The control summary is where most trust pages either build confidence or waste the reviewer’s time with vague reassurance. “We take security seriously” is not a control summary. A useful one groups your actual control categories under headings a security reviewer recognizes and scans for: access control (role-based permissions, MFA enforcement for staff), encryption (at rest and in transit, with the actual standard named, AES-256 and TLS 1.2 or higher rather than just “encrypted”), vulnerability management (scanning cadence and the date of your most recent penetration test), change management (code review and deployment gating), and monitoring (how incidents get detected and who’s on call).
Naming the standard, not just the category, is what separates a page that reads as substantive from one that reads as filler. “Data is encrypted” tells a reviewer nothing they can check a box against. “Data encrypted at rest with AES-256 and in transit with TLS 1.2+” is a specific, verifiable claim, and specificity is the entire point of the page.
- We take security seriously
- Data is protected with industry-standard encryption
- We monitor our systems for threats
- Access is restricted to authorized personnel
- SOC 2 Type II covering Security and Availability, audit period Jan-Dec 2026
- Data encrypted at rest (AES-256) and in transit (TLS 1.2+)
- 24/7 infrastructure monitoring with on-call incident response
- Role-based access control with MFA required for all staff
Subprocessors and Incident Response
A subprocessor list, every third party that touches customer data on your behalf, cloud hosting, email delivery, payment processing, error tracking, belongs on the trust page even though it’s also a DPA requirement under GDPR Article 28. Reviewers cross-check this list against their own vendor risk policies, and a company that discloses hosting on AWS, payments through Stripe, and error tracking through Sentry gives the reviewer something to verify rather than something to ask about. If your vendor relationship also involves processing personal data under a formal agreement, our guide on what to include in a Data Processing Agreement covers the subprocessor notice mechanism a DPA needs on top of what the trust page discloses.
A short incident response summary, how you contain, assess, and notify customers of a security incident, and on what timeline, rounds out the page. It doesn’t need to reproduce your full internal plan, just enough to show a reviewer that one exists and that it includes customer notification, not only internal remediation.
What Happens After a Reviewer Reads the Page
The trust page’s job is to shortcut as much of the security review as possible, but it rarely eliminates it entirely for a deal above a certain size. Understanding where the page fits in that process is what determines whether it’s doing its job.
A well-built page pushes most prospects toward the left branch of that flow: either they’re satisfied by the summary directly, or they request the report under NDA and move on quickly because the summary already told them the report would be relevant to their questions. A vague or missing page pushes almost everyone into a full questionnaire, the slowest and most expensive path for both sides, since it means someone on your team is now answering the same twenty questions by hand that the trust page could have answered in a paragraph.
Keeping the Page Current
A trust page tied to an expired audit period is worse than no page at all, because it signals that the compliance program isn’t actively maintained. The audit period dates need to stay current as new reports are issued, the subprocessor list needs to reflect actual vendors in use (not the list from eighteen months ago), and the pen test date should reflect your most recent test, not your first one. Reviewers who catch a stale trust page don’t give the benefit of the doubt; they read it as evidence the rest of the page might be stale too.
Building the Page
A trust page draws from the same underlying facts your SOC 2 audit and your DPA already establish: which criteria are in scope, what type of report you hold, who your subprocessors are, and how customers request the full report. Our SOC 2 Trust Page generator assembles those facts into a page structured the way a security reviewer expects to scan it, criteria, controls, incident response, subprocessors, and a request path for the full report, so the page is complete on day one rather than missing the detail that turns a quick read into an escalated questionnaire. If you’re also formalizing the data-processing side of a vendor relationship, see our guide on Standard Contractual Clauses vs a DPA for SaaS for how that document works alongside what the trust page discloses.
