Public vs private trust center: what to share

At a glance

• Choose an audience for each document, not just for the trust center homepage.
• Publish reviewed summaries and public policy links; approve access to sensitive supporting material separately.
• Treat search visibility, document authorization and evidence quality as different controls.
• Assign an owner and observation date to every claim that a buyer may reuse.

A public vs private trust center decision starts with the material you need to share. An AI SaaS may want anyone to read its product scope while limiting detailed security documents to approved buyers. The practical question is which artifact belongs with which audience, and what must be checked before release.

Use the matrix below to define your sharing requirements before choosing a portal or publishing files. It brings document sensitivity, recipient access and evidence freshness into one working record.

Public pages and private documents can coexist

Trust center permissions can control the page and its supporting documents separately. A publicly visible introduction does not require every supporting file to be public. Likewise, restricting the homepage does not by itself describe the permissions on each document URL.

Vanta's Trust Center FAQ documents public views with restricted documents and the ability to combine public and private views. Its access process also distinguishes requesting access or signing an NDA from receiving an administrator's approval. Check the exact controls in the product and experience you use.

Keep three decisions separate: whether a visitor can discover the page, whether a recipient can obtain a file, and whether the file supports the claim beside it. Each decision needs its own check. A private document can be inaccurate, and a carefully reviewed public summary can be useful without exposing its underlying implementation material.

Google's visibility controls distinguish removing content from search results from protecting access to confidential material. A noindex instruction can keep a page out of Google Search while people with its link can still open it. Define and test authorization wherever your sharing policy requires approved recipients.

Use a document-level sharing matrix

Start with the buyer's actual request, then inventory the artifacts that could answer it. The AI SaaS security questionnaire worksheet can help you connect each question to an evidence reference. The suggested audiences below are starting points for your own review, not automatic publication permissions. Document owners must consider the file's contents, applicable sharing restrictions and the scope of the buyer's question.

The downloadable sharing matrix includes fields for owner, version, intended audience, approval, checked on, next review trigger and withdrawal contact. Link the record to the buyer question it answers. A document that answers no relevant question may not belong in the package.

Drata's security documentation describes selecting evidence-library files for Trust Center access in its Classic experience. It distinguishes that experience from the newer SafeBase-based setup. This is a useful reminder to verify which library items become externally accessible in your own portal.

Use a hypothetical data-flow diagram to rehearse the matrix. A public summary might name the categories of services involved. An approved buyer might receive a reviewed diagram. Internal infrastructure identifiers and unrelated customer examples can remain outside both versions. Record the reason for each difference so the two views remain consistent.

Which AI documents should be public?

Public AI documents should help a reader understand the product's declared scope and the published policies relevant to its services. Public links are suitable for provider documentation that is already available to everyone. Claims about your own deployment need separate evidence and an explicit review before publication.

OpenAI's data controls distinguish model-training use, abuse-monitoring logs and endpoint application state. The API's default training policy does not establish that an application stores no data. Optional controls and endpoint-specific behavior also need to be considered for the service actually used.

Anthropic's retention guidance includes service-specific conditions and exceptions involving agreements, enforcement and legal requirements. Link to the applicable guidance and explain which service the product uses. Avoid turning a general policy statement into an unsupported promise about every data flow.

For each public claim, record three distinct inputs internally: the policy you read, the account configuration you could observe, and the application behavior you checked. A missing input should remain visible as a limitation in the claim. Do not fill the gap with a screenshot from a different account or an example configuration.

Your own storage deserves its own explanation. A provider policy does not describe whether your application saves prompts, responses or uploaded files in another database. Publish a reviewed description of the relevant flow and its limits; keep sensitive implementation evidence in the appropriate review process.

Choose your access model, then test it

Your access model should follow the documents, recipients and approvals your team can maintain. Choose the simplest arrangement that meets those requirements, then test both allowed and denied access using synthetic material before sharing real supporting files.

Use this sequence to make the decision concrete:

1. Define the public summary. List what any visitor should be able to learn about the named product. Remove claims without a current owner or evidence reference.
2. List restricted artifacts. Name each document a buyer may request and its approval conditions. Do not assume one approval should release the whole library.
3. Assign an approver. Decide who verifies the recipient, document scope and release conditions. Record approval separately from the original request.
4. Check the delivery controls. Establish how recipients authenticate, how individual files are authorized, and how you withdraw future access. Verify the features your chosen setup actually provides.
5. Test with a dummy file. Try an unauthenticated visitor, an approved test recipient, an unapproved test recipient and a previously approved recipient after access is withdrawn. Include the direct file link in the checks.
6. Record the result. Keep the tested configuration, date and unresolved limitations with the sharing decision. Repeat relevant checks after changing permissions or delivery methods.

Treat the test as a release checklist, not a claim that those checks have already passed. A successful test also has a scope: one file and one configuration do not prove every future upload will inherit the intended permissions.

Plan for copies outside the portal. Do not assume that withdrawing access recalls a file someone already downloaded or imported. Your process needs a way to communicate corrections and identify the superseded version as well as to control future retrieval.

Keep buyer evidence current

Give each buyer-facing claim an evidence owner and a review trigger. Useful triggers include a provider or endpoint change, a production deployment affecting the described flow, a revised policy, a changed permission, or a newly resolved finding. Select a review cadence suited to the material rather than assuming every document stays valid for the same period.

Separate the document's publication date from the date the underlying fact was observed. Re-uploading an old report does not refresh its evidence. A short release note can state what changed, which product it concerns and which earlier version it replaces.

Vanta's vendor assessments documentation explains that imported Trust Center documents are point-in-time copies and that updated versions require another import. Even where a portal shows the newest file, a buyer's working copy may therefore describe an earlier state.

Keep a recipient and version record within your approved process. When a material correction affects a document already shared, identify the recipients and arrange an appropriate update. Do not leave an obsolete statement beside a newer file and expect the reader to reconcile them.

Can a trust center replace a security review?

A trust center can organize disclosures and supporting documents, but access to a document does not establish that its claims are correct. Buyers still need evidence relevant to their questions, with clear scope, dates and limitations. Review the content as carefully as the permission settings.

TrustData's technical methodology describes seven mandatory controls evaluated from fresh observable evidence. Founder declarations and payment do not issue technical verification. TrustData Verified is not a legal certification, a human endorsement, a safety guarantee or an exhaustive compliance review.

If your AI product fits the supported scope, a private product check can help establish what is observable before you prepare a sharing package. The publication plans concern publication and monitoring. They should not be read as an assurance that an unsupported technical claim becomes verified through payment.

Finish by reviewing one complete buyer journey: the public statement, the requested supporting artifact, the recipient's permission and the version received. Every step should describe the same product and evidence. Keep unanswered questions explicit and assign the next action to an owner.