A trust center that cannot
say more than the evidence does.

• Readiness per enabled framework, with met, partly met and not met
• Open security-test findings as counts by severity, never their details
• Incident history with status and resolution dates
• Last verified time taken from when scores were last derived
• Private until you publish it; turn it off at any time
• Our own runs live at trytrustable.com/trust

A trust center is a public page where a company shows customers its security and compliance posture: which frameworks it works to, how ready it is, and how to request more. Done well, it answers most of a security questionnaire before it is sent.

Most trust pages are written by marketing and change when someone edits them. This one is generated from the same derived scores your team sees, so it moves when your controls move, including down.

1. Enable your frameworksTurn on the frameworks you work to, such as SOC 2, ISO 27001 or the DPDP Act. Each one brings its requirements, mapped to shared controls you already run.
2. Let the scores deriveReadiness for each framework is computed from control results: requirements met, plus half of those partly met, divided by the requirements that apply. Nobody types the number in, so nobody can round it up.
3. Review before you publishThe trust page is private until an owner publishes it. Check the figures, decide that you are comfortable showing them, and then switch it on.
4. Share one linkSend the link in a sales thread, add it to your website footer or paste it into the first answer of a security questionnaire. Customers see the same figures your team sees.
5. Let it moveWhen a control starts failing, the score falls on the trust page as it does inside the platform. When the fix lands, it rises again. The page also shows when scores were last derived.

Because a list of open findings is a map for an attacker. The page shows how many findings are open by severity, which tells a customer whether you are on top of them, without saying which door is unlocked.

A readiness figure is only worth showing a customer if your own team cannot simply raise it. On most trust pages the security status is written by a person and stays the same until someone edits it, so a buyer learns what the company wanted to say on the day the page was last touched.

Here the figure is computed from the same control results the compliance programme uses, and there is no field to set it. A failing control lowers it, and the page shows when it was last derived. That is less flattering on a bad week and more credible every other week.

A trust page should answer the three questions a security reviewer asks first: which frameworks you work to, how close you are to meeting them, and whether you handle incidents and findings rather than hide them. If those answers are visible, the questionnaire that follows is shorter and the follow-up calls are fewer.

It does not replace the questionnaire. Reviewers still need your policies, your sub-processor list and, for SOC 2, the report itself. The vendor security questionnaire template shows what they usually ask, and the trust link makes a good first answer to it.

Publishing counts is safe; publishing details is not. A count of open high-severity findings tells a customer whether you are on top of your security testing. The title, host and description of the same finding tell an attacker where to look. The page shows the first and never the second.

Incident history works the same way. Customers increasingly ask how incidents were handled, not whether they happened. Status and dates show that you detect, contain and close them; internal notes stay inside the platform.

A SOC 2 report is an auditor's opinion over a past period; a trust page shows your current position. A buyer needs both. The report says an independent firm tested your controls; the trust page says what has happened since. Our SOC 2 Type 1 vs Type 2 guide explains the reports, and our own trust page is at trytrustable.com/trust.

• Which frameworks you are certified against, and which you are working towards
• A current SOC 2 report or ISO 27001 certificate, under NDA
• How you handle security findings and how long fixes take
• Your incident history and how customers are notified
• Your sub-processors and where data is stored
• A completed security questionnaire, often their own format
• Evidence that the answers are current, not last year's

• It does not gate access. Password, invite-only and NDA-gated modes are not available yet; once published, the page is public
• It does not host documents such as your SOC 2 report, policies or penetration test summary for download
• It does not answer questionnaires for you
• It does not let you edit or override a score
• It does not show findings, hosts or control-level detail

Every result here is a control result on the same graph as the rest of the platform, so it reaches each framework that asks for it without being gathered again. Coverage lists the regimes.

Related reading: our live trust report and how readiness is derived.