A Trust Center is where a buyer's reviewer goes to answer their own questions before they send you theirs. Done well, it settles the routine requests in one visit. Done badly, it is a page of badges that sends the reviewer straight back to a spreadsheet.
The hard part is not building the page. It is deciding what goes on it, at what level of access, and who keeps each item current. This article works through the content: who reads it, what each reader needs, which documents sit in which access tier, and the mistakes that make a Trust Center less credible than having none.
Who reads it, and what they came for
Several different people will open your Trust Center during one deal, and each has a different job.
The vendor risk analyst is assembling a file. They want the standard documents: your audit report or certificate, a penetration test summary, key policies, sometimes an insurance certificate. They will check dates.
The security architect has specific technical questions. Where is data stored? How is it encrypted? Can we enforce our own single sign-on?
Privacy and legal reviewers want the data processing agreement, the subprocessor list, and how international transfers are handled.
Existing customers come back every year for their own vendor reassessment, usually looking for this year's report.
Design the content around those four jobs. Anything that serves none of them is decoration.
The three access tiers
Every item belongs in one of three tiers: public, gated behind an NDA or approval, or not published at all. The usual placement:
| Item | Usual tier | Why |
|---|---|---|
| Security overview and FAQ | Public | Answers the most common questions with no friction |
| Certifications and attestations held, with dates | Public | Reviewers check this first |
| ISO 27001 certificate | Public | Designed to be shown; includes scope and certification body |
| SOC 3 report, if you have one | Public | Intended for general use |
| Subprocessor list | Public | Privacy reviewers need it early, and many customers expect it |
| Security contact and disclosure policy | Public | Researchers and customers need a route in |
| SOC 2 report and any bridge letter | Gated | Restricted-use report; distribution terms apply |
| Penetration test summary or letter | Gated | Describes your attack surface in some detail |
| Full policy text | Gated | Useful to reviewers, not to the public |
| Completed standard questionnaire | Gated | Detailed answers about your controls |
| Network diagrams, scan output, runbooks | Not published | Operational detail with no review value worth the exposure |
The table is a starting point, not a rule. Some companies publish policy summaries publicly and gate the full text. Some gate the subprocessor list for commercial reasons. Make each decision on purpose and write it down, so the next person adding a document knows which tier it goes in.
Document by document
Audit reports and certificates
State exactly what you hold. For a SOC 2 report, give the type, the trust services criteria covered, and the period. If you are not sure which type buyers will ask about, SOC 2 Type I vs Type II covers the difference. For an ISO 27001 certificate, give the certification body, the scope, and the validity dates. A buyer who discovers later that your certificate covers one office and not the product will not trust the rest of the page.
If your report period ended some months ago, have a bridge letter ready. It answers the question every second reviewer asks: what about the months since?
Subprocessors
List each subprocessor with its purpose, the location where it processes data, and the categories of data it handles. Under GDPR Article 28, a processor working under a general written authorization must inform the controller of intended changes to its subprocessors, so the list needs a way for customers to subscribe to updates. An email address that nobody monitors does not count.
Penetration test summary
Give the date, the scope, the type of test, whether the tester was independent, and the remediation status of material findings. Most buyers do not want the full report and most companies should not hand it out freely. A summary letter from the tester, under NDA, covers the typical request.
Data handling
Say where customer data is stored, whether customers can choose a region, how it is encrypted at rest and in transit, how long it is kept, and what happens to it when a contract ends. These four questions appear in nearly every questionnaire. Answering them publicly removes them from most.
Product security features
Describe what customers can configure: single sign-on, MFA enforcement, roles, audit logs, data export, and deletion. Reviewers need this to understand which controls they will operate themselves. It also reduces the number of questions that are really about features rather than your internal controls.
Legal and privacy documents
Privacy reviewers look for your data processing agreement, and in healthcare deals, whether you will sign a business associate agreement. Publish your standard DPA, or at least say that one is available and how to request it. State which transfer mechanism you rely on for personal data leaving the EU, if that applies to you, and link to your privacy notice. Reviewers who find these in five minutes start the legal track earlier, which often matters more to the timeline than the security track.
Incident response and continuity
A short summary of how you detect, handle, and notify customers about incidents answers a question that appears in almost every review. Do the same for business continuity: say that you maintain a plan, how often you test restores, and where customers can see service status. Keep the detail behind the gate and the commitments consistent with your contracts.
Policies and standard questionnaires
A policy index with one-line summaries can sit in public view, with full text behind the gate. A completed SIG or CAIQ, if you maintain one, belongs behind the gate as well, labeled as a self-assessment with its date.
The FAQ
Build the FAQ from your answer library rather than writing it fresh. That keeps the Trust Center and your questionnaire answers saying the same thing. Building a security answer library covers how to structure the entries so they can feed both.
Keeping it current
A stale Trust Center is worse than none, because it is a public, dated record of your program as it used to be. Give each item an owner and an expiry date. When a new report is issued, the old one comes down the same day. When a subprocessor is added, the list changes before the subprocessor receives data, and subscribers are told.
Put a quarterly check on someone's calendar: open every document, confirm the date, confirm the content still matches reality. It takes less time than answering one questionnaire.
Mistakes that cost credibility
These are the patterns reviewers notice and remember:
Mixing "certified" with "aligned". A row of framework logos where some are audited and some are aspirations reads as deliberately misleading, even when it is not. Separate what an auditor or certification body has confirmed from what you follow internally.
Showing an audit in progress as achieved. "SOC 2 Type II in progress" is a fine statement. A badge with no qualifier is not.
Gating everything. If the subprocessor list and the security overview require an NDA, many reviewers give up and send their questionnaire instead.
Gating nothing. Publishing a restricted-use SOC 2 report openly can conflict with the report's distribution terms. Check them with your auditor.
Marketing language. Adjectives about how secure you are add nothing. The reviewer wants the mechanism, the scope, and the date.
How TrustLynce helps
A TrustLynce Trust Center holds your public content and your gated documents in one place, with an access log showing who viewed what. Questionnaire automation answers from a reviewed answer library, which can be the same source your Trust Center FAQ is written from.