Priya Nair had built her career on being the person who didn't panic. Fifteen years in security and compliance, the last four as VP of Security & Compliance at MedFlow Health, a care-coordination platform that connected discharge planners, home health agencies, and durable medical equipment suppliers across nine hospital systems. But the email sitting in her inbox on a Tuesday morning in March had her staring at her second cup of coffee a little too long.
Crestwood Health Network's vendor risk team had paused a $2.4 million, three-year contract — the single largest deal in MedFlow's pipeline — pending "clarification of the vendor's HIPAA compliance status." MedFlow had a clean SOC 2 Type II report, less than five months old, unqualified opinion, zero exceptions. Priya had assumed that report would carry the deal across the finish line. Instead, Crestwood's security director had written back with a single pointed question: "Your SOC 2 report is reassuring, but it doesn't mention HIPAA anywhere. Where's your Business Associate Agreement, and how does this report map to the Security Rule? We need both before legal can proceed."
That question — reasonable, common, and completely predictable in hindsight — is the one this article is built around. SOC 2 and HIPAA solve related but distinct problems, and health-tech companies that conflate them lose deals, fail vendor risk reviews, and occasionally end up in regulatory trouble they thought a nice PDF from their auditor had already prevented.
Who this is for, and what you'll walk away with
This article is for security, compliance, and engineering leaders at health-tech service organizations — care coordination platforms, telehealth vendors, clinical SaaS tools, health data analytics companies, revenue cycle management firms, and anyone whose systems touch protected health information (PHI) on behalf of a covered entity or another business associate. You'll walk away understanding exactly where SOC 2's Trust Services Criteria overlap with HIPAA's Security Rule safeguards, where the two frameworks diverge, why a Business Associate Agreement is a non-negotiable separate document regardless of your audit results, and how to scope the Confidentiality and Privacy criteria specifically for PHI so your next enterprise health system buyer doesn't send back the same email Priya got.
Why health-tech buyers ask the SOC 2 question at all
Every hospital system, health plan, and digital health platform that touches your product runs a vendor risk assessment before signing. For a health-tech company handling clinical, billing, or care-coordination data, that assessment almost always asks for two things in the same breath: a current SOC 2 report and evidence of HIPAA compliance. Buyers aren't being redundant. They're covering two different legal and contractual exposures — their own liability as a covered entity under HIPAA, and their operational confidence that your controls actually work day to day. A SOC 2 report speaks to the second. Only a signed Business Associate Agreement, paired with your own HIPAA-aligned safeguards, speaks to the first.
The confusion Priya ran into is extremely common, and it runs in both directions. Some vendors oversell their SOC 2 report as "HIPAA compliant," which creates false comfort for buyers and legal exposure for the vendor when a regulator or plaintiff's attorney later points out that a SOC 2 report is not, and was never intended to be, evidence of HIPAA compliance. Other vendors undersell what SOC 2 actually demonstrates, treating it as generic security theater rather than the rigorous, evidence-based examination it is when scoped correctly for PHI-handling systems.
"The single most common line in a health-tech security questionnaire we get is 'Please confirm your organization is HIPAA compliant, and attach your SOC 2 report as evidence.' Those are two different asks disguised as one, and half the vendors we evaluate don't seem to know that." — Sana Patel, Director of Vendor Risk, Crestwood Health Network
SOC 2 and HIPAA: the core distinction, stated plainly
Let's get the foundational fact on the table before anything else, because everything downstream depends on it: SOC 2 supports HIPAA compliance efforts — it is not HIPAA compliance, and it cannot substitute for one. SOC 2, governed by the AICPA's SSAE 18 standard, is a voluntary attestation examination performed by a licensed CPA firm against the Trust Services Criteria. HIPAA is a federal law with a Security Rule, a Privacy Rule, and a Breach Notification Rule, enforced by the U.S. Department of Health and Human Services' Office for Civil Rights (OCR). One is a market-driven assurance report; the other is a binding legal obligation with civil and, in some cases, criminal penalties.
Dimension | SOC 2 | HIPAA |
|---|---|---|
Nature | Voluntary AICPA attestation examination | Federal law (45 CFR Parts 160, 162, 164) |
Who performs it | Licensed CPA firm | Self-assessed, or via a security/legal advisor; enforced by OCR |
Output | Attestation report (Type I or Type II) | No "report" — a compliance posture, evidenced through policies, risk analyses, and audit logs |
Legal status | Not a law; contractual/market requirement | Federal law with civil and criminal penalties |
Scope | Systems and controls relevant to Trust Services Criteria | PHI specifically: its creation, receipt, maintenance, transmission |
Required contract artifact | None (report itself is the deliverable) | Business Associate Agreement (BAA) between covered entity and business associate |
Applies to | Any service organization, any industry | Covered entities and their business associates handling PHI |
Enforcement | Market pressure, contract terms, loss of trust | OCR investigations, resolution agreements, corrective action plans, fines |
The practical consequence: a health-tech company can hold a flawless SOC 2 Type II report and still be out of HIPAA compliance if it lacks a signed BAA with every covered entity or business associate it works with, hasn't performed a formal HIPAA risk analysis, or hasn't implemented required administrative safeguards like a sanctions policy for workforce violations. Conversely, a company can be diligently HIPAA-compliant and still fail to win enterprise deals because it has no independent attestation a buyer's procurement team can rely on without doing its own on-site audit.
"I tell every health-tech founder the same thing in the first onboarding call: SOC 2 tells your customer your controls work. HIPAA tells the government you're allowed to touch the data in the first place. You need both, and neither one does the other's job." — James Okafor, Partner, Okafor & Reyes CPAs
What a SOC 2 report actually covers for a health-tech service organization
A SOC 2 examination tests your organization's controls against the Trust Services Criteria (TSC): the mandatory Security criteria (the Common Criteria, CC1 through CC9) plus any of the optional categories — Availability, Processing Integrity, Confidentiality, and Privacy — that fit your commitments and system. For a health-tech company, that examination realistically covers:
Logical and physical access controls over the systems that store, process, or transmit PHI
Change management and system operations for the applications that touch clinical or billing data
Risk assessment processes, including how the organization identifies and treats risks to PHI-bearing systems
Monitoring activities — logging, alerting, and incident detection across the in-scope environment
Vendor and subservice organization oversight, which matters enormously in health tech given how many companies route data through cloud hosting, clearinghouses, and third-party APIs
If Confidentiality is added: specific controls over how confidential information, including PHI, is identified, protected, and disposed of
If Privacy is added: controls over the collection, use, retention, disclosure, and destruction of personal information consistent with the organization's privacy notice
None of that is a token gesture. A well-scoped SOC 2 Type II report, tested over a 6–12 month period, is genuinely rigorous evidence that your access controls, encryption practices, and incident response processes function as designed, not just on paper. That's exactly why buyers ask for it. It just isn't evidence that you've satisfied HIPAA's specific legal requirements — because SOC 2 was never written with HIPAA's statutory language in mind, and the AICPA has no authority to certify legal compliance with a federal law it doesn't administer.
What SOC 2 deliberately does not cover
This is the section most health-tech compliance teams skip, and it's the one that gets them the "where's your BAA" email. A standard SOC 2 examination, even a well-scoped one, does not by itself demonstrate:
Gap | Why SOC 2 doesn't cover it | What's actually required |
|---|---|---|
A signed Business Associate Agreement | SOC 2 is a controls attestation, not a contract | A BAA between the business associate and each covered entity/upstream business associate, per 45 CFR 164.502(e) |
Formal HIPAA risk analysis | TSC risk assessment (CC3) is broader and not statute-specific | A documented risk analysis addressing PHI confidentiality, integrity, and availability under the Security Rule |
Minimum necessary standard | Not a named TSC concept | Policies limiting PHI use/disclosure to the minimum necessary for the purpose |
Notice of Privacy Practices | Applies to covered entities, not typically business associates | Covered-entity obligation; business associates support via BAA terms |
Breach Notification Rule timelines | SOC 2 incident response criteria don't reference HIPAA's 60-day clock | HIPAA-specific breach assessment and notification procedures |
Workforce sanctions policy | Not a specific TSC requirement | A documented sanctions policy for workforce HIPAA violations |
OCR audit readiness | SOC 2 auditors are not OCR-authorized examiners | Internal HIPAA compliance program, potentially a separate HIPAA risk assessment or attestation |
42 CFR Part 2 (substance use disorder records), where applicable | Out of SOC 2's frame of reference entirely | Separate, stricter consent and disclosure controls |
Priya's mistake wasn't a technical control gap — MedFlow's engineering was solid. It was a documentation and positioning gap: nothing in MedFlow's sales materials, security page, or SOC 2 cover letter explained how the report related to HIPAA, and no BAA template was ready to send the moment Crestwood's legal team asked. That gap is what stalled a $2.4 million contract for six weeks.
PHI, ePHI, and PII: getting the definitions precise
Health-tech teams often use "PHI," "ePHI," and "PII" interchangeably, which causes real scoping errors when defining what your Confidentiality and Privacy criteria actually protect.
Term | Definition | Example in health tech |
|---|---|---|
Protected Health Information (PHI) | Individually identifiable health information created, received, maintained, or transmitted by a covered entity or business associate | A patient's diagnosis, treatment plan, or discharge summary |
Electronic PHI (ePHI) | PHI in electronic form — the subset the HIPAA Security Rule specifically governs | PHI stored in a cloud database or transmitted via API |
Personally identifiable information generally — a broader, non-health-specific category | Name, SSN, address, without a health context | |
De-identified health information | Health data stripped of identifiers per HIPAA's Safe Harbor or Expert Determination method | Aggregated, de-identified claims data used for analytics |
Sensitive PHI subcategories | PHI subject to extra legal protection beyond the general Security Rule | Behavioral health notes, substance use disorder records, HIV status, genetic information |
Scoping matters because a SOC 2 examination with Confidentiality and Privacy criteria needs a precise definition of what counts as "confidential information" and "personal information" in your system description — and for a health-tech company, that definition should explicitly name PHI and ePHI, not just use generic language borrowed from a non-health SOC 2 template.
Mapping SOC 2's Common Criteria to the HIPAA Security Rule
The most useful thing a health-tech compliance lead can do is build an internal crosswalk between the mandatory SOC 2 Common Criteria and the HIPAA Security Rule's three safeguard categories (administrative, physical, technical). They're not identical, but the overlap is substantial enough that a single, well-run control environment can serve both — with targeted additions.
SOC 2 Common Criteria | HIPAA Security Rule safeguard category | Overlap notes |
|---|---|---|
CC1 – Control environment | Administrative safeguards (workforce security, sanctions policy) | Strong overlap on governance and tone-at-the-top |
CC2 – Communication and information | Administrative safeguards (security awareness training) | Overlap on training and policy communication |
CC3 – Risk assessment | Administrative safeguards (required risk analysis) | Overlap in method; HIPAA requires PHI-specific documented risk analysis |
CC4 – Monitoring activities | Administrative safeguards (evaluation) | Strong overlap on ongoing control monitoring |
CC5 – Control activities | Administrative + technical safeguards | General overlap; HIPAA more prescriptive on specific technical controls |
CC6 – Logical and physical access | Technical safeguards (access control, encryption) + physical safeguards | Very strong overlap — access control, unique user IDs, encryption |
CC7 – System operations | Technical safeguards (audit controls) | Overlap on logging and anomaly detection |
CC8 – Change management | Not explicitly named in HIPAA, but supports overall safeguard integrity | Indirect support |
CC9 – Risk mitigation | Administrative safeguards (contingency planning) | Overlap on business continuity and disaster recovery |
This crosswalk is exactly the artifact Crestwood's security director wanted to see and didn't get. Building it once, keeping it current, and attaching it to every SOC 2 report you send to a health-tech buyer turns a 45-minute clarification call into a five-minute confirmation email.
"We don't need vendors to reinvent HIPAA language. We need one page that shows us how their existing SOC 2 controls line up to the Security Rule safeguards we're accountable for. That single page has saved more deals than any marketing brochure I've seen." — Sana Patel, Director of Vendor Risk, Crestwood Health Network
Why health-tech companies should add the Confidentiality criterion
The Common Criteria are mandatory in every SOC 2 report, but they're written broadly enough to apply to any service organization — a marketing SaaS tool and a clinical data platform can both pass a Security-only SOC 2. For a company handling PHI, that's not enough specificity. Adding the Confidentiality (TSC) criterion requires the organization to explicitly identify confidential information (PHI included), document how it's protected throughout its lifecycle, and demonstrate secure disposal when it's no longer needed. That's precisely the kind of control specificity a hospital system's vendor risk team is looking for, and precisely what's missing from a bare-bones Security-only report.
Practically, adding Confidentiality means your system description names PHI as a confidentiality category, your data classification scheme reflects PHI handling requirements, your encryption and access control narratives specifically address PHI-bearing data stores, and your data retention and destruction policies are tested against PHI specifically, not just "customer data" generically.
Why many health-tech companies should also add the Privacy criterion
The Privacy (TSC) criterion goes further than Confidentiality: it covers the full lifecycle of personal information handling — notice, choice and consent, collection, use, retention, disclosure, and disposal — measured against the organization's own privacy commitments. For health-tech companies that interact directly with patients (a telehealth app, a patient portal, a consumer health tracking tool), Privacy criteria matter because the company is making direct representations to individuals about how their health data is used, not just protecting it on behalf of a B2B customer.
Not every health-tech company needs Privacy. A pure back-office claims processing vendor that never interacts with patients directly may reasonably scope Security plus Confidentiality and skip Privacy. A consumer-facing telehealth platform that collects intake forms, manages consent, and markets directly to patients almost always should include it, because its privacy notice creates specific commitments an auditor can test.
Signal | Add Confidentiality | Add Privacy |
|---|---|---|
You store/process PHI on behalf of a covered entity (B2B) | Yes | Often not required |
You interact directly with patients/consumers | Yes | Yes |
You publish a consumer-facing privacy notice | Yes | Yes |
You handle consent management for data sharing | Yes | Yes |
You're a pure infrastructure/hosting subservice organization | Yes | Rarely |
Your buyers explicitly ask about patient data rights | Yes | Yes |
Confidentiality vs. Privacy for health data: a side-by-side
Because these two criteria are so often confused, it's worth a direct comparison specific to the health-tech context.
Aspect | Confidentiality criterion | Privacy criterion |
|---|---|---|
Primary question | Is PHI/confidential data protected from unauthorized access and disclosure? | Is personal information collected, used, retained, and disclosed as promised to individuals? |
Reference point | Organization's confidentiality commitments (contracts, data classification) | Organization's own privacy notice and applicable privacy criteria points of focus |
Typical evidence | Encryption logs, access reviews, data classification records | Consent records, privacy notice version history, data subject request logs |
Health-tech example | Encrypting a clinical database and restricting access by role | Documenting how patient consent for data sharing with a referral partner was captured and honored |
Relationship to HIPAA | Supports Security Rule confidentiality objective | Supports Privacy Rule-style transparency, though not equivalent to it |
Defining your PHI system boundary
Before an auditor can test anything, you need a precise system boundary: exactly which systems, data flows, personnel, and third parties are in scope for PHI. Health-tech environments are notoriously prone to scope creep here, because PHI tends to leak into places nobody planned for — a support ticketing tool where a clinician pastes a patient's chart number, a business intelligence dashboard built from production data, a developer's local environment used to debug a production issue.
A defensible PHI system boundary for a SOC 2 examination typically includes: the production application and database environment where PHI is created, stored, or transmitted; the identity and access management layer controlling who can reach that environment; the logging and monitoring stack that observes it; the cloud infrastructure or data center hosting it; and every subservice organization that processes PHI on the company's behalf. It should explicitly exclude, with documented justification, systems that never touch PHI, such as a marketing website's CMS or a public-facing blog — but only if that exclusion is actually true, not assumed.
"The biggest surprise in a health-tech readiness assessment is almost never the production database. It's the Slack channel where a customer success rep pasted a screenshot with a patient name in it, or the shared spreadsheet someone built for a QBR. PHI doesn't respect your architecture diagram." — Priya Nair, VP of Security & Compliance, MedFlow Health
Common subservice organizations in the health-tech supply chain
Health-tech companies rely heavily on downstream vendors, and each one is a subservice organization whose handling of PHI affects your own SOC 2 scope and your HIPAA obligations alike.
Subservice organization type | Example role | PHI exposure | Treatment in SOC 2 report |
|---|---|---|---|
Cloud infrastructure provider | Hosts production databases and application servers | High — often stores ePHI directly | Usually carve-out; provider's own SOC 2/compliance attestations referenced |
Claims clearinghouse | Routes and translates billing transactions | High — full claims data including diagnosis codes | Carve-out or inclusive, depending on integration depth |
Telehealth video infrastructure vendor | Powers video visit sessions | High — clinical conversations, sometimes recordings | Carve-out; BAA required with vendor |
Email/notification service | Sends appointment reminders, portal notifications | Variable — depends on content included | Carve-out; content minimization critical |
Customer support/ticketing platform | Handles support requests that may reference patient data | Medium-high if not controlled | Often overlooked; needs explicit scoping |
Analytics/BI tooling | Powers internal dashboards, sometimes on production data extracts | High if using raw data; low if de-identified | Frequently a gap area in readiness assessments |
Backup/disaster recovery provider | Stores backup copies of PHI-bearing systems | High | Carve-out; encryption and BAA required |
For every subservice organization above the "medium" exposure line, a health-tech company needs a signed BAA (where the vendor qualifies as a business associate or subcontractor) and a documented process for reviewing that vendor's own security posture — which is a textbook vendor risk management function that should be tested as part of your Common Criteria controls, particularly CC9.
Encryption and access controls: where PHI gets specific
Generic SOC 2 language about "encrypting sensitive data" isn't enough for a health-tech system description. Auditors testing Confidentiality criteria for a PHI-handling company expect to see PHI named specifically in the encryption and access narrative.
Control area | Generic SOC 2 practice | PHI-specific expectation |
|---|---|---|
Data encrypted using AES-256 or equivalent | ePHI-bearing databases and backups specifically enumerated and confirmed encrypted | |
TLS 1.2+ for external connections | All PHI transmission paths (API, HL7/FHIR interfaces, clearinghouse connections) confirmed encrypted | |
Role-based access to production systems | Access to PHI restricted using least privilege and reviewed against a "minimum necessary" standard | |
MFA for privileged/admin accounts | MFA extended to any account with direct PHI query or export capability | |
Audit logging | Logging of system events | PHI access, view, export, and modification events logged with user identity, timestamp, and reason where feasible |
Data disposal | Standard deletion procedures | PHI-specific destruction/cryptographic erasure procedures aligned to retention schedules |
That "minimum necessary" language deserves its own callout: HIPAA's minimum necessary standard isn't a native SOC 2 concept, but nothing stops a health-tech company from building it directly into its least privilege access model and then having its SOC 2 auditor test that model as a Confidentiality control. That's one of the cleanest ways to make a single control environment serve both frameworks at once.
Incident response and breach notification: two different clocks
This is one of the areas where health-tech teams most often get tripped up, because SOC 2's incident response expectations under CC7 and HIPAA's Breach Notification Rule look similar on the surface but run on very different timelines and triggers.
Dimension | SOC 2 incident response expectation | HIPAA Breach Notification Rule |
|---|---|---|
Trigger | Any security incident affecting the in-scope system | Unauthorized acquisition, access, use, or disclosure of unsecured PHI |
Notification timeline | Defined by organization's own policy, tested for adherence | Individuals notified without unreasonable delay, no later than 60 days |
Who must be notified | Per organization's incident response plan and contractual terms | Affected individuals, HHS, and in some cases media (for breaches affecting 500+ individuals) |
Risk assessment method | Organization-defined severity classification | Four-factor HIPAA breach risk assessment (nature of PHI, unauthorized recipient, whether PHI was viewed/acquired, mitigation) |
Documentation tested | Incident tickets, response timelines, root cause analysis | Breach risk assessments, HHS breach portal submissions, notification letters |
A health-tech company should not assume that satisfying SOC 2's incident response criteria automatically satisfies HIPAA's breach notification obligations. The safest approach is to build one incident response process with a HIPAA-specific decision branch: every incident gets triaged first through the general security process (tested by your SOC 2 auditor), and any incident involving PHI automatically routes to a HIPAA four-factor breach risk assessment (documented separately, often with legal counsel involved), regardless of whether the SOC 2 auditor ever sees that second document.
"The worst version of this I've seen is a company that had a beautiful SOC 2 incident response runbook and zero process for actually running the HIPAA four-factor test when PHI was involved. They technically passed their SOC 2 audit and still missed a breach notification deadline six weeks later." — Dr. Alicia Torres, CISO, Beacon Behavioral Health Systems
The compliance stack: how SOC 2, the BAA, and HIPAA fit together
It helps to picture this as layers rather than a single checklist. HIPAA is the legal floor everyone handling PHI must stand on. The Business Associate Agreement is the contractual bridge that formally extends a covered entity's HIPAA obligations to a business associate like a health-tech vendor. SOC 2, sitting on top, is the independent assurance mechanism that gives a buyer confidence the vendor's controls — many of which support HIPAA safeguards — actually operate as claimed.
flowchart TB
A[HIPAA — Federal Law\nSecurity, Privacy, Breach Notification Rules] --> B[Business Associate Agreement\nContractual extension of HIPAA duties]
B --> C[Health-Tech Service Organization\nInternal controls, policies, workforce training]
C --> D[SOC 2 Examination\nSecurity + Confidentiality + Privacy criteria]
D --> E[SOC 2 Type II Report\nIndependent assurance for buyers]
E --> F[Buyer Vendor Risk Review\nCombines SOC 2 report + signed BAA + HIPAA crosswalk]
C -.PHI-specific safeguards.-> DEvery layer is necessary. Skip the BAA and you're in breach of federal law regardless of how clean your SOC 2 report is. Skip the SOC 2 report and you're relying on buyers taking your word for it, which large health systems increasingly won't do. Skip the PHI-specific scoping inside SOC 2 (naming PHI in Confidentiality, tightening access controls to a minimum-necessary standard) and your report technically exists but doesn't actually answer the question a healthcare buyer is asking.
Case study: MedFlow Health closes the Crestwood deal
Back to Priya. Once Crestwood's email made the gap explicit, MedFlow moved fast. Within two weeks, the team had drafted a one-page HIPAA Security Rule crosswalk mapping their existing Common Criteria controls to the Security Rule's administrative, physical, and technical safeguards. They amended their SOC 2 scope for the next examination period to formally add the Confidentiality criterion, with PHI explicitly named as a confidentiality category in the system description. They finalized a standard BAA template, reviewed by outside counsel, ready to execute with any covered-entity customer within 48 hours of a signed order form. And they documented a HIPAA-specific breach risk assessment process that ran alongside — not instead of — their existing SOC 2 incident response plan.
The $2.4 million Crestwood deal closed 45 days later, after legal review of the BAA and a follow-up call where Priya walked Crestwood's security team through the crosswalk document directly. More importantly, MedFlow's average security questionnaire turnaround time across all deals dropped from roughly 90 days to about 12 days once the crosswalk, BAA template, and Confidentiality-scoped SOC 2 report became a standard sales-engineering package. Priya's team estimated the crosswalk document alone shaved two to three weeks off nearly every enterprise health system deal in the following two quarters.
Case study: Ridgeline Telehealth adds Privacy and saves three payer contracts
Marcus Chen, CTO of Ridgeline Telehealth, a direct-to-patient video visit platform, faced a different flavor of the same problem. Ridgeline's SOC 2 Type II report covered Security only. Three regional health plans, each representing roughly $350,000–$400,000 in annual contract value, flagged the same concern during renewal reviews: Ridgeline collected patient intake data, managed consent for sharing visit summaries with primary care physicians, and retained video session metadata — all activities that touch personal information lifecycle questions the health plans wanted addressed directly, not inferred from a Security-only report.
Ridgeline's next SOC 2 cycle added the Privacy criterion, with points of focus mapped explicitly to how the platform captured patient consent, how long video metadata was retained, and how patients could request deletion of their intake data. The examination also formalized data subject request handling as a testable control. All three payer contracts, worth roughly $1.1 million in combined annual recurring revenue, renewed without further security escalation, and Ridgeline's sales team began proactively including the Privacy-scoped report in every payer RFP from that point forward.
"Adding Privacy criteria felt like overhead until I saw how fast it de-risked payer conversations. We stopped having a 45-minute call explaining our consent model to every health plan's legal team — the report just answered the question." — Marcus Chen, CTO, Ridgeline Telehealth
Case study: Beacon Behavioral Health Systems and heightened-sensitivity data
Not all PHI carries equal regulatory weight. Beacon Behavioral Health Systems, a platform supporting outpatient behavioral health clinics, handles substance use disorder treatment records subject to 42 CFR Part 2 — a federal confidentiality regime that is, in places, more restrictive than HIPAA's general Privacy Rule around redisclosure of patient records. Dr. Alicia Torres, Beacon's CISO, worked with her SOC 2 auditor to ensure the Confidentiality criterion's points of focus explicitly distinguished "standard PHI" from "42 CFR Part 2-protected records" in the data classification scheme, with materially stricter access and disclosure controls tested for the latter category.
That extra layer of specificity became a differentiator in a strategic partnership negotiation with a multi-state behavioral health network evaluating three vendors. Beacon was the only finalist whose SOC 2 report explicitly addressed the heightened confidentiality requirements around substance use disorder records, and it won the partnership — an engagement Dr. Torres estimated at roughly $900,000 in first-year contract value — in part because procurement didn't have to ask the follow-up question the other two finalists couldn't answer cleanly.
Common gaps in health-tech SOC 2 readiness assessments
Across dozens of health-tech readiness assessments, the same handful of gaps show up repeatedly. Knowing them in advance saves weeks of remediation scrambling once an auditor is already engaged.
Gap area | What typically goes wrong | Remediation effort |
|---|---|---|
PHI not explicitly named in system description | Generic "customer data" language obscures PHI handling | Low — documentation rewrite |
No HIPAA-to-SOC 2 crosswalk | Sales/legal can't quickly answer buyer questions | Low — one-time mapping exercise |
Missing BAA templates or tracking | No standard BAA ready, or unclear which customers have signed | Medium — legal template + CRM tracking |
PHI leaking into unscoped tools | Support tickets, BI dashboards, Slack contain PHI outside system boundary | Medium-high — tooling controls, redaction, training |
Subservice organization BAAs incomplete | Vendors handling PHI lack signed BAAs | Medium — vendor outreach and contract remediation |
No minimum-necessary access model | Broad access roles instead of PHI-specific least privilege | Medium-high — access model redesign |
Incident response lacks HIPAA breach risk assessment step | Team responds to incidents but never runs the four-factor HIPAA test | Low-medium — process addition |
Confidentiality/Privacy criteria not added despite PHI exposure | Company relies on Security-only report | Low — scope decision, requires next audit cycle |
Workforce HIPAA training conflated with general security awareness training | No PHI-specific training content or sanctions policy | Low-medium — training content update |
De-identification methodology undocumented | Analytics team assumes data is "anonymized" without formal method | Medium — apply Safe Harbor or Expert Determination formally |
"Ninety percent of the health-tech gap findings I write up aren't exotic. They're a company that built genuinely good security and just never translated it into HIPAA-specific language a hospital's legal team can point to." — James Okafor, Partner, Okafor & Reyes CPAs
Cost and timeline: scoping SOC 2 for PHI in health tech
Adding Confidentiality and Privacy criteria, plus PHI-specific control work, extends both cost and timeline relative to a bare-Security SOC 2 — though less than most founders fear, especially if the underlying security program is already solid.
Phase | Security-only SOC 2 (baseline) | + Confidentiality (PHI-scoped) | + Privacy (patient-facing) |
|---|---|---|---|
Readiness assessment | 3–5 weeks | 4–6 weeks | 5–7 weeks |
Remediation | 6–10 weeks | 8–12 weeks | 10–14 weeks |
Type I examination (if used) | 2–4 weeks | 2–4 weeks | 3–5 weeks |
Type II observation period | 6–12 months | 6–12 months | 6–12 months |
Estimated incremental audit fees | Baseline | +10–20% | +15–25% |
Ongoing evidence collection burden | Moderate | Moderate-high (PHI-specific logs) | High (consent/DSR tracking) |
These figures are illustrative, drawn from patterns across health-tech engagements rather than a published benchmark, and any individual company's timeline depends heavily on how mature its access control and data classification practices already are before the readiness assessment starts.
HITRUST, HIPAA attestations, and where SOC 2 fits among health-tech frameworks
Health-tech buyers sometimes ask about frameworks beyond SOC 2 entirely — most commonly the HITRUST CSF, a health-industry-specific certifiable framework that explicitly incorporates HIPAA requirements into its control set. HITRUST and SOC 2 are not competitors; they answer different depths of the same question, and some health-tech companies eventually pursue both, particularly if enterprise health system buyers specifically require HITRUST certification in their vendor policies. A useful way to think about it: SOC 2 with Confidentiality and Privacy criteria, paired with a HIPAA risk analysis and a signed BAA, satisfies the large majority of health-tech buyers. HITRUST becomes relevant when a specific buyer's procurement policy mandates it, or when a company wants a single certifiable framework that maps directly to HIPAA language rather than relying on a crosswalk document.
Some CPA firms with healthcare specialization now offer combined engagements — a SOC 2 examination performed alongside a separate HIPAA Security Rule risk assessment, delivered as companion documents rather than a single report (since a CPA firm's SOC 2 opinion cannot legally represent "HIPAA compliance," they remain distinct deliverables even when bundled operationally). This bundled approach is increasingly common in health tech specifically because it solves the exact problem Priya ran into: one engagement, one evidence-collection cycle, two clearly labeled outputs that together answer both halves of a buyer's question.
Framework/artifact | What it demonstrates | Issued by | Legal status |
|---|---|---|---|
SOC 2 (Security + Confidentiality + Privacy) | Controls operate effectively against Trust Services Criteria | Licensed CPA firm | Voluntary attestation |
HIPAA risk analysis | PHI-specific risk identification and treatment | Internal team or third-party advisor | Required under Security Rule |
Business Associate Agreement | Contractual HIPAA obligations between parties | Negotiated between covered entity/business associate | Legally required for PHI-handling relationships |
HITRUST CSF certification | Comprehensive, health-industry-specific control certification incorporating HIPAA | HITRUST-authorized assessor | Voluntary, increasingly required by some large payers |
SOC 3 | Public-use summary of a SOC 2 | Licensed CPA firm | Voluntary, freely distributable |
Vendor risk management across the health-tech supply chain
A health-tech company's own PHI protection is only as strong as its weakest subservice organization. That makes vendor risk management a first-class control area, not an afterthought bolted onto procurement. A mature program tracks, for every vendor touching PHI: whether a BAA is signed and current, whether the vendor holds its own SOC 2 report (and whether Confidentiality is included), what carve-out or inclusive treatment applies in the company's own SOC 2 system description, and how frequently the vendor relationship is reassessed.
Vendor risk activity | Frequency | Owner | Evidence for SOC 2 auditor |
|---|---|---|---|
Initial vendor security review | Before contract signature | Security/procurement | Vendor questionnaire, SOC 2 report review |
BAA execution tracking | At onboarding, reviewed annually | Legal/compliance | Signed BAA repository |
Subservice organization SOC 2 report review | Annually, or on report renewal | Security | Documented review notes, exceptions tracked |
Data flow mapping update | Annually or on material change | Engineering/security | Updated data flow diagram, system description |
Vendor offboarding PHI destruction confirmation | At contract termination | Security/legal | Data destruction certificate |
Working with auditors who understand health tech
Not every CPA firm performing SOC 2 examinations has deep healthcare-sector experience, and that gap shows up in exactly the ways this article has described: system descriptions that never name PHI, Confidentiality criteria tested generically instead of against health-data-specific risks, and no meaningful connection drawn to HIPAA safeguards even where one would help the client. When evaluating an audit firm for a health-tech engagement, ask directly how many healthcare or health-tech clients they've examined, whether they're comfortable reviewing a HIPAA-to-SOC 2 crosswalk as supplementary context (even though it sits outside their formal opinion), and whether their sampling approach for access reviews accounts for PHI-specific minimum-necessary questions.
"The best auditors we've worked with don't try to opine on HIPAA — that's not their job and a good one will tell you that directly. But they will ask sharper questions about PHI access scoping than a generalist auditor would, because they've seen where health-tech companies actually get this wrong." — Ben Whitfield, Privacy Counsel, MedFlow Health
Using your SOC 2 report in health-tech sales and marketing
A properly scoped SOC 2 report, paired with a BAA template and a HIPAA crosswalk, becomes a genuine sales accelerant rather than a defensive document. Health-tech companies that handle this well typically publish a security overview page referencing their SOC 2 Type II status (without disclosing the restricted-use report itself publicly), operate a gated trust portal where prospects under NDA can review the full report, the crosswalk document, and a redacted sample BAA, and train sales engineers to proactively surface the crosswalk the moment a healthcare prospect's security questionnaire includes both "SOC 2" and "HIPAA" in the same section — which, per this article's opening example, is nearly always.
Sales enablement asset | Purpose | Distribution |
|---|---|---|
SOC 2 Type II report | Full technical/audit evidence | Gated trust portal, NDA-protected |
HIPAA-to-SOC 2 crosswalk (one-pager) | Fast answer to the most common buyer question | Sales engineering, RFP responses |
BAA template | Speeds legal review | Shared at contract stage |
Public security overview page | Top-of-funnel trust signal | Company website |
SOC 3 report (if applicable) | Freely shareable summary | Public distribution |
Common mistakes health-tech companies make with SOC 2 and HIPAA
Even well-resourced teams repeat a predictable set of errors. Naming them explicitly is often the fastest way to avoid them.
Mistake | Why it happens | Consequence |
|---|---|---|
Marketing SOC 2 as "HIPAA certified" | Sales team simplifies for speed | Legal exposure, buyer distrust once discovered |
Treating BAA execution as a legal afterthought | No standard template ready | Deal delays, contract renegotiation |
Scoping SOC 2 to Security only despite heavy PHI exposure | Cost/time minimization | Buyer follow-up questions, lost deals |
Assuming cloud provider's HIPAA-eligible services make the company compliant | Misunderstanding shared responsibility | Gaps in the company's own safeguards |
No PHI-specific incident response branch | General IR plan assumed sufficient | Missed HIPAA breach notification deadlines |
Letting PHI leak into unscoped SaaS tools | No data flow governance | Expanded, unmanaged system boundary |
Never updating the HIPAA risk analysis after architecture changes | Treated as a one-time exercise | Stale risk analysis, audit finding risk |
Health-tech SOC 2 + HIPAA readiness checklist
# | Readiness item | Status owner |
|---|---|---|
1 | PHI and ePHI explicitly defined in data classification policy | Security |
2 | System boundary documented, including all PHI touchpoints | Security/Engineering |
3 | BAA template finalized and legally reviewed | Legal |
4 | BAA tracking system in place for all customers/vendors | Legal/Compliance |
5 | HIPAA risk analysis completed and current | Compliance |
6 | HIPAA-to-SOC 2 Common Criteria crosswalk documented | Compliance |
7 | Confidentiality criterion added to SOC 2 scope (if PHI-handling) | Compliance/Audit liaison |
8 | Privacy criterion evaluated and added if patient-facing | Compliance/Audit liaison |
9 | Minimum-necessary access model implemented | Security/Engineering |
10 | MFA enforced for all PHI-access accounts | Security |
11 | Encryption confirmed for all PHI at rest and in transit | Engineering |
12 | Subservice organizations inventoried with BAA status tracked | Security/Legal |
13 | Incident response plan includes HIPAA breach risk assessment step | Security/Legal |
14 | Workforce HIPAA-specific training deployed | HR/Compliance |
15 | Sanctions policy for HIPAA violations documented | HR/Compliance |
16 | Sales/trust portal materials distinguish SOC 2 from HIPAA compliance | Marketing/Sales |
SOC 2 as a health-tech growth lever, not just a gate
It's tempting to treat this entire topic as risk management — closing gaps so deals don't stall the way Priya's did. That's true, but it understates the opportunity. Health-tech buyers are becoming more sophisticated, not less, and the vendors who can hand over a Confidentiality- and Privacy-scoped SOC 2 report, a current BAA, and a one-page HIPAA crosswalk before being asked are the ones shortening their own sales cycles relative to competitors still fumbling through the same questions Crestwood asked MedFlow. In a market where hospital systems, payers, and digital health platforms are all tightening vendor risk requirements simultaneously, a company that has clearly separated — and clearly connected — its SOC 2 posture from its HIPAA compliance program isn't just avoiding friction. It's turning a compliance requirement into a differentiator procurement teams notice and reward with faster yes decisions.
For organizations building an information security management system that needs to support both HIPAA and international frameworks, it's also worth understanding how ISO 27001 for Healthcare Organizations and HIPAA (/iso27001/iso-27001-for-healthcare-organizations-hipaa) approaches the same underlying problem from a certifiable-ISMS angle rather than an attestation angle — many health-tech companies operating internationally eventually run both programs in parallel, much the way Running ISO 27001 and SOC 2 Together describes for organizations pursuing multiple frameworks at once. Understanding ISO 27001 vs SOC 2: which one do you need is a useful next step for health-tech leaders weighing both paths.
Getting there with PentesterWorld
If your team is scoping a SOC 2 examination for a PHI-handling system for the first time, or expanding an existing report to add Confidentiality and Privacy criteria, start with a structured readiness assessment rather than jumping straight into an audit engagement — it's the fastest way to surface the PHI-specific gaps this article walks through before an outside auditor finds them for you. PentesterWorld's SOC 2 Readiness Checklist (/resources/soc-2-readiness-checklist) is built around exactly this kind of PHI-aware scoping exercise, and our SOC 2 Trust Services Criteria Mapping Template (/resources/soc-2-tsc-mapping-template) gives your compliance team a starting point for the HIPAA-to-SOC 2 crosswalk described above. Pair either with our SOC 2 vs ISO 27001 Comparison Guide (/resources/soc-2-vs-iso-27001-comparison-guide-ebook) if you're also evaluating a certifiable path alongside your attestation work — and if you're not sure where your program stands today, our "Are You SOC 2 Ready?" Quiz (/resources/are-you-soc-2-ready-quiz) is a fast, no-commitment way to find out before you engage an auditor.