For a young SaaS company, the first security questionnaire usually arrives at an awkward moment: a promising deal, a buyer's security team, and a spreadsheet of a hundred questions. Many of those questions could have been answered before anyone asked, on a public security page.
A security page does not replace a questionnaire or an audit. What it does is let a buyer's engineers and security reviewers check the basics early, decide you are worth the effort, and arrive at the formal review with fewer surprises. This guide covers what to put on a SaaS security page, including what to say before you hold any certifications.
This is general guidance on website content, not legal or compliance advice. Have anything you publish about security, privacy or compliance checked by the people responsible for those areas in your company.
Who reads the security page
Several kinds of visitor look for a security page:
- Engineers evaluating your product, who want to know how their data is handled before they send you any.
- Security and IT teams at a prospect, doing an early check before the formal review.
- Procurement, looking for evidence that the vendor takes security seriously.
- Existing customers, checking something specific, often after a news story about a breach elsewhere.
Most of them want facts, not reassurance. "We take security seriously" tells them nothing. "Customer data is encrypted at rest and in transit, and production access is limited to named engineers using single sign-on and hardware keys" tells them something they can check.
What to say even before you have certifications
Many startups delay a security page because they do not yet have a formal certification or audit report. That is a mistake. Buyers know early companies may not have them yet. What they want to see is that you have thought about security and can describe what you do.
You can describe:
- Your current practices, in plain terms
- Which cloud providers host your infrastructure
- How you manage access to production systems
- Your approach to backups and recovery
- Your plans for formal audits, only if you are actually working towards them
If you are working towards a certification, you can say so, but describe it accurately. "We are preparing for an audit" and "we are certified" are very different claims.
Data: where it lives, who can see it, how long you keep it
The most common questions are about data. Answer them directly:
- What data you collect through the product
- Where it is stored, including region, if customers can choose
- Who can access it, within your company and among your suppliers
- How long you keep it, and what happens when a customer leaves
- Whether it is used for anything else, such as analytics or, for AI products, training models
For AI products, the training question matters a great deal. State clearly whether customer inputs and outputs are used to train or improve any model, yours or a provider's.
Access, encryption and incidents, in plain words
Cover the main controls briefly:
- Encryption in transit and at rest
- Access control: how staff access production, and whether you support single sign-on for customers
- Monitoring and logging: that you log access and watch for unusual activity
- Incident response: that you have a process, and how you will notify customers if something happens
- Vulnerability reporting: an email address or form for security researchers
Keep the language plain. A reviewer who has read hundreds of these pages will notice vague wording and invented detail.
Subprocessors and contact
List the third parties that process customer data on your behalf, such as cloud hosting, email delivery, payment and analytics providers, and for AI products, model providers. Many buyers need this list for their own records.
Then give a clear contact route for security questions, and a way to request further documentation, such as a completed questionnaire, policies or audit reports where you have them.
What not to claim
A security page can do real damage if it overstates. Avoid:
- Certifications you do not hold, or logos of standards you have not been audited against
- Absolute claims, such as "unhackable", "100% secure" or "military-grade"
- Compliance claims about specific regulations unless your legal or compliance advisers have confirmed them
- Copying another company's page, which may describe controls you do not have
Getting caught overstating security can cost you the deal and your reputation. Stating less, accurately, is always safer.
Keep it current
A security page that was accurate a year ago may not be accurate now. Suppliers change, regions are added, and practices improve. Put a "last updated" date at the top and review the page whenever you change a supplier, add a data region or complete an audit. Ask whoever owns security to sign off each change, the same way you would for the privacy policy.
Where it fits on the site
Make the security page easy to find. Link it from:
- The main navigation or footer
- The pricing page, near any enterprise tier
- The product and developer pages
- Your privacy policy and terms
It should sit alongside your privacy policy and terms of service, which buyers also check, and ideally link to a status page showing uptime.
Two getsites templates include pages for this. Switchyard ($69), made for AI infrastructure and developer tool companies, has a dedicated security page among its twelve pages, next to pricing, developer docs and a changelog. Its positioning is that technical buyers read the docs, pricing and security page first. Relaey ($69), built for B2B operations platforms, has privacy and terms pages among its eight, which you can extend with a security section. Both are native Framer, and one licence covers unlimited sites.
In either template, rewrite the security content entirely around your own practices. Do not leave any sample claim in place that you cannot back up. See Framer templates for SaaS for more.
A security page will not close a deal by itself. A clear, honest one stops the deal stalling for weeks while a buyer's security team tries to work out what you do.