Trust Center: Self-Service Security Evidence

A trust center is a central, usually publicly accessible portal through which a vendor provides its security and compliance evidence in a structured, self-service format – from certificates and audit reports to policy excerpts. Unlike a marketing page, it is aimed at scrutinizing third parties: at customers who, as controllers under Art. 28(3)(h) GDPR, may demand evidence and audits, and at procurement and security teams that must assess their direct suppliers under NIS2 (Art. 21(2)(d) of Directive (EU) 2022/2555). An established reference model is the Microsoft Service Trust Portal, which bundles audit reports from external auditors, pentest attestations and whitepapers – some freely accessible, some only after signing in and accepting a non-disclosure agreement.

The core consists of evidence from independent third parties: the ISO/IEC 27001 certificate, SOC 2 reports, the SOC 3 report – a summary version that may be distributed freely – and, in the German cloud market, the C5 attestation under ISAE 3000; with C5:2026, the BSI published an updated version of the catalogue in April 2026 with 168 criteria across 17 subject areas. Added to this are a well-maintained subprocessor list, summaries of recent penetration tests (management summary or attestation instead of the full report), the availability status or a link to the status page, and excerpts from key policies such as the information security policy. An entry in the public CSA STAR Registry complements this with a standardized self-assessment (CAIQ, Level 1) or an audited Level 2 credential (STAR Certification or Attestation).

For the subprocessor list, Art. 28(2) GDPR sets the framework: further processors may only be engaged with the controller's specific or general written authorization; in the case of a general authorization, the processor must inform the controller of any intended addition or replacement, giving the controller the opportunity to object. Under Art. 28(4), the same data protection obligations must be passed on contractually to every further processor. A robust trust center list therefore states, for each subprocessor, the service provided, the processing location and the date of the last change – and offers a notification subscription that allows the duty to inform customers to be fulfilled verifiably. The details must match the data processing agreements exactly.

Not every document belongs in the public domain: SOC 2 reports are restricted-use reports intended for a defined audience only, and full pentest reports or the Statement of Applicability give attackers needless insight. A tiered model has proven effective: certificates, SOC 3, policy excerpts and the availability status are freely accessible; after email verification come items such as DPA templates and detailed subprocessor information; behind a non-disclosure agreement sit SOC 2 and pentest reports as well as architecture documentation. Trust center platforms implement this with click-through NDAs and logged acceptance – Microsoft, for instance, requires sign-in with an organizational account and acceptance of a dedicated “Non-Disclosure Agreement for Compliance Materials” for its compliance materials. Access should be personal, time-limited and logged.

The value materializes in the procurement and sales process: prospects find standard evidence in self-service instead of requesting it individually, and security reviews start from a complete document set rather than a loop of follow-up questions – shortening review and thus sales cycles. A substantial share of bespoke security questionnaires can be pre-empted by published evidence and standardized self-assessments; the Cloud Security Alliance explicitly names reducing the burden of repeated vendor questionnaires as a purpose of the STAR Registry. At the same time, the portal is a signal of maturity: expired certificates or a neglected subprocessor list generate more follow-up questions there than trust.

A trust center is not a one-off project but a maintained process with a clear owner – usually within the GRC or security team. Defined triggers keep the content current: recertifications and certificate expiry dates, new audit reports, completed penetration tests, and every subprocessor change sufficiently in advance of its effective date so that objection periods can run; versioning and approvals follow the document control of the ISMS. For integration with security questionnaires, the same curated knowledge base serves as the single source of truth: standard catalogues such as the CAIQ structure the answers, and where customers nevertheless send bespoke questionnaires, the answers reference the evidence stored in the trust center instead of releasing content individually all over again.