SOC 2 and HIPAA overlap for SaaS companies

If you already have SOC 2 Type 2, you are roughly 60-70% of the way to HIPAA. That is not a marketing claim. It is a practical reality of how the control requirements overlap.

Most SaaS companies first encounter HIPAA when a healthcare prospect asks about it during a security review. The immediate reaction tends to be dread, because HIPAA sounds like an entirely separate compliance mountain to climb. But if you have already done the work for SOC 2, much of the foundation is already in place. The gap is real, but it is smaller than you think.

Where the two frameworks share ground

SOC 2 and HIPAA come from different places. SOC 2 is an attestation framework defined by the AICPA, focused on how service organizations protect data generally. HIPAA is federal law, focused specifically on protecting health information. Different origins, different enforcement mechanisms, but a surprising amount of shared territory in what they actually require you to do.

The AICPA’s Trust Services Criteria map closely to several HIPAA Security Rule requirements. According to Censinet’s cross-mapping analysis, organizations that have achieved SOC 2 compliance may be up to 65% of the way toward HIPAA compliance based on shared controls alone. That figure lines up with what we have seen at Tallyfy when working through our own compliance journey.

Five areas carry the strongest alignment between the two frameworks:

Access controls. SOC 2 criteria CC6.2 and CC6.3 require you to manage logical access to systems, authenticate users, and restrict access based on roles. HIPAA’s technical safeguards under 164.312(a)(1) require essentially the same thing: technical policies and procedures that allow access only to authorized persons or software programs. If you have role-based access controls, unique user IDs, and a process for provisioning and deprovisioning access, you are covering both frameworks with the same control.

Encryption. SOC 2 criterion CC6.1 and CC6.7 address encryption at rest and in transit. HIPAA’s 164.312(a)(2)(iv) and 164.312(e)(1) address the same requirements for electronic protected health information. The implementation is identical. AES-256 at rest and TLS 1.2 or higher in transit satisfies both.

Audit logging. SOC 2 criterion CC7.2 requires monitoring system components for anomalies. HIPAA’s 164.312(b) requires hardware, software, and procedural mechanisms that record and examine activity in systems containing PHI. Same logs, same alerting, same review processes.

Incident response. SOC 2 criteria CC7.3 and CC7.4 cover evaluating security events and responding to identified incidents. HIPAA’s 164.308(a)(6) requires a security incident response and reporting process. Your incident response plan, your escalation procedures, your post-incident review process all serve double duty.

Password and authentication policies. SOC 2 criterion CC6.1 covers authentication mechanisms. HIPAA’s 164.312(d) covers person or entity authentication. Password complexity requirements, multi-factor authentication, session timeout controls. One implementation, two frameworks satisfied.

SOC 2 and HIPAA share roughly 65% of control requirements

What HIPAA adds that SOC 2 does not cover

The overlap is significant, but HIPAA is not just SOC 2 with a healthcare sticker on it. Several requirements have no real equivalent in the SOC 2 Trust Services Criteria.

The biggest gap is the concept of protected health information itself. SOC 2 does not define specific data categories. It talks about “user entity data” and “confidential information” generally. HIPAA defines PHI precisely and imposes rules about how it can be used, disclosed, and shared that go well beyond security controls. The HHS summary of the HIPAA Security Rule makes clear that every safeguard ties back to this specific data category.

The minimum necessary standard is a HIPAA concept with no SOC 2 equivalent. This rule requires that covered entities and business associates make reasonable efforts to limit PHI access to only what is needed for a specific purpose. SOC 2 wants you to restrict access based on roles. HIPAA goes further. It wants you to think about every access request and ask whether the person actually needs that specific piece of health data.

Breach notification is another area where HIPAA adds specific requirements. SOC 2 expects you to have incident response procedures. HIPAA dictates exactly what happens after a breach of unsecured PHI. The Breach Notification Rule requires notification to affected individuals within 60 days of discovering a breach. Breaches affecting more than 500 individuals require notification to prominent media outlets and to the Secretary of HHS. The clock starts when the incident is first known, not when the investigation concludes.

HIPAA also imposes workforce training requirements that are more specific than SOC 2’s general security awareness expectations. Under 164.308(a)(5), covered entities must implement a security awareness and training program for all workforce members, including management. This training has to address specific HIPAA concepts, not just general security hygiene.

Then there is the risk analysis requirement under 164.308(a)(1). SOC 2 expects risk assessment as part of its Common Criteria. HIPAA mandates a formal risk analysis specific to PHI. This is the single most enforced requirement in HIPAA enforcement actions. Since early 2025, the HHS Office for Civil Rights has announced multiple resolution agreements with covered entities specifically for risk analysis failures, with penalties reaching into the millions.

Controls that do double duty

For practical purposes, here is how your existing SOC 2 policies map to HIPAA requirements. If you have been through a SOC 2 Type 2 examination, you probably already maintain most of these.

Your Data Classification Policy serves both frameworks. Under SOC 2, it defines how you categorize and protect data. For HIPAA, you extend it to explicitly classify PHI and specify handling rules. The policy structure stays the same. You add a classification tier.

Your Encryption Policy is already doing the work. If you have documented your encryption standards for data at rest and in transit, and those standards meet current best practices, both SOC 2 and HIPAA are satisfied. No rewrite needed.

Your Logical Access Policy covers user provisioning, role-based access, authentication requirements, and access reviews. Both frameworks want this. For HIPAA, you add language about the minimum necessary standard and PHI-specific access considerations.

Your Incident Response Policy handles detection, triage, containment, eradication, and recovery. Managing these policies as code makes dual-framework updates straightforward. SOC 2 is satisfied. For HIPAA, you bolt on the specific breach notification timelines and the process for determining whether a breach involves unsecured PHI. We’ve written about how we manage these policies with AI and Google Drive rather than paying for a compliance platform, and the same approach works for both frameworks.

Your Vendor Management Policy covers third-party risk assessment. For HIPAA, you extend it to require Business Associate Agreements with any subcontractor that touches PHI. More on that in a moment.

Organizations that align their controls across both frameworks can reduce redundant compliance work by 30-40% according to Censinet’s mapping study. That reduction is real. It comes from not writing duplicate policies, not running parallel evidence collection processes, and not treating each audit as an isolated exercise.

The Business Associate Agreement question

This is where many SaaS companies get stuck. You can have every technical control in place and still not be HIPAA-ready because you don’t have a Business Associate Agreement.

A BAA is a contract required by HIPAA between a covered entity and any business associate that creates, receives, maintains, or transmits PHI on its behalf. If your SaaS product touches patient data in any way, even temporarily, you need one. The HHS provides sample BAA provisions that spell out the required elements.

A BAA is not a technical control. It is a legal instrument that defines responsibilities: permitted uses of PHI, safeguard requirements, breach reporting obligations, and subcontractor management. Without a signed BAA, both the SaaS vendor and the healthcare provider face liability in a breach scenario.

Here is what trips people up. A BAA requires your organization to actually do the things it says. If your BAA states you will encrypt PHI at rest with AES-256 and you don’t, that is a breach of contract on top of a HIPAA violation.

For subcontractors, HIPAA extends the chain. If you use AWS to host your application and it processes PHI, you need a BAA with AWS. AWS offers BAAs to qualifying customers through their compliance program. Same applies to any infrastructure provider or third-party tool that might encounter PHI.

SOC 2 does not require Business Associate Agreements. It expects vendor management and third-party risk assessment, but the specific contractual instrument of a BAA is purely a HIPAA construct. This is the clearest example of something you cannot satisfy with SOC 2 controls alone.

Practical path from SOC 2 to HIPAA

If you already have a clean SOC 2 Type 2 report, here is a realistic path to HIPAA readiness.

Start with a gap assessment. Take your existing SOC 2 control matrix and map each control to the corresponding HIPAA requirement. The AICPA provides formal mappings between Trust Services Criteria and other frameworks. The same cross-mapping exercise applies when comparing SOC 2 to ISO 27001. You will find that most of your Security and Availability controls map directly. Your gaps will cluster around PHI-specific requirements, breach notification procedures, and the Privacy Rule.

Consider a SOC 2+ examination. This is a standard SOC 2 Type 2 examination with additional HIPAA criteria included in the scope. Your CPA firm tests your controls against both frameworks in a single audit cycle. One set of evidence requests. One examination period. One report that covers both. This is significantly more efficient than running two separate compliance programs. We’ve explained the difference between Type 1 and Type 2 examinations elsewhere, and for the SOC 2+ approach, Type 2 is the standard expectation.

Conduct a PHI-specific risk analysis. Your SOC 2 risk assessment process is a good starting point, but HIPAA requires you to specifically identify where PHI exists in your systems, how it flows, and what threats apply to it. Document this separately. HHS enforcement data consistently shows this is the area where organizations fail. The penalties are not hypothetical. HHS has collected $144 million in settlements and civil money penalties to date, and risk analysis failures are the most common trigger.

Write the HIPAA-specific policies you don’t already have. You probably need a Privacy Impact Assessment process, a formal breach notification procedure with the 60-day timeline, PHI-specific workforce training materials, and a BAA template. Everything else, your access control policy, your encryption standards, your incident response plan, already exists from SOC 2. You are extending, not starting over.

Get your BAA ready before your first healthcare customer. Don’t wait for the deal to close. Have your legal team draft a BAA based on the HHS sample provisions, make sure your technical controls actually back up every clause, and keep it ready. Healthcare sales cycles are long enough without adding compliance delays.

The path from SOC 2 to HIPAA is not trivial. But it is not starting from zero. The companies that recognize the overlap early and build their compliance programs to serve both frameworks spend far less effort than those who treat each framework as an isolated project. If you already have the attestation, you have the foundation. Build on it.