Before a buyer's reviewer sends you a questionnaire, they usually search for your company name and the word "security." What they find is your public security page. In a few minutes it tells them whether you are likely to be a straightforward review or a long one, and sometimes which questionnaire to send.
That makes the security page one of the most consequential documents you publish, and it is often the least maintained. It was written when the company was smaller, it lists a certification with no dates, and its encryption section uses adjectives instead of facts. This article covers who reads the page, what belongs on its first screen, the sections that follow, and the patterns that make reviewers trust it less.
How it differs from a Trust Center
The two are often confused, and some companies combine them. They do different jobs.
The security page is a public narrative: a readable summary of how you protect customer data, written for someone forming a first impression. A Trust Center is a document hub: reports, certificates, policies, and questionnaires, many of them gated. What to put on a Trust Center covers the hub. This article covers the page that points to it.
If you have only one, make it the page. A reviewer can request documents. They cannot request a first impression.
Who reads it and what they decide
Four kinds of reader arrive at the page:
A buyer's vendor risk reviewer, deciding how deep the review needs to go and what to request.
An internal champion at the buyer, forwarding the link to their own security team to get ahead of the review.
A security researcher who has found something and wants to report it.
A customer administrator looking for the security features they can turn on.
Each needs something different, and each should find it without scrolling far. The first two decide whether your review is easy or hard. The third decides whether a vulnerability reaches you privately or appears somewhere public. The fourth decides whether your customer's half of the security model actually gets configured.
What belongs on the first screen
The top of the page carries the facts a reviewer checks first:
- Not done:
Assurance held, with specifics. For a SOC 2 report: type, criteria covered, and period. For a certification: the standard, the scope, and the certification body. Each with a date.
- Not done:
Work in progress, labeled as such. "SOC 2 Type II observation period under way, report expected after it ends" is an honest and useful line.
- Not done:
Where to get documents. A clear link to your Trust Center or a request route.
- Not done:
A security contact. An address or form that a person monitors.
- Not done:
A last-reviewed date for the page itself.
That is all. Everything else can sit lower on the page. A reviewer who finds these five items immediately has already decided you are organized.
The sections that follow
After the first screen, order the sections by how often buyers ask about them. A sequence that works for most SaaS companies:
Hosting and data protection. Where data is stored, whether customers can choose a region, how it is encrypted at rest and in transit, and who manages keys. Name the algorithms or standards you use, not a strength adjective.
Staff access to customer data. Who can reach production data, how access is approved, how long it lasts, and whether it is logged.
Security features for customers. SSO, MFA enforcement, roles, audit logs, and data export. Explaining shared responsibility to customers covers how to frame which controls are theirs.
Secure development. Code review, testing, dependency scanning, and how often an independent tester assesses the product.
Incident response. A short summary of how you detect and handle incidents and how you notify customers, consistent with your contract terms.
Availability and recovery. A link to your status page, and a sentence on backups and how you test restores.
Subprocessors and privacy. A link to the subprocessor list, your data processing agreement, and your privacy notice.
Reporting a vulnerability. How to report, what you commit to in return, and what you ask of researchers.
For the last item, also publish a security.txt file at the well-known location defined in RFC 9116. It tells researchers and automated tools where to send reports, and it costs you one small text file.
Writing claims a reviewer believes
Reviewers read security pages skeptically, because they have seen many that overstate. A few habits make yours read as credible.
Describe mechanisms. "Customer data is encrypted at rest with AES-256 using keys managed in our cloud provider's key management service" is a claim a reviewer can check against a questionnaire answer. A sentence about "state-of-the-art protection" is not, and it makes the reviewer wonder what the sentence is covering for.
State scope. "All production databases" and "all employee laptops" are scopes. Unqualified "all systems" usually is not true.
Separate what you operate from what you inherit. Your cloud provider's certifications are theirs. Saying "our data centers are certified" when you operate no data centers is the kind of small overstatement reviewers remember. Say that your infrastructure runs on a provider whose facilities are covered by its own audits.
Keep it consistent with everything else. The page, your Trust Center, your questionnaire answers, and your contracts should describe the same facts in the same way. Some contracts incorporate a security page by reference, so a careless edit can change what you have promised. Security commitments in customer contracts covers why that matters.
Red flags reviewers notice
These patterns reliably turn a short review into a long one:
No dates anywhere. The reviewer cannot tell whether the page describes this year or three years ago.
Badges without detail. A SOC 2 logo with no type, period, or criteria invites the reviewer to assume the least favorable version.
Superlatives about encryption. Strength adjectives with no algorithm or protocol named suggest the writer did not know them.
No security contact. A page about security with no way to report a security problem is a contradiction reviewers notice.
Claims that contradict public reports. If you publish a SOC 3 report, the page must agree with its description of the system.
Marketing ownership only. A page last edited by the web team, with no sign that security reviewed it, often shows in the details.
How long it should be
Long enough to answer the questions above, and no longer. Most good security pages are a few screens of plain text with headings, not a design showcase. If a section needs more than a few paragraphs, the detail probably belongs in a gated document on your Trust Center, with a sentence on the page pointing to it. Reviewers are reading to decide what to request next, and a short page that tells them helps more than a long one that tries to replace the review.
Keeping it current
Give the page an owner in security, not marketing, and a review whenever one of its facts changes: a new report, a new region, a change to incident terms, a new subprocessor category. Write its content from the same approved answers your team uses for questionnaires, so a change made in one place is easy to carry to the others. Have legal review any edit that could read as a commitment.
How TrustLynce helps
A TrustLynce Trust Center gives your security page a place to send reviewers for documents, with gated access and an access log. The reviewed answers behind questionnaire automation can be the same source the page is written from.