A Customer Asked for Your Trust Center. Here Is What to Put On It

Direct answer: A trust center is a public page that answers the security questions buyers keep asking, with the sensitive documents available on request. It exists to stop you answering the same questionnaire by hand every quarter, and a good one measurably shortens security review.

What goes on the public page

Which frameworks you hold or are working toward, with dates. Where data is hosted and in which regions. Encryption in transit and at rest. Your subprocessor list. How to report a vulnerability. How to reach a human about security. Your incident notification commitment.

None of that is sensitive. All of it is asked constantly, and publishing it removes the first round of most reviews.

What to gate

The SOC 2 report itself, behind a request form or an NDA. Penetration test reports, or better, the attestation letter. Your policy set. Anything with architectural detail. Gating is normal and buyers expect it, so long as the request is answered quickly.

What not to do

Do not claim frameworks you do not hold. "SOC 2 compliant" when you have no report is the single fastest way to lose a technical reviewer's trust, and they check. If you are in progress, say in progress with a target date.

Do not let it go stale. A trust page listing a subprocessor you dropped a year ago, or a report period that expired, is worse than no page, because it tells a reviewer nobody owns this.

Why it pays

The economics are straightforward. Every enterprise buyer asks broadly the same forty questions. Answering them once publicly means most reviews start further along, and the ones that still send a questionnaire can often be answered by pointing at the page. It also signals maturity in a way that costs nothing to maintain once built.

We build these as Trust Center Setup, ours is at traztech.ca/trust-center if you want to see the shape, and the free trust center builder will draft the content for you.

What the Buyer On the Other Side Is Actually Doing

It helps to know what happens to your page after a reviewer opens it. In most mid-market and enterprise procurement teams, a vendor risk analyst has a queue of thirty to sixty reviews and a target turnaround measured in days. Their job is not to assess your security philosophy. It is to fill in fields: framework held, report period, hosting region, encryption, subprocessors, breach notification commitment, insurance, and whether anything on your page contradicts what your sales engineer said on the call. They copy those fields into a vendor risk platform or a spreadsheet, attach the report, and route it.

That changes what a good trust center looks like. It is not a marketing page about your commitment to security. It is a fielded document that lets a tired analyst finish their form without emailing you. Put the facts in scannable lines with labels, not in prose paragraphs. Put dates on everything. If your report period is 1 January to 30 June, say so, because "SOC 2 Type 2" without a period tells the analyst nothing and they will have to ask.

The second thing to understand is that reviewers check. If you list a framework, someone will request the report. If you name subprocessors, a privacy-conscious buyer will compare that list against what their own DPA requires them to disclose downstream. If you claim a bug bounty and your security page has no intake path, that gets noticed. Everything you publish becomes a claim you can be tested on, which is exactly why it works when it is true.

The Request Workflow Is the Part That Breaks

Publishing the page is a day of work. Running the gated side is where trust centers quietly fail. A buyer requests your SOC 2 report on a Thursday afternoon. What happens next determines whether the page saved you time or cost you a week.

Decide these four things before you launch. Who receives the request, with a named person and a backup, not a shared alias nobody watches. What the turnaround commitment is, and put it on the page, because a stated one business day is a competitive advantage over a rival who takes five. Whether an NDA is required, and if so, whether you use a click-through mutual NDA or route to legal, because routing to legal adds a week and is rarely worth it for a standard report request. And whether you log who received what, which you will want the moment a report shows up somewhere it should not have.

The click-through NDA is the single highest-leverage decision. A short mutual non-disclosure agreement, accepted electronically, tied to the download, with the counterparty's name and email captured, resolves the confidentiality concern without a legal cycle. If your counsel will not accept click-through for the SOC 2 report, ask whether they will accept it for a penetration test attestation letter instead, and gate the full test report separately.

Publishing an Attestation Letter Instead of the Full Test Report

Penetration test reports are the most over-shared sensitive document in B2B software. A full report contains reproduction steps, affected endpoints, and often screenshots of your admin interface. Handing that to every prospect's analyst, some of whom will store it in a shared drive with loose permissions, creates real exposure for a benefit you can get another way.

The alternative is an attestation letter from the testing firm: scope tested, methodology, dates, tester qualifications, a summary count of findings by severity, and a statement that findings were remediated and retested. Two pages, no exploitation detail, and it satisfies the overwhelming majority of reviewers. Ask your testing provider for one at the outset of the engagement rather than after, because retrofitting it means going back to a firm that has already closed the project. Our own penetration testing engagements produce the letter alongside the report as standard, starting from $1,000, precisely because the letter is the artefact that actually moves through a sales cycle.

The Page You Publish When You Do Not Have a Report Yet

Most companies asking this question have no SOC 2 and no ISO certificate, and assume that means they have nothing to publish. That is wrong, and the in-progress trust page is one of the highest-return pages an early-stage company can build.

What you can publish honestly with no audit at all: your hosting provider and regions, encryption in transit and at rest with the actual protocols and key management approach, your authentication model including whether you support SSO and enforce MFA internally, your access control approach and how offboarding works, your backup and restore posture including when you last tested a restore, your subprocessor list, your vulnerability disclosure contact, your incident notification commitment in hours, and the date of your most recent penetration test. That is a substantial document, and a reviewer who receives it in place of a report often has enough to proceed under a risk exception.

Then add the honest status line: readiness work underway, target audit period beginning in a stated month, framework named. That line converts an absence into a plan. What it must never become is a claim. There is a real difference between "SOC 2 Type 2 audit period begins October 2026" and "SOC 2 compliant," and reviewers punish the second one hard.

Subprocessors, Change Notification, and the Commitment You Should Think Twice About

Your subprocessor list is the section most likely to create an ongoing obligation you did not intend. Many buyers, especially European ones and anyone flowing down GDPR-style terms, want advance notice of new subprocessors with a right to object. If you offer a notification subscription on your trust center, you are committing to remember to use it every time an engineer adds a new tool that processes customer data.

That commitment is worth making, but only alongside a control that makes it survivable: new vendor onboarding has to route through one person or one channel before the tool goes into production. If your company adds SaaS tools by expensing them on a personal card, do not promise thirty days advance notice of subprocessor changes, because you will breach it within a quarter and a diligent buyer will find out.

Same reasoning applies to uptime. Publishing a status page is excellent. Publishing an availability commitment on your trust center when you have no formal SLA in your contracts creates a claim your contracts do not back.

Ownership, Refresh Cadence, and How to Keep It From Rotting

Staleness is the failure mode, and it is a calendar problem rather than a content problem. Attach the page to events that already happen. When a report is issued, update the period. When a penetration test completes, update the date and the letter. When a subprocessor is added or removed, update the list that day. When your insurance renews, check the coverage line. Beyond that, one scheduled review each quarter by a named owner catches the drift.

Track two numbers if you want to know whether it is working. First, how many inbound security questionnaires you receive per closed deal, before and after. Second, the elapsed days from first security contact to security sign-off. If the page is doing its job, the second number falls faster than the first, because reviews that still happen start further along.

Build It Yourself or Buy a Platform

Dedicated trust center products exist and they do genuinely useful things: access logging, automatic NDA handling, control status pulled from a compliance platform, notification subscriptions. They also cost real money annually and they tie the page's appearance to a vendor's template.

Our honest read is that a company under about fifty people, with one report and a handful of documents, does not need the platform. A static page on your own domain plus a request form that lands in a monitored inbox plus a click-through NDA does the same job for the cost of a day of work. Buy the platform when the volume justifies it, which usually means you are fielding several report requests a week, you need per-recipient access logs for a regulated customer base, or you already own a compliance platform that populates the page automatically.

When You Should Not Build One At All

If a single customer has asked and you have nothing published, answer that customer directly and well, and do not build infrastructure for a population of one. A tight security overview document and a fast, complete questionnaire response will close that deal. Build the page when the same questions have arrived from three different buyers, because at three you are provably paying the repeat cost the page eliminates.

If your security posture genuinely will not withstand scrutiny, publishing is the wrong first move. A page that invites detailed questions you cannot answer accelerates the discovery of problems rather than the closing of deals. Fix the two or three things you already know are wrong, usually MFA enforcement, offboarding, and logging, and then publish.

And if the requesting buyer is small, non-regulated, and asking because a template told them to, it is entirely reasonable to send a two-page security summary and move on. Not every request deserves a programme. If you want help telling those cases apart, or you want the questionnaires handled while you build the page, that is what our retainer work covers, and talking to us costs nothing.