Because it says nothing, and saying nothing reads as having nothing. A page with three padlock icons and the phrase enterprise grade security does not answer a single question on a security questionnaire. The reviewer emails you instead, and the deal adds two weeks.
This is one of the highest leverage pages on a B2B site and one of the least designed. It usually gets written once by whoever was free, and never revisited even after the company earns the certifications that would make it credible.
We have built and rebuilt enough of these to have opinions about what belongs on one, so here they are.
It is there to answer a security review before the review starts. The buyer's champion needs to send something internally. If your page gives them a link that satisfies most of the questions, they look prepared and the process moves. If it does not, they have to arrange calls, and every call is a chance for the deal to slow down.
That framing changes what you put on it. You are not persuading anyone. You are equipping an internal advocate with evidence. Marketing language actively works against that, because it is exactly what a security reviewer discounts.
Write it for the sceptical reader. Specific, dated, and boring is the goal.
Three audiences, and they want different things. Security reviewers want controls, certifications and subprocessors. The economic buyer wants to know that this will not become their problem. And increasingly, an AI assistant reads it first, on behalf of someone who asked whether your product is safe to use.
That third reader is new and it changes the format. A model summarising your security posture can only work from what it can parse. A trust page built as a scrolling animation with content injected by script gives it nothing, and it will answer from a third party source instead.
The scale of that gap is measurable. Webflow analyzed the websites of 2,000 companies for a study it published in September 2026 and found the median company appeared in only 16% of the AI answers it would want to be part of, and was cited in those answers just 6% of the time.
Start with certifications and their scope, including which product and which dates. A certification without a date is treated as expired by anyone experienced. Then the subprocessor list, naming each vendor and what data they touch, because this is the item that most often triggers a follow up email when missing.
Next, data handling in plain terms. Where data is stored, whether it is encrypted in transit and at rest, how long you keep it, and what happens when a customer leaves. Then access control on your side: who at your company can see customer data and under what conditions.
Finish with the operational things. How to report a vulnerability, how you communicate incidents, and where uptime is published. Each of these is a small section, and together they replace most of a questionnaire.
Precisely, and never by implication. The AICPA promulgates the professional standards for SOC engagements, and the criteria a SOC report addresses are named as security, availability, processing integrity, confidentiality and privacy. Which of those your report covers is a meaningful difference, and reviewers will ask.
Say what you have, what it covers, and when it was issued. Do not say working towards in a way that reads as achieved, and do not put a certification logo next to text about a different certification. Security reviewers spot this constantly, and it converts an ordinary review into a suspicious one.
If a report is available under an agreement rather than publicly, say so and say how to request it. That is a normal arrangement and stating it plainly is far better than leaving the reader to guess.
Say what you actually do, in detail, and skip the badges. An early company with no certifications can still describe its encryption, its access controls, its backup policy and its vendor list. That is more convincing than a vague page from a company that has certifications but will not discuss specifics.
Anchoring to a public framework helps here. The National Institute of Standards and Technology maintains the Cybersecurity Framework, currently at version 2.0, released in February 2024, to help organizations better understand and improve their management of cybersecurity risk. Saying which framework your practices map to gives a reviewer a structure to read you against.
Be honest about the timeline if you are pursuing something. A sentence saying an audit is underway with an expected window is fine. A page implying you already hold it is not, and it is the kind of thing that ends deals rather than delaying them.
The page itself, no. Gating your security overview behind a form is the single most self defeating pattern in B2B marketing, because it blocks exactly the reader you want to convince and it removes the page from search and AI answers entirely.
Detailed reports are a different matter. It is reasonable to require an agreement before sharing a full audit report or a penetration test summary. The distinction is between a summary that describes your posture, which should be open, and evidence documents, which can be requested.
What we would avoid is a form that promises a security overview and delivers a sales call. That converts a technical reader into an annoyed one, and they remember.
It needs to be readable in raw HTML, which is the version of that question that actually matters. If your content only appears after JavaScript runs, both traditional crawlers and AI systems may see an empty page, and your security posture gets summarised from someone else's blog post.
Beyond that, there is a growing convention of publishing structured context files for AI systems. The llms.txt proposal from Jeremy Howard, first published on September 3, 2024 with a version 2 update on August 10, 2026, describes a Markdown file that points AI clients at the pages that matter. It is a proposal rather than a standard, and it costs very little to include your trust page in it.
Keep the page's structure simple regardless. Real headings that name the topic, one idea per section, and no content hidden inside tabs or accordions that require interaction to reveal. Our guide to website security covers the technical side of what you would be describing.
We would delete the hero. The padlock illustration and the sentence about taking security seriously occupy the space where the certification list should be, and no reader has ever been reassured by either.
Then we would date everything. Last reviewed dates on each section, issue dates on certifications, and a changelog if you have had incidents. Dates are the cheapest credibility signal available and almost nobody uses them.
We would also make sure the page reflects the actual site. It is awkward to publish a page about rigorous security controls on a site with no content security policy and a dozen third party scripts nobody can account for. Our pieces on content security policy and cookie consent cover the two gaps we find most often.
Find the last three security questionnaires you were sent and count how many questions your current page answers. That number is your brief. Most teams discover the page answers two or three out of forty, which makes the work obvious and the priority easy to argue for internally.
Then write the subprocessor list, because it is the item most often missing and the easiest to produce. If you want help structuring a trust page that holds up to a real security review, or making sure it is readable to the systems that now summarise it, we are happy to go through it with you at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.