A Trust Centre is the page a prospect’s security reviewer opens before they decide whether to send you a 200-question spreadsheet. Done properly it removes most of those spreadsheets entirely. Done as a marketing page with a shield icon and the word “enterprise-grade”, it does nothing at all — and reviewers can tell the difference in about eight seconds.

What it is for

Understand who the audience is. It is not your buyer. It is the person their buyer forwards you to: a security engineer, a risk analyst, sometimes a procurement officer working from a checklist. That person has a specific job — establish whether you are a risk worth accepting — and limited time.

They are looking for a small number of concrete facts. If those facts are present, you clear the review. If they are absent, the reviewer defaults to the questionnaire, and you have lost two weeks.

The things that must be on it

In rough order of how often they are the thing that unblocks a deal:

Item	Why it matters
Certifications, with status	Certificate number, accreditation body, scope and expiry. If you are working toward one rather than holding it, say so explicitly — see below.
Sub-processor list	Name, service, country, and the transfer mechanism where data leaves the UK or EEA. Required reading for any GDPR-aware buyer.
Where data is stored and where it is processed	Two different questions. Answering only the first is the most common way to fail a data-protection review.
Security overview	Encryption in transit and at rest, tenant isolation, authentication options, logging and monitoring. Specific, not adjectival.
Sub-processor change notice	How much warning customers get, and how they object.
Document request route	Pen test summary, SOC 2 report, DPA, insurance certificate — behind a form or NDA is fine. A dead end is not.
Incident and breach commitments	Notification window in hours, and who gets contacted.
A named contact	A monitored security address. Not a general sales form.

Say what you are not

This is the part most companies get wrong, and the part that most damages trust when it unravels.

If you are not certified, do not write anything that could be read as claiming you are. “ISO 27001 aligned”, “built to SOC 2 standards” and “compliant with ISO 27001” are all phrases a reviewer has seen used to disguise the absence of a certificate, and they will assume the worst reading. State the position plainly instead: controls aligned to the standard, certification targeted for a named date, not yet certified.

A vendor who says that clearly is more trustworthy than one who is vague, not less. The reviewer’s job is to find out anyway — the only variable is whether they find out from you or from the gap in your answer.

The claim that gets caught most often is data residency. “Your data never leaves the EU” is disproved in one click by a sub-processor list showing a US analytics provider, a US email service, or off-site backups in another region. If your database is in the EU but some processing happens elsewhere, say exactly that. The buyer can accept it under standard transfer safeguards. They cannot accept being told something the next page contradicts.

Gated or open?

A reasonable split: public for everything a reviewer needs to triage you, gated for anything that reveals your internal security posture in detail.

Public: certification status, sub-processor list, data locations, security overview, incident commitments, contact route.
Gated behind a form: penetration test summary letters, SOC 2 reports, detailed architecture, insurance certificates.
Never public: raw pen test findings, unremediated vulnerabilities, internal audit reports, your asset inventory.
Keep the gate light. An NDA request that takes a week to process costs you the deal velocity the page was meant to create.

Keeping it true

A Trust Centre decays. Certificates expire, sub-processors change, a new region gets added, an incident commitment gets renegotiated in a contract and nobody updates the page. Out-of-date is worse than absent, because a reviewer who catches one stale fact stops believing the rest.

Drive the page from the same source as your contracts. If your DPA lists sub-processors and the page lists them separately, they will diverge — and the contract wins the argument.
Put a "last reviewed" date on it, and make that date honest.
Set a calendar reminder for certificate expiry two months out.
Whenever a sub-processor changes, update the page in the same change as the DPA, not afterwards.
Re-read the page after any incident, contract renegotiation or architecture change.

How to structure the page

Reviewers scan rather than read, and they arrive looking for a specific fact. Structure for retrieval, not for narrative.

Put the certification and compliance status at the top, above the fold, stated in a sentence each. That is what most visitors came for, and burying it under a hero banner costs you the eight seconds you had. Below that, short labelled sections a reviewer can jump to: data locations, sub-processors, security controls, incident commitments, document requests, contact.

Use plain headings that match what people search for — “Where your data is stored”, not “Our commitment to your privacy”. Reviewers use in-page search. A heading written for marketing is a heading their Ctrl-F will miss.

One page, not a microsite. Deep navigation is the enemy; a reviewer who has to click four times will email you instead.
Tables for anything enumerable — sub-processors, certifications, data locations. Prose hides facts; tables expose them.
Link to the underlying documents rather than summarising them. Your DPA, SLA and security policy should be reachable, not paraphrased.
Make it printable. Reviewers attach pages to internal risk assessments surprisingly often.
No login to read the basics. Every gate loses a share of visitors, and the basic facts are not secret.

The questionnaire that arrives anyway

A Trust Centre reduces questionnaires; it does not abolish them. Regulated buyers and large enterprises have process obligations that a web page cannot satisfy. What a good page changes is the shape of what arrives.

Instead of 200 generic questions, you get 30 specific ones, because the reviewer has already answered the rest themselves. That is the win, and it compounds: answer those 30 into a reusable library and the next questionnaire is faster again.

When one lands, resist the urge to answer it in the spreadsheet immediately. Check first whether the answer already exists on your Trust Centre or in your library. If it does not, write the answer once in a form you can reuse, then paste it in. Answering directly into someone else’s template is how knowledge gets thrown away forty questions at a time.

Measuring whether it works

This is a sales asset, so treat it like one. Three things worth tracking:

Metric	What it tells you
Document requests per month	Genuine buying signal. A pen test summary request usually means an active security review, and sales should know about it.
Questionnaire length over time	If your average questionnaire is shrinking, the page is doing its job.
Time from security review start to sign-off	The number that actually matters commercially. Track it before and after.
Which sections get read	Tells you what buyers in your market care about — and which section to expand next.

One caution on tracking: be careful what analytics you load onto a page whose entire purpose is demonstrating data discipline. A privacy-conscious reviewer checking your Trust Centre and finding four advertising trackers has learned something you did not intend to teach them.

What it saves you

The return is measurable in two places. Questionnaire volume drops, because a reviewer who can self-serve the basics often decides a full assessment is unnecessary — and when they do send one, they send a shorter one. And sales cycles shorten, because the security review stops being a two-week pause while someone chases your engineers for answers that could have been on a page.

There is a third benefit nobody plans for. Writing the page honestly forces you to find out what is actually true — where the data really goes, who the sub-processors really are, what the notification window in the contract really says. Teams routinely discover, in the act of building this page, that three of those answers were wrong.

Building a Trust Centre That Actually Closes Deals