What makes a trust page useful. Written for the person who has to verify it.

The short version: a trust page earns its name when a stranger whose job is to doubt you can leave it with fewer questions than they arrived with. That stranger is not your prospect's CEO — it is a security engineer or a third-party-risk reviewer who will cite what they find in a workpaper or a decision. They cannot cite a badge. They can cite a dated scope, a shareable report, a stated verification method, and a closed-findings log. Build the page for them and the sales value takes care of itself; build it for the logo wall and you have just moved the real work to email.

Who actually reads a trust page

The mistake is imagining a general "customer" audience. Three specific readers do the real work, and each wants something a marketing page does not provide. The auditor is collecting evidence against a control — they need something datable and attributable. The buyer's security team is clearing a vendor before a contract is signed — they are looking for the most recent independent test and the scope it covered. The vendor-risk reviewer is working through a due-diligence questionnaire and wants to replace ten email round-trips with one link. All three share a trait: they are paid to be skeptical, so anything that cannot be checked is treated as unproven.

What a useful trust page contains

Six things. The first two tell a reviewer what you tested and when; the next two let them believe the result without trusting you; the last two show the work reached a conclusion. Teams tend to spend everything on presentation and skip the four that carry weight — which is exactly backwards.

1 · Current test status and dates

The first question in any reviewer's head is "how old is this?" A trust page that does not say when the last penetration test ran, what period an assessment covers, and when the next one is due has failed before the second question. Security posture decays — a clean test from eighteen months ago, across a product that has shipped two hundred releases since, tells a reviewer almost nothing. Dates are what turn a claim into a fact with a shelf life. The failure here is the undated boast: "we are penetration tested" with no "as of," which a competent reviewer reads not as reassurance but as a prompt to ask when, and to assume the worst until you answer.

2 · A scope statement, in plain terms

A result means nothing without the boundary it was measured against. The scope statement says which applications, APIs, environments and identities the test covered — and, just as usefully, what it did not. A reviewer reading "annual pentest" has no idea whether that was the marketing site or the multi-tenant platform where customer data actually lives. Stating scope plainly does two things at once: it lets an honest reviewer size the assurance correctly, and it protects you from the implied over-claim of a narrow test dressed up as a broad one. A narrow scope stated honestly beats a broad scope implied and undeliverable.

3 · Shareable evidence, not a wall of badges

This is the stage that separates a trust page from a trust poster. A compliance logo asserts that, at some unseen moment, an audit happened against a scope you cannot inspect. It is a pointer to evidence, not evidence. What a reviewer actually wants is the thing the logo points at: a shareable report — gated behind an NDA if need be — that shows real findings, their severity, and the state they are in. One readable report under NDA does more for a serious buyer than a dozen badges, because the badges send them back to email asking for exactly that report. See a worked report for what that package looks like when it is built to be read by someone outside your company.

4 · A stated verification and reproduction method

A finding is only as good as the reader's ability to believe it was real. A useful trust page — or the report behind it — says how a candidate issue became a confirmed one: was it reproduced from a clean session, was the impact demonstrated rather than asserted, was there an independent check that the result was not a false positive? This is where most security claims are thinnest, because the honest answer is often "a scanner flagged it and we wrote it down." Stating the method lets a reviewer calibrate: a finding reproduced from a fresh context, with the exact request and a control to compare against, is a different object from a tool hit nobody re-ran. We go deeper on this in how a candidate becomes a finding.

5 · How findings are tracked to closure

A test that ends at a list of problems is a story, not an assurance. What a reviewer is really assessing is not whether you have vulnerabilities — everyone does — but whether you have a working loop: a finding is recorded, a fix ships, and the same test runs again to confirm it actually closed and did not just move. A trust page that shows open versus resolved counts, and the time findings sit before closure, is telling a reviewer something a badge never can: that the organisation metabolises security problems instead of collecting them. The honest version separates attempted from verified and resolved, so a headline number is never inflated by things that were tried but not proven, or found but not fixed.

6 · Honest disclosure — including what is open

The counter-intuitive one. A page that shows only wins reads as curated, and a skeptical reviewer discounts curated evidence automatically. A page that shows a small number of open findings — with a severity, a date, and a remediation target — reads as real, and real is what clears due diligence. Honesty is not a liability here; it is the single cheapest trust signal you can send, because it is the one a theatre page structurally cannot fake. The same instinct governs how the underlying testing should work: a candidate that did not reproduce is held back rather than shipped to pad a count, and a finding that was refuted never gets to call itself a finding. A trust page built on that kind of honest coverage has nothing to hide because it already declined to over-claim.

Useful versus theatre, in one line each

The dividing question is always the same: can the reader verify this without taking your word for it? A date can be checked against a report. A scope can be read and sized. A shared report can be opened and disbelieved. A verification method can be interrogated. A closure log can be counted. A badge can only be trusted — which is precisely why it belongs to the theatre column. Build every element of the page so a hostile reader runs out of things to doubt, and you have built a trust page. Build it to look impressive from across the room, and you have built a poster.

FAQ

What is a security trust page?

A single page where a company states its current security posture for the people evaluating it — auditors, a buyer's security team, and vendor-risk reviewers. A useful one answers the questions those readers would otherwise send over email: what was tested, when, against what scope, what was found, and how it was closed. A page that only shows compliance logos answers none of them.

Who actually reads a trust page?

Not customers in general. The readers who matter are a buyer's security engineer clearing a vendor, a third-party-risk analyst working a due-diligence questionnaire, and an auditor collecting evidence. All three want something they can cite in a decision or a workpaper — and a badge is not citable, while a dated scope and a shareable report are.

Why is a wall of compliance logos not enough?

A logo proves an audit happened at some point against a scope the reader cannot see. It does not say when the last test ran, what was in scope, what was found, or whether it was fixed. A reviewer doing their job treats an unqualified logo as a prompt to ask for the underlying evidence — so a page that stops at logos just moves the work to email instead of removing it.

Want to see the evidence a trust page should point at? Open a worked report, read how a candidate becomes a finding, or book a demo.