Short answer: if you sell SaaS, you are selling trust. A public trust site — separate from your contract — shows enterprise buyers your security posture, uptime history, and compliance status in one place. It closes deals faster than any amount of contract language can.
Since I first wrote about SaaS trust sites, they have gone from a nice-to-have for enterprise-facing vendors to something procurement teams expect before a deal closes. A well-built trust site does what no SaaS agreement can: it communicates your security practices clearly, in accessible language, without requiring a legal review every time someone reads it.
What a SaaS Trust Site Should Include.
A trust site is not a marketing page. It is an operational transparency resource for the security and compliance teams vetting your product. The core elements are your uptime and incident history, your security practices summary, the compliance certifications you hold (SOC 2, ISO 27001, HIPAA where relevant), your subprocessor list, your data processing addendum, your privacy policy, and how to request your security overview or penetration test summary. Pair those with a status page showing live uptime monitoring and a clear path to contact your security team, and you have answered most of enterprise procurement’s standard questions before they ask them.
Salesforce Set the Gold Standard.
Salesforce overhauled its trust site at trust.salesforce.com, with a clean layout organized around Trust, Status, Performance, Security, and Learn. If you want a model for what “good” looks like, start there. The idea is to put the answers to a buyer’s security and reliability questions in one public place, so they do not have to dig — and so you do not have to cram it all into your contract, which is the wrong home for it. As I have written elsewhere, SaaS agreements are not good communication vehicles for operational details that change over time. A trust site is.
You Do Not Have to Build It From Scratch.
Plenty of third-party services will stand up a status and trust site for a reasonable monthly fee. Statuspage (Atlassian) and Status.io are well-established options. In the range of a hundred dollars a month you can publish a credible status and incident history page. Pair it with the security artifacts enterprise buyers now ask for — a SOC 2 report, a security overview, your subprocessor list, your privacy posture — and you have answered most of what a standard procurement questionnaire asks, on your own schedule rather than in a deal crunch.
The Trust Site and the Contract Work Together.
Once you have a trust site, reference it properly in your contracts. A security schedule in your SaaS agreement or your DPA should link to your trust site for current security practices, rather than hardcoding specific technical commitments that go stale when you upgrade infrastructure. That keeps your contract accurate without requiring amendments every time you rotate certificate authorities or change a subprocessor. Building privacy and security in from the start makes the trust site easy to populate and keep current — which is exactly what the privacy by design framework advocates. For the deeper question of where specific security commitments belong — in the contract versus in a living policy — see Are You Selling Trust or SaaS/PaaS?
Common Questions About SaaS Trust Sites.
Q: Do we need a SOC 2 report before building a trust site?
A: No. Build the trust site now and note what certifications you have in progress. A trust site that honestly shows a security roadmap — “SOC 2 Type II audit underway, expected Q3” — is more credible than no trust site at all.
Q: Should the trust site be public or behind a login?
A: The status page and basic security overview should be fully public. Detailed documents like SOC 2 reports are typically provided under NDA on request. A tiered approach — public summary, NDA-gated details — is industry standard.
Q: What happens during a security incident?
A: A well-maintained trust site with a public incident log actually increases buyer confidence because it demonstrates operational maturity and honest communication. Customers who can see your incident history and response process trust you more, not less.
When you sell SaaS, you are selling trust. A public trust site proves it in a form that procurement, legal, and security teams can all verify — faster than any amount of contract language. In the SaaS world, a customer is unlikely to buy if they do not trust you. Carve that in virtual stone. I hope this helps.
Resources:
- Salesforce Trust Site
- Are You Selling Trust or SaaS/PaaS?
- SaaS Agreements Are Not Good Communication Vehicles
- Privacy by Design: A Framework for SaaS and Software Vendors
Disclaimer:
This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.
Discover more from Aber Law Firm
Subscribe to get the latest posts sent to your email.