By Mehdi HassanWhat should a SaaS security page include?
A SaaS security page should answer the first questions an IT or procurement reviewer asks: are you certified, where does our data live, who can access it, who else processes it and how do we reach you about a problem. If the page answers those clearly, the security review starts with trust instead of a long questionnaire.
The page belongs in the main structure of the site, linked from the footer and the pricing or enterprise page. It's one of the trust pages covered in our SaaS website design guide, and it often decides whether a deal moves this quarter or next.
Section | What to include | Pre-SOC 2 | Post-SOC 2 |
|---|---|---|---|
Compliance status | Frameworks, report types and dates | Honest status and timeline | Report type, period and how to request it |
Infrastructure | Cloud provider, regions, data residency options | Yes | Yes |
Encryption | In transit and at rest, key management approach | Yes | Yes |
Access control | SSO, MFA, least privilege, employee access to customer data | Yes | Yes |
Subprocessors | Vendors that process customer data and why | Yes | Yes, with change notifications |
Incident response | How you detect, respond and notify | Summary | Summary plus policy on request |
Vulnerability reporting | Security contact and disclosure policy | Yes | Yes, plus any bug bounty |
Documents | Policies, pen test summary, questionnaires | What you have | SOC 2 report under NDA |
How do you write a SaaS security page before SOC 2?
Before SOC 2, write a security page that describes the controls you actually have and states your compliance status in exact terms. Buyers don't expect a seed-stage company to have every certification. They do expect honesty, and they will check.
Lead with what's real: your hosting provider and regions, encryption, MFA for employees, how access to production is limited and how you handle backups. Then describe your compliance plan with dates you control. Avoid inflated phrases such as "enterprise-grade security" or "bank-level encryption", which tell a reviewer nothing and make them more careful.
Honest wording for each stage
Where you are | Wording that's honest |
|---|---|
Not started | "We're building our security program on the SOC 2 framework. Here's what's in place today." |
Readiness work underway | "We're preparing for a SOC 2 Type I audit and expect to engage an auditor in [quarter]." |
Auditor engaged, Type I | "Our SOC 2 Type I audit is in progress with an independent auditor. We expect the report in [month]." |
Type II observation period | "Our SOC 2 Type II observation period began in [month]. We expect the report in [month]." |
Report issued | "We hold a SOC 2 Type II report covering [period]. Request a copy under NDA." |
What changes on a SaaS trust page after SOC 2?
After SOC 2, the page shifts from describing your plan to helping buyers get evidence quickly. State the report type (Type I or Type II), the period it covers and how to request it, usually through an NDA form or a trust center portal.
This is also the point where many companies move from a single security page to a full trust center, often on a subdomain such as trust.yourcompany.com, with document requests, subprocessor change notifications and a status page link. Our guide to trust center design covers that step, and our guide to displaying SOC 2 and ISO 27001 explains badge placement.
The AICPA publishes rules on who may use its SOC logo and how. Read them on aicpa-cima.com before you add the badge, and ask your auditor if you're unsure.
What is the SaaS security page checklist?
Use this checklist to build or audit the page. Each item is something procurement and IT reviewers regularly look for.
- Compliance status with exact wording, report types and dates.
- Hosting and data location: cloud provider, regions and any data residency choices.
- Encryption in transit and at rest, described plainly.
- Customer-facing controls: SSO, SAML, SCIM, MFA, roles and audit logs, with the plans that include them.
- Internal access: who at your company can access customer data and how that's controlled.
- Subprocessor list with purpose and location, and how customers hear about changes.
- Privacy links: privacy policy, DPA and GDPR or CCPA information where relevant.
- Incident response summary and how customers are notified.
- Vulnerability disclosure: a security email or form and a disclosure policy.
- Document request: a form or portal for the report, policies and questionnaires.
- Owner and last-reviewed date, visible on the page.
Hypothetical example: a Series A startup's first security page
For example, suppose a Series A startup is in its first enterprise deal, and the buyer's IT team sends a long questionnaire. The company has MFA everywhere, encrypted databases on a major cloud provider and a SOC 2 Type II observation period that started recently, but no public page.
The first version of the page would state the observation period start and expected report month, describe hosting, encryption and access in a few short sections, list subprocessors in a table, and add a security contact and a document request form. The sales team then sends the link before the questionnaire arrives. This is illustrative, not a client result.
How should a SaaS security page be designed?
Design the security page for scanning: a short summary at the top, sections with plain headings, tables for subprocessors and frameworks, and a clear button to request documents. Reviewers are often working through a checklist, so let them find each answer in seconds.
- Summary first: compliance status and the three or four controls buyers ask about most.
- Anchored sections: a short table of contents so reviewers can jump to subprocessors or encryption.
- Tables where data is a list: subprocessors, frameworks, regions.
- One action: request documents or contact security, consistent across the page.
- Visible freshness: a last-reviewed date near the top.
Look at how security-focused companies present this in our cybersecurity website examples. If you sell to HR or people teams, our guide to the HR software security page covers employee data concerns specifically.
Who should own the security page after launch?
Your security or engineering lead should own the content, and marketing should own the page itself. The page needs updating whenever a subprocessor changes, a report is issued or a control changes, which is too technical for marketing alone and too easy for engineering to forget.
Set a quarterly review, keep subprocessors in a CMS collection so updates are quick, and show the review date. Our guide to B2B website trust pages covers how security, status and compliance pages work together, and the SaaS website redesign checklist covers what to do when the whole site needs to catch up with an enterprise move.
