Trust center launch checklist

Before you start — pick an owner and a deadline

A trust center stalls when no single person owns it. Pick one owner from security, ops, or founder-team and give them a hard deadline (one week is realistic for most early-stage teams). The owner does not need to write every word; they need to chase the people who hold the documents, approve the NDA copy, and make the publish-vs-keep-private calls. If you have a designer or marketer who can spend an hour on the brand pass, line them up for day 5.

Decide up-front what "done" means. A minimum-viable launch is: the trust portal is live on a public URL, the SOC 2 (or equivalent) is gated behind an NDA workflow, and the URL is in your sales team's email signatures and proposal template. Anything else — custom domain, e-signature integration, GA4 — is a fast-follow.

Day 1 — Gather your documents

Pull every security and compliance artefact you already have into one folder. Most teams find more than they expect once they actually look — old penetration test summaries, an ISO gap-analysis report, an information-security policy a previous hire wrote and never published. List what you find even if it feels incomplete; you can always mark a document internal-only and surface it later.

• SOC 2 Type 2 report (and Type 1 + bridge letter if relevant)
• ISO 27001 certificate or other certifications
• DPA / GDPR addendum
• Subprocessor list with locations and the data category each one processes
• Pen test summary or full report
• Information security policy and any sub-policies (access control, acceptable use, incident response)
• Business continuity / disaster recovery plan
• Cyber insurance certificate
• Responsible disclosure policy
• Latest vulnerability-management summary or risk register extract

Day 2 — Decide visibility per document

Each document should be public, NDA-required, or internal-only. Default sensitive material (SOC 2 report, pen test report, financials, internal risk register) to NDA-required so buyers can see the document exists without being able to download it. Default high-level artefacts (ISO certificate, DPA, responsible-disclosure policy) to public so buyers can self-serve.

If you are not sure, NDA-gate it. Watermarking, audit trails, and short-lived links remove almost all of the downside of sharing without giving up the ability to know who has the file. The cost of leaking a SOC 2 report into a competitor's inbox is high; the cost of asking a buyer to click "Request access" is approximately zero.

Day 3 — Set up your sections

Organize the trust page into sections buyers expect: Certifications, Policies, Subprocessors, Pen Tests, Practices, Incident Response, Contact. Add a short paragraph per section so buyers can self-serve answers without having to download anything. The goal is to absorb the obvious questions ("Where do you host data?", "How do you encrypt at rest?", "Who are your subprocessors?") before they become a questionnaire.

Keep each section short — two or three sentences plus a bullet list is usually enough. Buyers skim; long-form prose loses them. Reuse phrasing from your existing security policies so the language matches what your team already says under audit.

Day 4 — Configure your NDA workflow

Use the built-in NDA template, upload your own, or wire up DocuSign / SignNow on a paid tier when you need a fully audited e-signature flow. Decide whether requests auto-approve on signature or wait for manual review. Manual review is the right default for the first month so you can spot patterns (which companies are asking, which documents they want, whether anyone is fishing) before you flip on automation.

While you are in the NDA section, write a short, plain-English description of what is in your SOC 2 package — buyers want to know if they are getting the report, the bridge letter, the most recent letter of attestation, or all three. Setting expectations here saves a round-trip after approval.

Day 5 — Brand and publish

Add your logo, primary color and footer text. On Pro and Business plans, set up a custom domain (e.g. trust.yourcompany.com) so the portal lives on your brand rather than on a vendor subdomain — buyers notice. Add a custom favicon, write a one-line tagline under your logo, and double-check the typography matches your marketing site so the portal does not feel bolted on.

Do a final read-through on a phone before you publish. Most security reviews happen on a laptop, but procurement leaders increasingly skim on mobile while waiting for the next meeting. If your section paragraphs reflow cleanly and the document list is usable with a thumb, you are in good shape.

Day 6 — Share and instrument

Add the URL to your sales email template, contract pack, customer onboarding emails, marketing site footer, and the bottom of your homepage. Update your standard proposal cover letter to reference the trust portal as the place buyers should go for security questions. Optionally add a custom GA4 measurement ID for trust-page analytics so you can see how many buyers actually use the portal end-to-end.

In week two, instrument the audit log into a weekly review: which buyers requested which documents, which requests stalled, and which questionnaire questions still came in despite the portal. Use that signal to add the missing section, rephrase a confusing one, or move a document from internal-only to NDA-gated.

Common mistakes to avoid

Three patterns trip up first-time trust-center owners. First, treating the portal as a one-time marketing project — it works only if someone reviews access requests weekly and refreshes documents after each new audit. Second, gating everything — buyers reading a vague homepage with no public artefacts assume you have nothing to share, which is the opposite of the impression you want. Third, ignoring the small stuff: a stale "last reviewed" date or a broken link to a policy PDF reads as carelessness, and carelessness is the one signal buyers cannot un-see during a security review.