SOC 2 for healthtech: which trust service criteria actually matter when you handle PHI

I reviewed a healthtech startup’s SOC 2 readiness plan last quarter and found all five trust service criteria checked off. When I asked the CTO why, he said his auditor told him to include everything to be safe. The result: a scope that would take five months and cost roughly $45,000, when the right scope for their product and data flows would have taken three months and cost closer to $28,000.

This is the most common scoping mistake I see in healthtech. The startup knows it needs SOC 2 (System and Organization Controls 2). It probably also knows it needs to comply with HIPAA (Health Insurance Portability and Accountability Act). But nobody explains which parts of SOC 2 are mandatory for their specific situation and which ones are adding months of audit work for no practical benefit.

So let me walk through the five trust service criteria and explain what actually matters when your product handles protected health information (PHI).

The five trust service criteria, briefly

SOC 2 is organized around five trust service criteria, defined by the AICPA (American Institute of Certified Public Accountants). Every SOC 2 report must include at least one. Most include more. Here they are:

1. Security (also called the Common Criteria). Covers access controls, system operations monitoring, risk management, and change management. This is the foundation.
2. Availability. Covers uptime commitments, disaster recovery, and performance monitoring.
3. Processing Integrity. Covers whether your system processes data accurately, completely, and on time.
4. Confidentiality. Covers how you protect information designated as confidential, including how you restrict access and handle data retention.
5. Privacy. Covers how you collect, use, retain, and dispose of personal information. Specifically governed by the AICPA’s Generally Accepted Privacy Principles.

Security is always in scope. Always. There is no SOC 2 report without it. The other four are optional, and this is where the scoping decisions matter.

Security: the one you cannot skip

Every SOC 2 engagement starts here, and for good reason. The Security criteria cover the controls that everything else builds on: access management, network monitoring, change management, risk assessment, incident response.

For healthtech startups, the Security criteria also carry most of the overlap with HIPAA’s Security Rule. Access controls, audit logging, encryption in transit and at rest, workforce security training. If you have already mapped your HIPAA controls, you will recognize about 60-70% of the Security criteria as work you have done or need to do anyway.

This is the efficiency most generalist guides miss. A healthtech startup that builds its HIPAA compliance program and SOC 2 Security criteria together saves roughly a third of the total effort compared to doing them sequentially. The controls are not identical, but they share enough DNA that building them in parallel eliminates most of the redundant work.

Availability: it depends on your product

This is where I see the first scoping mistake. Availability covers uptime, disaster recovery, backup procedures, and performance monitoring. If you are selling a platform that health systems rely on for clinical workflows, availability belongs in your scope. Downtime in a clinical workflow is not just an inconvenience. It can affect patient care.

But if your product is a back-office analytics tool, or a population health platform that runs batch jobs overnight, the question is simple: do your customers have an uptime expectation you have committed to in your contracts?

If you have signed SLAs (Service Level Agreements) with availability commitments, include it. If neither SLAs nor clinical workflow dependencies exist, you are probably adding 15-20% more audit work for a criteria that does not match your risk profile. Make the decision deliberately, not because an auditor defaulted you into it.

Processing Integrity: usually over-scoped for healthtech

Processing Integrity is the criteria I see included most often without a clear reason. It covers whether your system processes data accurately, completely, and in a timely manner. Think financial transaction processing, payroll calculations, insurance claims adjudication.

If your healthtech product processes claims, calculates dosages, generates clinical decision support recommendations, or handles any workflow where an incorrect output has direct clinical or financial consequences, Processing Integrity is in scope.

For most healthtech startups I work with, though, the product is ingesting, storing, displaying, or transmitting health data. Not transforming it in ways that require integrity guarantees beyond what the Security criteria already cover. A patient portal that displays lab results does not need Processing Integrity. A clinical decision support tool that recommends medication adjustments probably does.

This criteria adds roughly 10-15% to the audit scope. Before you include it, ask your auditor to explain exactly which of your processing workflows it would cover. If the answer is vague, that is a signal.

Confidentiality: almost always in scope for healthtech

Here is where healthtech diverges from generic SaaS, and where most generalist consultants get it wrong.

Confidentiality covers how you protect information designated as confidential: who can access it, how it is classified, how long you retain it, and how you dispose of it. For generic B2B SaaS, Confidentiality might be optional. Customer data is covered under Security, and no regulatory mandate drives specific confidentiality requirements.

For healthtech, PHI is by definition confidential information. Your Business Associate Agreements (BAAs) with covered entities specify how you must handle it. HIPAA’s Privacy Rule dictates retention and disposal requirements. Your customers will look at your SOC 2 report and expect to see Confidentiality controls.

I have seen healthtech startups get their SOC 2 Type II report back without Confidentiality in scope and then have a health system’s procurement team ask why it was excluded. That conversation does not go well. Including it adds roughly 10% to the audit scope. The cost of explaining why you left it out is larger.

Privacy: the one that catches people off guard

Privacy is the most misunderstood of the five criteria, and for healthtech, it is almost always relevant.

The Privacy criteria covers how you collect, use, retain, disclose, and dispose of personal information. It is governed by the AICPA’s Generally Accepted Privacy Principles, which are broader than HIPAA’s Privacy Rule but overlap with it significantly.

Here is where it gets specific. If your product collects information directly from patients (through a patient portal, a mobile app, intake forms, or any direct consumer interaction), the Privacy criteria is in scope. You are collecting personal information from individuals, and your SOC 2 report should demonstrate that you have controls around consent, notice, choice, and data minimization.

If your product only receives data from covered entities through system-to-system integrations and never interacts with patients directly, you have a reasonable argument for excluding Privacy. Your HIPAA obligations still apply, but they are covered under your BAA and your HIPAA compliance program rather than the SOC 2 Privacy criteria.

Privacy adds real audit work: documented privacy notices, consent mechanisms, data subject access request procedures, and retention schedules. But for a patient-facing product, this work needs to happen regardless of SOC 2. Including it in your scope just means it gets audited formally, which is actually a benefit when procurement teams ask about your privacy posture.

The healthtech scoping framework

Let me make this concrete. Here is how I scope SOC 2 for a healthtech startup:

Always in scope: Security and Confidentiality. Security is mandatory. Confidentiality is functionally mandatory when you handle PHI, because your buyers expect it and your BAAs require the underlying controls.

In scope if your product is patient-facing: Privacy. If patients interact with your product directly, include it. The audit work overlaps heavily with HIPAA Privacy Rule requirements you need to satisfy anyway.

In scope if you have clinical uptime obligations: Availability. Include it if you have signed SLAs or if your product integrates into clinical workflows where downtime has patient care implications.

In scope only if your product transforms health data: Processing Integrity. Include it if your product calculates, adjudicates, or generates clinical recommendations. Exclude it if your product primarily stores, displays, or transmits data.

For most healthtech startups selling to health systems, the right scope is three criteria: Security, Confidentiality, and Privacy. Some add Availability. Very few actually need all five.

The difference between three criteria and five criteria is not trivial. All five criteria can add 40% more audit work compared to a focused three-criteria scope. That translates to roughly 4-8 extra weeks of preparation and $10,000-$15,000 in additional audit costs. For a startup trying to get audit-ready quickly, that time matters more than the money.

Where SOC 2 and HIPAA overlap (and where they do not)

If you are a healthtech startup, you are building both a SOC 2 compliance program and a HIPAA compliance program. The overlap is significant, and that is your advantage.

High overlap: Access controls, encryption (at rest and in transit), audit logging, incident response, workforce security training, vendor management, and risk assessment. Build these once and map them to both frameworks. You write the policies once, implement the controls once, and collect evidence once, then present it differently to each assessor.

SOC 2 specific: Change management controls, system monitoring, and the criteria around Availability and Processing Integrity. HIPAA does not have formal change management requirements the way SOC 2 does.

HIPAA specific: BAA management, breach notification procedures (HIPAA has specific timelines SOC 2 does not address), minimum necessary standard for PHI access, and Privacy Rule provisions around patient rights.

Start with the overlapping controls. That gets you roughly 60-70% of the way to both frameworks. Then layer in the framework-specific requirements.

The scoping conversation you should have with your auditor

Before you sign an engagement letter, ask your auditor two things. First: “Based on my product, my data flows, and my customer contracts, which trust service criteria do you recommend and why?” If the answer is “all five, to be safe,” push back. Ask them to justify each one against your specific situation.

Second: “Which of my HIPAA controls can we map to SOC 2 criteria to reduce duplicate work?” A good auditor will help you build an integrated control matrix. A less experienced one will treat them as separate workstreams, which doubles your evidence collection effort.

The right auditor for healthtech is one who has done healthtech engagements before. The general-purpose auditor who mostly works with fintech SaaS may not think to raise Confidentiality and Privacy, because in their usual engagements, those criteria are optional.

Get the scope right first, then move fast

The fastest SOC 2 projects I have been part of all started the same way: with a clear scoping decision that matched the criteria to the product and the buyers. Everything that came after, the policies, the controls, the evidence collection, moved faster because the scope was right.

The slowest projects included everything without thinking about it, then spent months building controls for criteria that nobody was going to ask about.