What Should Your Trust Center Contain? A Guide for Health Tech Software Vendors

A buyer at a healthcare organization often checks your security posture before sending you a questionnaire. What is a trust center? It's the public page where that check happens: your framework status, your policies, your sub-processor list, and a gated path to your SOC 2 report. For a health tech vendor, a well-built trust center answers the reviewer's first questions and can keep a full questionnaire from being sent at all.

The problem is that trust centers go stale. Compliance platforms sync some data automatically, but the pieces healthcare buyers act on first (like framework status and the sub-processor list) are usually kept by hand and go stale unless someone owns them. A trust center that says "SOC 2 compliant" with no report date, no auditor named, and no way to request the actual report can cost you more with a reviewer than having no page at all.

A trust center that holds up needs the right contents, a clear line between public and gated documents, precise wording for frameworks still in progress, and a named owner who reviews it every quarter.

Key Points

• A trust center is a public-facing page where prospective customers verify your security and compliance posture before engaging sales or sending a security questionnaire. For health tech vendors it must include HIPAA compliance status, SOC 2 Type 2 examination details, HITRUST certification if held, sub-processor lists, and recent penetration test dates.
• Each audited framework entry should show the date of the most recent report or assessment and the auditor or assessor name, because reviewers treat badges without dates and auditor names as unverified and ask for the actual reports anyway.
• Healthcare buyers check the sub-processor list closely because they need to know where PHI flows. List each sub-processor, what they do, where they are hosted, and update it every time you add or remove one.
• When describing a framework still in progress, use precise language like "SOC 2 Type 2 audit in progress, report expected [month]" with the auditor name, observation period start date, and expected report date. "SOC 2 in progress" means nothing to a buyer without that context.
• A trust center without an owner goes stale. Assign someone to check framework status, the sub-processor list, document currency, and access request settings every quarter.
• A well-built trust center answers a reviewer's first questions before a questionnaire is sent. Keeping it current is part of GRC platform administration, the work that cut ReadMe's security questionnaire responses from 6 business days to 2.

What is a trust center?

A trust center is a public-facing page on your website where prospective customers verify your security and compliance posture before engaging your sales team or sending a security questionnaire.

Every claim on it should be verifiable and current.

For most software vendors, the page lists active frameworks like SOC 2 and ISO 27001, links to policies, and a way to request detailed reports.

Why health tech vendors need a specific version

A generic security trust center works fine if you sell project management software. It doesn't work when your buyer is a health plan, a pharma company, or a healthcare provider with a security team that reviews vendors against the HIPAA Security Rule and their own internal procurement standards.

Healthcare buyers look for specific signals. They want to see what backs your HIPAA compliance claim (HIPAA has no official certification), whether you've completed a SOC 2 Type 2 examination, whether you hold HITRUST, and who your sub-processors are. They want to know if your penetration test was done in the last year. They want to see a BAA execution path.

If those signals aren't on your trust center, the reviewer sends the full questionnaire.

What a health tech trust center should contain

Keep the page short and clear enough that a reviewer can get through their checklist in ten minutes.

Framework status and audit details

List every framework you've completed or are actively working toward. For each one, include the status (achieved, in progress, or aligned to) and, where an audit or assessment exists, the date of the most recent report and the auditor or assessor name.

A reviewer who sees "SOC 2" with no date and no auditor name treats it as unverified.

We see this from the buyer side, too. When we assess a vendor for a client and its trust portal lists frameworks with no dates and no auditor named, we treat them as unverified and ask for the actual reports. Badges without paper don't satisfy a reviewer.

Policies, sub-processors, and security contact

Your policy list should include at minimum your information security policy, privacy policy, acceptable use policy, and incident response overview. A business continuity and disaster recovery plan can go here too, though some companies gate it.

One of our healthcare SaaS clients prepared a public version of its business continuity and disaster recovery plan with internal names and source details removed. We reviewed it, routed it through the compliance platform for approval, and asked whether it should be open to every visitor or available on request.

They chose on request to start. That's a reasonable default for any document that contains operational detail.

Healthcare buyers check the sub-processor list closely because they need to know where PHI flows. List each sub-processor, what they do, where they're hosted, and whether they handle PHI. Update it every time you add or remove one.

Finally, include a security contact email or form and a way to request your BAA. Reviewers shouldn't have to go through your sales team to ask a security question.

What to keep public and what to gate behind an NDA

The split between public and gated content protects you without making the reviewer's job harder.

Keep these items public on your trust center: framework status with dates and auditor names, your policy list (or at least titles and summaries), the sub-processor list, your security contact, and any certifications you hold.

Gate these items behind an access request, usually with an NDA: the full SOC 2 report, your penetration test report or summary (a scan report is a different document, covered in penetration test vs vulnerability scan), detailed architecture documentation, and any document that contains control-level detail.

Handling the SOC 2 report

During that same client's SOC 2 Type 2 audit, it worried its system description would become public. We set the full report behind an access request the client approves.

When the report was issued, we uploaded it with access restricted and also produced a shorter summary version that leaves out the list of controls, for buyers the client was comfortable sharing it with more widely.

The two versions serve different readers. The summary can answer an initial review. The full report goes to buyers who need it for their formal vendor assessment.

One thing to watch is old reports sitting next to current ones. When a life sciences software client's SOC 2 Type 2 report arrived, we removed the superseded Type 1 report and made its privacy document a public download. A trust center showing last year's report next to this year's confuses a reviewer.

If you're working toward SOC 2, see our SOC 2 compliance services, and to make sure you're not missing foundational items, grab our free SOC 2 Readiness Checklist before you set up your trust center.

What syncs from your compliance platform and what you keep by hand

If you use a GRC platform, some of your trust center data syncs automatically. Monitoring status and control counts typically update on their own.

The parts healthcare buyers act on are mostly kept by hand.

The items that go stale

Your sub-processor list usually has to be kept by hand. So does your framework status when it changes (say, from Type 1 to Type 2, or from "in progress" to "achieved").

Policy documents kept outside the platform need to be re-uploaded when they're revised. The pen test summary needs to be swapped when a new test is completed.

We reviewed one client's rebuilt trust center and asked for each framework to carry its real status, achieved or in progress, and for documents to be split into public and NDA-gated. One certification had passed its final audit stage with the auditor recommending certification, but the certificate wasn't yet issued, so we had it labeled "certification pending."

A draft label that called two privacy laws "independently audited" was corrected to "compliant," because no independent audit had been done against them. Both fixes came from checking each label against what actually stood behind it.

How to describe a framework you are still working toward

You want to signal progress to a buyer without overstating where you are. The wrong label costs more when a reviewer checks than the gap ever would.

Status labels for in-progress work

Use labels that claim no more than you can show a reviewer.

• SOC 2 Type 2 audit in progress, report expected [month]. Use this when the observation period is underway and the audit firm is engaged.
• Aligned to ISO 27001. Use this when you follow the standard but haven't had a certification audit.
• Certification pending. Use this when the auditor has recommended certification but the certificate hasn't been issued.
• SOC 2 Type 1 report issued [date], Type 2 observation period underway. Use this when you're between report types.

On its own, "SOC 2 in progress" tells a buyer nothing. Add the auditor name, the start date of the observation period, and the expected report date. That gives the reviewer something to work with.

What to do when a buyer needs assurance before the report exists

During one client's SOC 2 observation period, one of its customers wanted assurance before any report existed. We asked the audit firm for a letter of engagement confirming the SOC 2 examination was underway and stating the date the observation period began.

The firm issued it.

That letter is not a SOC 2 bridge letter. A bridge letter comes from you, after a report exists, and covers the months since its period ended. Before your first report, the auditor's confirmation of the engagement is the strongest proof you have. It gives the buyer something verifiable without you making claims you can't back up.

What never to put on the page

Don't write "certified" or "audited" unless a certificate or an audit report backs it. Don't display a framework logo without a corresponding document. And never present SOC 2 as a certificate. The accurate line is "SOC 2 Type 2 report issued" with the date.

Under AICPA standards, a SOC 2 examination ends in a CPA firm's report on your controls. Reviewers at healthcare organizations know the difference.

Knowing how to verify vendor certifications is part of their job.

How a trust center cuts security questionnaire work

Every security questionnaire a healthcare buyer sends you represents hours of work. A trust center for healthcare vendors reduces the volume and the depth of what gets asked, though some questionnaires will still come.

When a reviewer can confirm your SOC 2 status, read your sub-processor list, and request your report from the trust center, they may not need to send a full SIG questionnaire. They might send a short supplemental questionnaire focused on the gaps your public information didn't cover. Or they might skip the questionnaire entirely and go straight to report review.

When a full questionnaire still comes, our guide to healthcare security questionnaires covers how to answer it without stalling the deal. The more your trust center answers upfront, the fewer rounds of back-and-forth your team handles.

Our GRC platform administration for ReadMe cut its security questionnaire responses from 6 business days to 2. Keeping a trust center current is part of the same work. A current page keeps many low-value requests from reaching your team.

Who should own it, and how often to review it

A trust center without an owner goes stale. Someone needs to own the page the same way someone owns your HIPAA compliance program, with a name, a responsibility, and a review cadence.

A short quarterly review

The owner should check four things every quarter.

First, check your framework status. Has anything changed? New report issued? Observation period started or ended?

Second, review your sub-processor list. Added or removed any vendors? Changed hosting providers?

Third, verify your documents. Are all uploaded documents current? Any superseded reports still showing?

Fourth, confirm your access requests. Are gated documents still set to the right access level?

If you don't have a dedicated compliance or security person, assign the trust center to whoever owns vendor relationships or your compliance program. At a 30-person health tech company, that's often the CTO or VP of Engineering.

If nobody on your team has the bandwidth, that's a sign you need fractional support.

Frequently asked questions

What is a security trust center?

A security trust center is a public-facing page where prospective customers can verify your security and compliance posture before they involve sales or send a security questionnaire. It typically includes high-level framework status, policies, your sub-processor list, and a way to request gated assurance documents.

What is the purpose of a trust center?

The purpose is to let buyers quickly validate key security signals without starting a back-and-forth process. Done well, it reduces the number and depth of security questionnaires and helps deals move faster.

Can you provide some examples of trust centers?

Common examples include SaaS vendors publishing a security page that lists SOC 2 or ISO 27001 status, links to security and privacy policies, a sub-processor directory, and an access request workflow for reports like SOC 2. Many companies host this as a "Security" or "Trust" page on their website, sometimes powered by a GRC or trust portal tool.

How do I access the trust center?

Most vendors expose it as a public link on their website, often in the footer under labels like Security, Trust, or Trust Center. If a vendor gates certain documents, you typically access those by submitting an access request from within the trust center.

How should we word in-progress frameworks in a trust center without creating legal or buyer trust issues?

Use specific, verifiable status language and include the proof points a reviewer can validate, such as the audit firm, the observation period start date, and the expected report month. Avoid blanket claims like "compliant" when what you really have is an audit underway or internal alignment work.

What should a healthcare vendor include about sub-processors to prevent procurement delays?

Make the list usable for risk review by including what each sub-processor does, where it is hosted, and when it was last updated. Also add an owner and a lightweight change process so the list stays current when vendors are added, removed, or data flows change.

What is the fastest way to keep a trust center from going stale when no one has time to maintain it?

Assign a named owner and schedule a recurring quarterly review with a short checklist that covers framework status, sub-processors, document currency, and access request settings. If you cannot staff an owner internally, consider fractional compliance or security ops support to keep updates from slipping.

Keeping your trust center current

A healthcare buyer often checks your trust center before anything else, so it has to be current.

Get the framework status right. Keep the sub-processor list current. Gate what needs gating and assign someone to review the page quarterly.

When a reviewer can verify your compliance posture in ten minutes instead of sending a full security questionnaire, your sales cycle can shorten and your team spends less time on low-value back-and-forth.

Help with your trust center

If you're building or fixing your trust center and want help getting the details right, from framework language to document structure to quarterly reviews, talk to an expert at Cycore. Cancel anytime. If you're not saving 100+ hours, you don't pay.