Two Frameworks, One Security Program

If you build software for healthcare organizations — hospitals, clinics, health plans, or digital health platforms — you're almost certainly subject to HIPAA. You're also likely to face SOC 2 requirements from enterprise healthcare buyers who need assurance beyond what HIPAA mandates.

HIPAA and SOC 2 are not the same thing, and one does not substitute for the other. Understanding how they interact is essential to building a single security program that satisfies both without duplicating work.

HIPAA vs. SOC 2: Different Frameworks, Different Purposes

HIPAA (Health Insurance Portability and Accountability Act) is a US federal law. Its Security Rule requires covered entities and business associates to implement administrative, physical, and technical safeguards for protected health information (PHI). Compliance is mandatory for any entity that creates, receives, maintains, or transmits PHI. There is no attestation report from an independent auditor — compliance is self-assessed and enforced by OCR investigations.

SOC 2 is a voluntary attestation standard from the AICPA. A licensed CPA firm evaluates your controls against the Trust Services Criteria and issues a report. Enterprise buyers use SOC 2 reports to evaluate vendor security without conducting their own audits.

The critical distinction: HIPAA is the legal floor for PHI protection. SOC 2 is the commercial signal that demonstrates security maturity to buyers. A healthtech SaaS company needs both for different reasons.

When Do Healthtech Companies Need SOC 2?

SOC 2 becomes necessary when:

• Healthcare enterprise buyers require it during vendor procurement
• Health system security teams ask for it as part of a vendor assessment
• Health plan partners require it before data-sharing integrations
• You're competing against vendors who already have it

Typical trigger point: when you start selling to health systems, large physician groups, or health plans with formal procurement teams.

How HIPAA's Safeguards Overlap with SOC 2

The HIPAA Security Rule's technical safeguards align closely with SOC 2's Common Criteria, particularly CC6 (logical access) and CC7 (monitoring). A single technical implementation can satisfy both.

|---|---|---| Implement these technical controls once, document them in a way that maps to both frameworks, and collect evidence that satisfies both auditors. The HIPAA Security Risk Analysis becomes part of your SOC 2 risk register. Your HIPAA policies become part of your SOC 2 policy library.

Business Associate Agreements and SOC 2 Scope

Every customer that shares PHI with you requires a Business Associate Agreement (BAA). Your BAAs are both a legal requirement and an SOC 2 scope item — auditors will review a sample of your BAAs during a Type II audit to verify that your subcontracting and data-handling agreements are in place.

For SOC 2 purposes, your BAA obligations flow into CC9 (vendor and business partner risk management) and CC6 (access controls). Auditors will check that your contracts reflect your stated security commitments.

PHI Handling and SOC 2 Evidence

At rest: Encryption of databases and storage volumes containing PHI. On AWS, this means RDS encryption with KMS, S3 server-side encryption, and EBS volume encryption. See [AWS encryption best practices for SOC 2](/blog/aws-encryption-best-practices-soc2).

In transit: TLS 1.2 or higher for all API endpoints and internal service communication.

Access controls: No standing access to production PHI for engineers without an approval workflow. Audit logs of every access event. Quarterly access reviews for accounts with PHI access. See the [SOC 2 access review process guide](/blog/soc2-access-review-process-guide).

Breach detection: AWS GuardDuty for infrastructure threats, CloudTrail for API-level access, application-level logging for PHI access patterns. HIPAA requires documenting security incidents; SOC 2 requires a formal incident response process. Build one program that satisfies both.

HITRUST: A Third Option for Healthcare

HITRUST CSF incorporates HIPAA, SOC 2, NIST, and other standards into a single certifiable framework specifically for healthcare. For some enterprise health system buyers, HITRUST is the preferred vendor attestation.

HITRUST is more expensive and time-consuming than SOC 2 alone (typically $80,000–$200,000+ and 12–18 months for a first certification). Consider HITRUST when you're selling primarily to large health systems or national health plans that specifically require it.

For most early-stage healthtech SaaS companies, SOC 2 Type II plus a mature HIPAA compliance program is the right starting point.

Practical Path: One Program, Two Certifications

Start with a Security Risk Analysis: HIPAA requires it; it doubles as your SOC 2 risk register.

Build policies that satisfy both: Your acceptable use policy, incident response plan, and access control policy should reference both HIPAA and SOC 2 criteria. See [SOC 2 information security policy guide](/blog/soc2-information-security-policy-guide).

Implement technical controls once: Every technical safeguard you implement for HIPAA generates SOC 2 evidence. Configure AWS to collect that evidence automatically.

Pursue SOC 2 Type I first: This gives you a report to share with buyers while you build the 6-month observation window for Type II.