Support Library
Trust Centers: What to Publish and Why
A trust center is a public page that answers the security questions every customer, auditor and procurement team asks: which standards you meet, who handles their data, how to report a vulnerability and whether the service is up. Publishing it saves weeks of questionnaires and shows you take security seriously.
The short answer
Publish one page, linked from your homepage footer as “Security” or “Trust”, that lists your attestations, links your subprocessor list, vulnerability disclosure policy and status page, and offers security documentation (openly or on request under NDA). Add a security.txt file that points to it.
What a buyer looks for
How DNS Panopticon detects it
Security Posture looks for a trust center or security page linked from the homepage, at trust.<domain>, /trust or /security, or hosted on a trust center platform, then reads it for each item below. Each missing item costs points on the Trust Center card. Pages that load their content with JavaScript cannot always be read; items not found elsewhere are then reported as unknown rather than missing.
| Finding | Severity | When it appears |
|---|---|---|
| No trust center or security page found | 25 points | Nothing linked from the homepage and nothing at the usual addresses. |
| No compliance attestations named | 20 points | No SOC 2, ISO/IEC 27001, PCI DSS, FedRAMP or similar is named. |
| No vulnerability disclosure policy found | 15 points | No policy telling researchers how to report flaws, including a Policy line in security.txt. |
| No subprocessor list found | 10 points | No list of the third parties that handle customer data. |
| No status page found | 10 points | Nothing links to a status page and status.<domain> is not on a status page service. |
| No security documentation found | 10 points | No whitepaper, policies, penetration test summary, DPA or questionnaire answers (CAIQ, SIG, HECVAT). |
| … couldn’t be read | Not graded | The page or item exists but its text could not be read. |
The security.txt part of this card is explained in security.txt.
How to check it yourself
| Command or page | What to look for |
|---|---|
| curl -sI https://trust.example.com | Whether a trust subdomain answers. |
| curl -sI https://example.com/security | The same for a /security or /trust path. |
| curl -s https://example.com/.well-known/security.txt | Contact and Policy lines, which should point to your disclosure policy. |
Then read the page as a customer would: can you find each item in the table above within a minute?
What to publish
| Item | What it is | Why buyers ask |
|---|---|---|
| Attestations | SOC 2 Type II, ISO/IEC 27001, PCI DSS, HIPAA, FedRAMP and similar, with the audit period or certificate. | Independent proof that controls exist and work. |
| Subprocessors | Every third party that processes customer data, what it does and where, with a way to subscribe to changes. | GDPR Article 28 and most data processing agreements require it. |
| Vulnerability disclosure policy | How to report a flaw, what is in scope, and a promise not to take legal action against good-faith researchers. | CISA, ISO/IEC 29147 and the EU Cyber Resilience Act expect one. |
| Status page | Live service status and incident history, usually at status.<domain>. | Shows how outages are handled and communicated. |
| Security documentation | Whitepaper, policy summaries, penetration test summary, DPA, CAIQ, SIG or HECVAT answers. | Answers most questionnaire questions in advance. |
Why it matters
- Sales speed. Security reviews are a common reason enterprise and public sector deals stall. Ready answers shorten them.
- Researchers know where to go. A disclosure policy turns a found vulnerability into a report, not a public post.
- Regulation. Subprocessor transparency and vulnerability handling are becoming legal expectations, not just good practice.
How to build one
- Start simple: a /security page with the items above is enough. A platform is optional.
- Link it from the footer of every page, and from security.txt with a Policy line.
- Write the disclosure policy from an established template such as CISA’s or disclose.io’s, and name a monitored contact.
- Publish the subprocessor list and offer email notice of changes.
- Set up a status page on a separate service, so it stays up when your platform is down.
- Gate sensitive reports, such as the full SOC 2 report, behind a request form or NDA, but say that they exist.
- Keep dates current. An expired certificate or a two-year-old pen test summary does more harm than good.
FAQ
We are too small for SOC 2. Is a trust center still worth it?
Yes. A clear security page with your practices, subprocessors, disclosure policy and status page answers many questions without an audit, and the attestations finding is only one part of the card.
Our trust center is on SafeBase and the finding says it couldn’t be read.
Hosted platforms often load content with JavaScript, which DNS Panopticon cannot run. Those items are reported as unknown and cost nothing. Linking the main items, such as the subprocessor list and policy, as plain pages makes them readable.
Does DNS Panopticon check our SOC 2 report?
No. It only checks that an attestation is named. Customers should ask for the report and check its scope and period.
Sources and further reading
- RFC 9116: security.txt
- ISO/IEC 29147: Vulnerability disclosure
- CISA: Vulnerability Disclosure Policy Template
- disclose.io: safe harbor policy templates
- GDPR Article 28: Processor: subprocessor authorisation
- AICPA: SOC 2
- ISO/IEC 27001
- Cloud Security Alliance: STAR registry and CAIQ