A healthtech vendor is ready for an enterprise deal with a clean SOC 2 Type II report in hand. But their confidence comes to nothing, when the procurement team backtracks during the talk.
Turns out, the red flags are not around SOC 2’s Trust Services Criteria. They are about a non-existent risk analysis, missing parameters in Business Associate Agreements, and a notification clock that doesn’t align with HIPAA’s 60-day window. The SOC 2 report answers none of them.
That gap between attestation that you have controls and your legal obligations is where healthcare organizations get hurt. And the numbers around it are not small.
We are halfway into 2026 and, so far, 31 business associates have reportedly been breached out of 252 total data breach incidents. Censinet’s 2025 Healthcare Cybersecurity Benchmarking Study traced 72% of healthcare data breaches to third-party vendors, and business associates were implicated in 37% of all reported healthcare breaches in 2025 to date.
The shocking fact of the matter is that all these business associates are required by law to be HIPAA-compliant, and many organizations that were breached had SOC 2 reports. But due to misconfigured controls, they had gaps.
And those gaps are widening.
What many companies preparing for both SOC 2 and HIPAA miss is that they have almost similar controls. You cannot treat one as a stand-in for the other.
In this blog, let’s break down where the two frameworks overlap, where they diverge, and the best way for health tech startup to manage SOC 2 and HIPAA together.
Where Do SOC 2 and HIPAA Overlap?
Most organizations frame it as SOC 2 vs HIPAA, which implies they are alternatives. They are not.
One is federal law, while the other is a voluntary attestation against a private control framework. Understanding that distinction is the foundation for understanding compliance.
HIPAA is enforced by the HHS Office for Civil Rights. Three rules, the Privacy Rule, the Security Rule, and the Breach Notification Rule carry the operational weight. They may serve different functions, but the main thing they protect is PHI through controls, safeguards, and accountability.
HIPAA applies to covered entities and their business associates. It is mandatory for anyone who touches PHI. Critically, there is no such thing as HIPAA certification. Compliance is evidenced through a documented risk analysis and enforced reactively through complaints, breaches, and audits by OCR. This legal status is exactly what separates HIPAA from any voluntary security framework like SOC 2.
SOC 2 is not a law and involves no government body. It is a report produced by a licensed CPA firm against the AICPA’s Trust Services Criteria. The criteria span five categories, of which, only Security is mandatory.
A SOC 2 report comes in two forms. A Type I attests that controls are suitably designed at a single point in time. A Type II tests whether those controls operated effectively over a period of time, typically twelve months. Type II is what enterprise procurement actually wants, because it speaks to operation, not just design.
A healthtech company selling into hospitals usually needs both HIPAA (healthcare law requires it) and SOC 2 (because enterprise procurement teams will require it).
This SOC 2 vs HIPAA comparison summarizes the distinction at a glance before we turn to where the two frameworks overlap:
Federal law, enacted 1996
Voluntary attestation against the AICPA Trust Services Criteria
Authority
Enforced by the HHS Office for Civil Rights
Examined and signed by a licensed CPA firm
Is it mandatory?
Yes, for any entity that handles PHI
No; driven by customer and market demand
Certification
None exists. Compliance is self-determined
No certificate. It is a Type I or Type II report
Validity
Ongoing legal obligation
Point-in-time (Type I) or over a period (Type II), usually renewed yearly
Scope
All PHI wherever it lives in the organization
A defined system and the chosen Trust Services Criteria
Primary driver
Legal compliance and patient protection
Sales enablement and vendor due diligence
The two frameworks converge in some parts because both are fundamentally about protecting sensitive data through layered controls.
A SOC 2 and HIPAA mapping overlap over identity and access management, logging and monitoring, incident response, change management, encryption, and risk management.
In Trust Services Criteria terms, CC6 through CC8 and CC3 align well with HIPAA’s technical and administrative safeguards, and CC6 aligns with HIPAA’s physical safeguards.
A mature SOC 2 Security program already covers a large share of the HIPAA Security Rule’s technical and administrative requirements. The efficient move is not to run two parallel programs but to build one integrated control set, perform the risk analysis once, and map a single body of evidence to both regimes.
A SOC 2 Type II report is also legitimate evidence of your HIPAA compliance. It demonstrates a business associate’s posture to a covered entity assessing risk. For most vendors, a healthcare SOC 2 effort is far less daunting when it is built on an existing HIPAA foundation rather than started from scratch.
Where Do SOC 2 and HIPAA Diverge?
While HIPPA and SOC 2 sure have overlapping controls, where they diverge are where the gaps exist.
- The Privacy Difference: SOC 2’s Confidentiality and Privacy categories protect restricted and personal information broadly, but their scope diverges from HIPAA’s Privacy Rule, which governs PHI uses and disclosures.
HIPAA is the minimum necessary standard for any healthcare organization dealing with PHI along with patient rights such as access and amendment. Most SOC 2 reports do not even include the Privacy category, and none of them discharge HIPAA Privacy Rule obligations.
- Breach Notification: HIPAA imposes a legal 60-day notification duty with defined recipients and timelines. SOC 2 has no breach notification requirement at all.
- Business Associate Agreements: HIPAA mandates a specific contractual instrument between covered entities and business associates. SOC 2 addresses vendor risk through its criteria but has no equivalent legal contract; BAAs are a HIPAA-only item that must be documented separately.
- Independent Attestation vs. Self-Determination: SOC 2 is tested and signed by an independent CPA firm. HIPAA has no such equivalent process. The risk analysis is self-performed, though OCR audits exist.
- Scope: SOC 2 is scoped to a defined “system.” HIPAA in healthcare applies to PHI wherever it lives across the organization, regardless of system boundary.
Worth flagging for any team running on a cloud computing platforms like AWS or Azure is that a cloud provider BAA covers the infrastructure layer only. It does not cover how an application handles PHI once data arrives, and neither framework closes that gap automatically. The application layer remains the vendor’s responsibility.
How to Break the "We’re SOC 2 Certified, So We’re HIPAA Compliant" Myth?
This is the most common and most expensive misconception among healthtech startups, and there are three reasons why the statement doesn’t hold water.
First of all, SOC 2 is not a certification. It is an attestation that is tied to a specific window of time.
A Type II report shows that the controls you have opted for are operating effectively across an observation period. It does not guarantee they are operating today after the observation period is over, and it never brings up controls that were never in scope.
Secondly, HIPAA compliance is a legal status that SOC 2 cannot confer. HIPAA is federal law, while SOC 2 is market driven as it is expected by enterprise clients if you use cloud services.
A signed SOC 2 report does not satisfy the Privacy Rule, does not create the BAAs HIPAA requires, and does not establish the breach notification process the law mandates. An auditor’s opinion is not a regulator’s finding.
Third, an attestation is a snapshot, not a shield. The Change Healthcare incident is the now a cautionary version as the company had a SOC 2 report and yet failed to find the gap that attackers exploited.
The gap was a single access path without multi-factor authentication. The Change Healthcare attack became the largest healthcare breach on record. Procurement teams still accept a SOC 2 report, but it can never be a substitute for HIPAA compliance. Treating both the same is how the gap opens.
What Are the Best Practices Regarding SOC 2 and HIPAA?
The best way for health tech startup to manage SOC 2 and HIPAA together is by having a common risk assessment framework and then mapping the controls to each framework, so as to reduce duplication. This is the best approach to go for these two frameworks. The following best practices reflect what OCR is actively enforcing under HIPAA and what procurement actually checks in a SOC 2 report.
- Treat HIPAA as the base and SOC 2 as a layer above it.
If the organization handles PHI, HIPAA is non-negotiable and comes first. SOC 2 is layered on when commercial demand requires it, which for B2B healthtech is almost always. HIPAA is the first step and a strong foundation for the SOC 2 work that follows.
- Build one unified control framework with a documented crosswalk.
Map each HIPAA safeguard to the corresponding SOC 2 control and tie both to a single body of evidence. Gather each access review, log sample, and policy once, and apply it across both frameworks rather than producing it twice times for two audiences.
- Run the risk analysis.
Risk analysis is the most frequently cited HIPAA Security Rule failure in OCR enforcement. But what many miss is that it also underpins SOC 2’s CC3.
A risk analysis or assessment must identify every location where ePHI is created, received, maintained, or transmitted, assess the threats, and document the control decisions.
You should also note that a penetration test is not a substitute for risk analysis. They answer two different questions.
- Close the HIPAA-only gaps explicitly.
BAAs with every vendor that touches PHI, a breach response plan built to the 60-day clock with named owners, and Privacy Rule obligations including patient access rights all sit outside the SOC 2 overlap. They have to be documented on their own.
- Do not rely on the attestation alone.
Independent penetration testing is the connective tissue between the two frameworks. SOC 2 auditors increasingly expect pentest evidence, something that the proposed Security Rule update would make mandatory on an annual basis.
A pentest will help you find gaps like a missing MFA, which was the whole reason for the Change Healthcare breach.
- Own the application layer.
If you are running your product on AWS, Azure, or GCP, remember that a signed BAA only covers infrastructure, not the application’s handling of PHI.
Other than that access controls, audit logging, transmission encryption, and integrity controls have to be implemented in the product, not assumed that they are present with the cloud configuration.
How Can KLEAP Help?
KLEAP works with healthtech platforms, EHR and digital health vendors, and healthcare organizations to close the distance between a compliance posture that reads well on paper and one that survives OCR scrutiny and enterprise procurement at the same time.
Our engagements are manual and evidence-based. We do not hand over automated scan output repackaged as a compliance deliverable.
A dedicated expert maps your HIPAA safeguards and SOC 2 controls to a single crosswalk, identifies where the frameworks genuinely overlap and where the HIPAA-only obligations sit, and validates the technical controls through hands-on testing rather than a questionnaire.
Our concierge model means that expert stays with you from the compliance and advisory work through the testing and the documentation that has to hold up under investigation.
The question that matters is not whether you hold a SOC 2 report or believe you are HIPAA compliant. It is whether you can demonstrate both with documented evidence if a customer’s security team or a regulator asks.
If you want to understand where your current posture stands, that is where we will start the conversation.
