The first action a procurement reviewer takes after receiving a vendor pitch in 2026 is to type the vendor name plus the word “trust” into Google. If a trust page appears, they read it before any sales call. If nothing appears, the procurement file gets a quiet downgrade and the next vendor on the list gets a closer look.
A trust page is not a marketing surface. It is procurement entry-point infrastructure. This article is a tight playbook for what a B2B SaaS trust page must contain, what evidence to show publicly, what to gate behind an email capture, and what to never display. Sourced from a sampling of trust pages from 2026 across Vanta, Drata, Sprinto, Hugging Face, Linear, Notion, and a handful of SMB B2B SaaS that close enterprise deals.
What a trust page does (and does not) do
A trust page reduces the procurement reviewer’s mental cost of evaluating you from the equivalent of a half-day investigation to a 5-minute scan. It is not a substitute for the security questionnaire (procurement still sends one) but it tells the reviewer in advance which answers will be defensible. The pages that work in 2026 are dense, factual, and machine-readable. The pages that fail are heavy on graphics and light on specifics.
The 9-section trust page anatomy
Section 1: Live security posture grade (above the fold)
The single highest-impact section. Show your current external security posture as a verifiable grade or rating. Example pattern: “External posture grade: A. Last scan: 2 days ago. Verified by SaaSFort.” Link to the verifying scanner’s verification page so procurement can confirm independently.
What to NOT do: a static “we take security seriously” headline. Procurement reviewers in 2026 ignore qualitative claims; they want a number tied to an external verifier.
Section 2: Certifications and attestations
List every certificate you hold with name, scope, issue date, and (if applicable) the certification body’s name. Examples: “SOC 2 Type II, full company scope, May 2026, audited by [firm name]” or “ISO 27001:2022 certificate number 12345, accredited by DAkkS”. Link to a downloadable certificate or the cert-body’s online verification page.
What to NOT do: claim a certification you do not hold, or claim Type II when you have Type I. Procurement reviewers verify; inflated claims are deal-killers.
Section 3: Compliance frameworks supported
List the frameworks your customers may need you to support: GDPR, NIS2, HIPAA, FedRAMP, ISO 27001, ISO 27017, ISO 27018, ISO 27701, PCI DSS, CCPA, DORA. For each, state your readiness level (in scope, certified, supported, not applicable) with a one-sentence explanation.
What to NOT do: a generic “we support all major frameworks” claim. Pick the 4 to 6 most relevant to your ICP and be specific.
Section 4: Sub-processors and data residency
A live list of every third-party processor handling customer data, with location, purpose, and (where applicable) the customer-data category they touch. Updated within 30 days of any change. Plus a clear data-residency statement: where customer data is stored, where it is processed, the lawful basis under GDPR Art. 6.
What to NOT do: hide the sub-processor list behind an email gate. Hidden sub-processor lists are a procurement red flag in 2026.
Section 5: Security controls overview
A concise summary of the technical controls you operate: encryption at rest and in transit (algorithm, key management), authentication (MFA enforcement scope, SSO support), access control (RBAC, principle of least privilege), backup and disaster recovery (RPO, RTO, last DR test date), incident response (24/7 monitoring, IR retainer, last tabletop date).
What to NOT do: dump the entire control matrix on the page. 200+ rows make the page unreadable. Show the 10 to 15 controls procurement asks about most often.
Section 6: Privacy commitments
GDPR-specific commitments: data processor agreement available on request, lawful basis statement, data subject rights workflow, retention policy, data export and deletion mechanisms. Plus the equivalent for other privacy regulations relevant to your customers.
Section 7: Incident history
Either a transparent history of past incidents with what happened, how you responded, and what you changed; or a clear statement “no significant incidents in the last 24 months”. Both options work; silence does not.
Section 8: Vulnerability disclosure programme
A public-facing security contact (security.txt file plus a dedicated email or HackerOne page) and your vulnerability disclosure policy: scope, safe-harbour, response SLA, hall of fame if applicable. Procurement reviewers and security researchers both check this.
Section 9: Documentation request workflow
A clear path for procurement reviewers to request the docs that are not public: SOC 2 Type II report, ISO 27001 certificate (full not just the cover page), penetration test executive summary, internal security policies. Specify which documents require an NDA and which do not, plus the typical turnaround time.
What to show publicly vs gate behind an email
| Document | Public | Email-gated | NDA-gated |
|---|---|---|---|
| Live posture grade | Yes | ||
| Certification cover page | Yes | ||
| Full SOC 2 Type II report | Yes | ||
| Full ISO 27001 certificate | Yes | ||
| Pen test executive summary | Yes | ||
| Full pen test report | Yes | ||
| Sub-processor list | Yes | ||
| Incident response policy | Excerpt | Full | |
| DPA (Data Processing Agreement) | Template | Signed | |
| Internal control matrix | Yes |
The principle: anything that helps procurement decide whether you are worth talking to should be public; anything that contains exploitable detail (pen test findings, specific control implementations) is NDA-gated. Email-gated content is the middle tier where you trade contact info for additional depth.
Where SaaSFort fits in the trust page
The Section 1 live grade is the highest-impact addition for SaaS vendors who do not yet hold a full SOC 2 or ISO 27001 certificate. Embedding a continuously-updated external posture grade (“A, last scan 2026-05-18, verified by SaaSFort”) shifts the trust page from “we promise” to “you can verify”. SaaSFort generates the verification URL automatically.
For SaaS in NIS2 scope, the same grade carries the Article 21 control mapping. Customer questionnaires asking for Art. 21(2)(b)(e)(h)(j) external-posture evidence are answered by the verification URL plus the downloadable PDF.
Run a free SaaSFort scan to baseline your posture grade before designing your trust page. The grade becomes the Section 1 hero element. Pricing from EUR 9 per month covers continuous monitoring and the verification page customers click to confirm.
Common trust page failures (and how to fix them)
Failure 1: Vague claims. “Bank-level security” is meaningless. Replace with specifics: “TLS 1.3 enforced on all customer-facing endpoints; AES-256-GCM at rest; HSM-managed keys”.
Failure 2: Outdated content. Last-updated dates older than 6 months kill credibility. Add a visible “last updated” timestamp on every section and discipline a quarterly review.
Failure 3: Missing sub-processor list. Procurement immediately downgrades a vendor that does not publish sub-processors. Always public.
Failure 4: Pen test report behind a contact-sales form. Move the executive summary to email-gated; keep the full report NDA-gated; do not force a sales call.
Failure 5: No security contact. Add a security.txt file at the root of your domain (RFC 9116) plus a security@ email and a public PGP key. The SaaSFort scan checks for security.txt and flags its absence.
Frequently asked questions
How long should a trust page be?
In 2026 procurement reviewers spend 3 to 5 minutes on a trust page before deciding whether to send the questionnaire. The page must answer their top 10 questions in that window. Length ranges from 1500 words (SMB B2B SaaS) to 5000 words (multi-product enterprise SaaS), but readability matters more than length. Use anchor links so reviewers can jump to the section they need.
Do I need a separate URL for each section?
No, but use anchor-tag deep links. Procurement reviewers cite trust page sections in their internal write-ups. Anchors at /trust#certifications, /trust#sub-processors, /trust#incidents make their work easier and your page more shareable.
Should I include a chatbot on the trust page?
No. Procurement reviewers want to read, not chat. A chatbot is friction. If you must offer interactive help, a clear “request documents” link to a form is enough.
What about a status page?
Status page (uptime and incidents) is separate from trust page (security and compliance). Both should exist. Link from trust to status, not the reverse, because the audiences differ: status reviewers want uptime, trust reviewers want security posture.
My competitor has a fancier trust page than mine. Should I match the design?
No. Match the substance, not the visual polish. Procurement reviewers read trust pages on laptops at procurement standards; visual elaboration does not move them. The vendor whose trust page makes the buyer’s procurement-file-build trivial wins.
Bottom line
A trust page in 2026 is procurement entry-point infrastructure. The 9 sections above plus a live external-posture grade reduce the procurement evaluation cost from a half-day to 5 minutes and turn quiet downgrades into closer looks. The cheapest single improvement is adding a verifiable live grade; the second cheapest is publishing your sub-processor list.
Run a free SaaSFort scan to baseline the live grade. Pricing from EUR 9 per month keeps the continuous-monitoring cost trivial against the cost of a single procurement-stage deal slipping by a quarter.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.