BlogThe trust centre is the new landing page: the case for security transparency
Trust

The trust centre is the new landing page: the case for security transparency

Your buyer's security reviewer can read your trust centre before speaking to sales. Why to run it like a landing page, not a shelf of badges.

Harry WestFounder & CEO28 March 20268 min read
Inside This Article
The usual view: a compliance page you publish once you're certifiedWhy regulated buyers read you so closelyWhat the reviewer is actually looking forA landing page has one jobThe strongest objection: publishing more invites attackWhat to do about itThe page your buyer reads first
Book a discovery call

Key takeaways

Security transparency is a sales decision, not a disclosure risk. A regulated buyer's reviewer can read a supplier's trust centre before any sales contact, and UK and EU rules tell that buyer not to stop at the badge. Run the trust centre like a landing page: one job, a named owner, kept current and dated, and judged by whether deals move.

The thesis
For a supplier to regulated buyers, the trust centre is the landing page for the person who decides the deal. Its one job: let the reviewer move you to the next stage.
PRA SS2/21
In material outsourcing, the PRA expects banks and insurers not to assume a supplier certificate's mere existence is sufficient evidence, and wants assurance information kept up to date.
FCA SYSC 8.1
A firm that outsources a critical or important function remains fully responsible for its regulatory obligations and is expected to use due skill, care and diligence in the arrangement.
DORA reach
Article 28 requires EU financial entities to do all due diligence on ICT providers. It does not bind UK suppliers directly but reaches them through EU customers' contracts.

Security transparency is a sales decision, not a disclosure risk. If you sell into banks, insurers or other regulated firms, the most important page on your website isn't the homepage. It's your trust centre. The buyer's security reviewer can read it before anyone has spoken to your sales team, and what it shows, or leaves out, shapes the view they bring to the review. Treat it as a shelf of compliance badges and you leave that first judgement to chance. That is where a stalled security review can begin.

I spent four years as a financial services CISO, deciding whether technology suppliers passed or failed, so I know what that reviewer is actually looking for. Here's what I think most suppliers get wrong about the page they can read first, the best argument against my view, and what I'd change.

The usual view: a compliance page you publish once you're certified

The usual view is that a trust centre is a record. You put your certificates and policies on it once you have them, security owns it, and every extra detail you publish is one more thing an attacker or a competitor can read. So the page stays thin, and less feels safer.

That view is reasonable. It's also incomplete, because it treats the page as a filing cabinet. The buyer reads it as evidence. And regulated buyers are told, in writing, not to stop at the badge.

Why regulated buyers read you so closely

Because their regulators require it. A UK bank or insurer that relies on you stays responsible for the outcome. It has to show that it checked you properly before signing and that it keeps checking afterwards. Your trust centre is the first evidence its reviewer can gather without asking you for anything.

The rules are specific:

  • FCA. Under the outsourcing rules in SYSC 8.1, a firm that outsources a critical or important function "remains fully responsible for discharging all of its obligations". It is expected to use "due skill and care and diligence" when it enters into and manages the arrangement.
  • PRA. Supervisory Statement 2/21 expects banks and insurers to check a provider's "ICT controls and security" before a material outsourcing. It also tells them not to assume that a certificate's "mere existence or provision is sufficient evidence". It wants that information up to date, and it encourages online, real-time reporting tools.
  • DORA. For EU financial entities, Article 28 of Regulation (EU) 2022/2554 requires "all due diligence on prospective ICT third-party service providers". It also restricts them to providers that "comply with appropriate information security standards", and Article 30 sets what the contract must contain. DORA doesn't bind a UK supplier directly. If your customers include EU banks or insurers, it reaches you through their contracts with you.

Outside financial services, buyers hear the same message. The NCSC's supply chain security guidance sets out 12 principles "to help you establish effective control and oversight of your supply chain".

Read those together and the badge shelf looks different. The regulator has told your buyer that the badge isn't enough on its own. So the reviewer goes looking for the rest.

What the reviewer is actually looking for

The reviewer wants to know how you run security, not whether you own a certificate. From the buy side, I'd put it this way: a trust centre earns credit when it answers the questions a reviewer would otherwise have to ask, and loses it when it raises new ones.

Five things carry the most weight:

  • Currency. A page with dates on it, recently changed, tells the reviewer someone is looking after it. An undated page tells them nothing, and they assume the worst.
  • Specifics over logos. A logo says an assessment happened once. A plain description of what is in scope, and how the main controls work, says you understand your own environment. If you publish an assurance report under NDA, the reviewer will go straight to its scope and exceptions, so know how a SOC 2 report is read before you share one.
  • Honest scope. Say what your certificates and reports cover, and what they don't. A certificate's scope statement is read closely. Work that is in progress, marked as in progress, reads as candour. A gap the reviewer finds later reads as concealment.
  • A named contact. A person who answers security questions, not a generic form. It signals that someone owns this.
  • Consistency. What the page says has to match the documents you send later and the answers you give when the security questionnaire arrives. A mismatch costs more trust than a gap you admitted up front.

None of this is exotic. It is what a reviewer needs to move you to the next stage.

A landing page has one job

A good landing page has one job, an owner, a reason for people to come back, and a measure of whether it works. Run as a badge shelf, a trust centre has none of the four. That is the change I'm arguing for.

One job. Let the reviewer move you to the next stage of their process. Everything on the page should serve that conclusion. Anything that doesn't is noise.

An owner. Someone whose name is against it, who sits with revenue as well as security. Security knows what is true. Sales knows which deals are waiting and what the reviewers in them keep asking.

A reason to come back. A regulated buyer has to keep monitoring you after the contract is signed, so its reviewer will be back. A dated record of what changed gives them something to read when they do.

The right measure. Visits tell you little. The better question is whether deals move: whether reviews start further along, and whether the first round of follow-up questions gets shorter.

This is where the Enterprise Trust Gap opens: the distance between what a firm can prove about its security and what a buyer needs to see before saying yes. For a tech firm selling into regulated buyers, the trust centre is where that gap is first measured. That is why I say trust is market access infrastructure, not overhead.

The strongest objection: publishing more invites attack

Here is the best case against me. Every detail you publish is information an attacker can use. The NCSC itself warns that "attackers have both the intent and ability to exploit vulnerabilities in supply chain security". A detailed trust centre also invites more scrutiny from buyers, because each claim becomes something to test. Better, the argument goes, to say little and answer questions privately.

It's a fair concern, and it confuses transparency with exposure. A reviewer needs your conclusions, not your configuration. They need to know that you encrypt customer data, test your recovery and review access. They don't need firewall rules or network diagrams on a public page. Publish your posture openly, keep the detailed evidence behind an NDA, and never publish what would help an attacker. That split is a method, and it's a well-worn one.

As for scrutiny, it comes either way. A regulated buyer has to do the due diligence. The only choice you have is whether the reviewer starts from your account of how you run security or from a blank page and a long list of questions.

What to do about it

Five moves:

  1. Give the trust centre a named owner who sits with revenue as well as security. Put it in someone's objectives, not on a shared list.
  2. Decide what the page must let a reviewer conclude, then publish to that. Write the conclusion down first. Cut anything that doesn't support it.
  3. Keep it current and dated. Put a date on every change, so a reviewer can see the page is looked after.
  4. Put it on the sales path. Link it from the first security email and from proposals, not only the website footer. The reviewer should arrive with it already open.
  5. Use a method for what to publish, what to gate and what never to publish. Our guide to running a trust centre covers it.

We run what we sell. GRCMANA publishes its own trust centre at trust.grcmana.io, with an overview of our controls and policies, an updates feed and an FAQ. Fuller documentation is available on request under NDA.

The page your buyer reads first

Security transparency isn't a risk to manage. It is how a supplier gets through the door. Your trust centre is the landing page for the person who decides your deal, so give it a job and an owner. If you're ready to rebuild yours, start with what to publish and how to run one.

Profile image for Harry West, Founder and CEO of GRCMANA
Author

Harry West

Harry is the founder of GRCMANA, he helps regulated service providers close the enterprise trust gap — turning GRC, cyber resilience and AI governance from paperwork exercises into shippable systems.

GRCMANA
  • About
  • Insights
  • Contact
Ask the Trust ArchitectBook a Call →
  • About
  • Insights
  • The Vault
    Compliance VaultCyber Essentials→ISO 27001→SOC 2→ISO 42001→
    Domain VaultGRC Fundamentals→Risk Management→AI Governance→GRC Engineering→
    Other ResourcesFree Tools→Templates→Newsletter→
  • Contact
Book a Call →Ask the Trust ArchitectFixed fee. ISO 27001 in as few as six weeks.
GRCMANA

Helping high-growth B2B tech startups close the Enterprise Trust Gap through security, governance, and AI resilience.

ISO 27001ISO 42001ISO 9001Cyber EssentialsEU AI Act ReadyNIST AI RMF

The Vault

GRC EngineeringAI GovernanceISO 27001ISO 42001All Vault Resources

Resources

BlogFree ToolsTemplatesNewsletter

Company

About GRCMANAContactPrivacy PolicyTerms & ConditionsCookie Policy
© 2025 GRCMANA · All rights reservedRegistered in England & Wales under company registration 16810805. VAT Registration 506308024