SOC 2 vs HIPAA is the wrong framing for most healthcare organizations, because you usually need both.
SOC 2 proves to customers that your security controls work. HIPAA is the federal law that governs how you protect patient health information. Organizations subject to HIPAA may also need a SOC 2 report when customers or business partners require independent assurance over their security controls.
Most teams make the same mistake at this point. They run SOC 2 and HIPAA as two separate compliance projects.
That means two risk assessments, two sets of policies, two evidence folders and twice the cost.
There’s a better approach. Identify what your SOC 2 program already covers, map those controls to HIPAA, and put your effort into the gaps that are specific to HIPAA.
This guide shows you how. It covers what each framework requires, where they overlap, how SOC 2 controls map to HIPAA, and what you still need to add.
What is SOC 2 vs HIPAA: Quick Overview
SOC 2 is a voluntary audit report. HIPAA is a law.
SOC 2 comes from the AICPA (American Institute of Certified Public Accountants). An independent CPA firm examines your security controls against five Trust Services Criteria:
- Security
- Availability
- Processing integrity
- Confidentiality
- Privacy
Security is the only required criterion. You receive a report you can share with customers.
A Type I report tests whether your controls are designed well on a single date. A Type II report tests whether they actually worked over a review period, usually 3 to 12 months.
HIPAA protects protected health information (PHI), meaning any health information linked to an identifiable person. It applies to covered entities (healthcare providers, health plans and clearinghouses) and to their business associates (BA).
A business associate is any vendor that creates, receives, stores or sends PHI on a covered entity’s behalf. SaaS platforms, cloud hosts, billing services and AI tools that process patient data all qualify, and each carries direct legal liability.
The HHS Office for Civil Rights (OCR) enforces HIPAA. No official HIPAA certification exists.
The two frameworks have different legal status, but they share far more of the actual work than that suggests. You can see this as soon as you compare what each one asks you to do.
SOC 2 vs HIPAA Compliance Requirements: What Does Each Require?
SOC 2 requires you to design controls and have an auditor test them. HIPAA compliance requires specific safeguards, contracts and procedures whether or not anyone audits you. Much of the work underneath is the same.
SOC 2
Legal status
Voluntary
“Addressable” does not mean optional. You either implement the safeguard or document why an alternative gives equal protection.
SOC 2 Requirements: From Scope to Type II Report
1. Define your system scope: Describe the services, infrastructure, software, people, data and procedures under review, following the AICPA’s description criteria (DC 200). Decide how to treat subservice organizations such as your cloud host: “carve-out” leaves them out of your report, while “inclusive” brings their controls into it.
2. Choose the Trust Services Criteria: Security, covered by the common criteria CC1 to CC9, is mandatory. Add Availability (A1), Processing Integrity (PI1), Confidentiality (C1) or Privacy (P1 to P8) based on what you promise customers.
- a) your control environment and governance (CC1)
- b) internal and external communication (CC2)
- c) risk assessment (CC3)
- d) monitoring of controls (CC4)
- e) control activities and policies (CC5)
- f) logical and physical access (CC6)
- g) system operations, including incident detection and response (CC7)
- h) change management (CC8)
- i) risk mitigation, including vendor management (CC9)
4. Collect evidence that the controls operate: Keep records such as access reviews, change tickets, training logs and incident reports. CC4 requires you to monitor that your controls keep working, not just that they exist.
5 .Go through a CPA examination: An independent CPA firm examines your controls under AICPA attestation standards. For Type I, it checks design on a single date. For SOC 2 Type II, it tests samples of evidence across a review period, usually 3 to 12 months.
6. Receive and share your report: The report contains the auditor’s opinion, your management assertion, your system description and, for Type II, the tests performed and any exceptions. Customers usually receive it under the NDA.
HIPAA Requirements for Healthcare SaaS Companies
1. Determine whether HIPAA applies. Use the definitions in 45 CFR 160.103 to confirm whether you are a covered entity, a business associate or neither.
2. Identify every system that stores or sends ePHI. The current Security Rule does not require a formal asset inventory, but you can’t complete step 3 without one. The proposed Security Rule update would make an inventory mandatory.
3. Conduct risk analysis. Section 164.308(a)(1)(ii)(A) requires an accurate, thorough assessment of risks to the confidentiality, integrity and availability of ePHI. Section 164.308(a)(1)(ii)(B) then requires you to reduce those risks to a reasonable level.
4. Implement the three safeguard categories.
- a) Administrative safeguards (164.308): a named security official, workforce security, training, incident procedures and contingency planning.
- b) Physical safeguards (164.310): facility access, workstation security, and device and media controls.
- c) Technical safeguards (164.312): access control, audit controls, integrity, authentication and transmission security.
5. Sign BAAs. Sections 164.308(b), 164.314(a) and 164.504(e) require written business associate agreements with covered entities and with any subcontractor that handles PHI for you.
6. Set up Privacy Rule processes. As a business associate, you may use and disclose PHI only as your BAA allows (164.502(a)(3)). You must also limit PHI to the minimum necessary for each task (164.502(b)).
- a) Assessment (164.402): use a four-factor risk assessment to decide whether an incident is a reportable breach.
- b) Notice to the covered entity (164.410): business associates must notify within 60 days of discovery.
- c) Notice to others (164.404 to 164.408): covered entities notify affected individuals, HHS and, for large breaches, the media.
8. Keep ongoing documentation. Section 164.316 requires written policies and records of required actions. You must keep them for six years and review them as your environment changes.
Put the two lists side by side, and the duplication stands out. Both need a defined scope, risk assessment, security controls, and evidence. Running them as separate projects means doing those steps twice.
The one difference that matters most is scope. SOC 2 lets you choose what the audit covers, while HIPAA follows the PHI wherever it goes. A single program works only if your SOC 2 scope includes the systems that hold patient data.
Stuck on the crosswalk? Let’s see exactly which SOC 2 controls you already have, and which HIPAA requirements still need your attention.
Book a slot with us:
What Are the Differences and Overlaps Between HIPAA and SOC 2?
SOC 2 and HIPAA overlap in access control, risk management, monitoring, incident response, encryption and change management. They differ in purpose and legal status. HIPAA is a federal law governing healthcare information, with requirements for BAAs, rules on using and disclosing PHI, and breach notification.
SOC 2 is an independent attestation of your controls against the AICPA’s Trust Services Criteria. A SOC 2 program supports many HIPAA security requirements, but it does not replace HIPAA compliance.
Where HIPAA and SOC 2 Overlap
Both frameworks expect you to limit access to sensitive data, encrypt it, log activity, respond to incidents, assess risk regularly, vet vendors and train staff. That shared ground is where your existing SOC 2 work pays off twice.
Key Differences Between SOC 2 and HIPAA
- Purpose: SOC 2 builds customer trust. HIPAA protects patients’ rights and data under law.
- Data scope: SOC 2 covers any data you choose. HIPAA covers PHI, wherever it lives.
- Obligations beyond security: HIPAA adds contracts (BAAs), privacy rules and breach deadlines. SOC 2 has no direct equivalent for any of these.
- Proof: SOC 2 gives you a report. HIPAA gives you a legal duty you must be able to show you meet.
The overlaps are what you reuse. The differences are what you add. A control mapping shows you exactly where the line falls between the two.
SOC 2 HIPAA Mapping: How Do SOC 2 Controls Map to HIPAA Requirements?
Most SOC 2 common criteria map to a HIPAA Security Rule standard. The mapping stops where HIPAA adds healthcare-specific obligations
SOC 2 area
CC3.1–CC3.4 Risk Assessment
164.308(a)(1)(ii)
(A) Risk analysis (R); (B) Risk management (R)
Both require a documented, repeatable risk assessment
An enterprise-wide risk analysis scoped to every system that creates, receives, maintains or transmits ePHI. It must include an ePHI data-flow inventory and a risk management plan that shows how each identified risk is being reduced.
CC6.1–CC6.3 Logical access; CC6.4 Physical access
164.312(a)(1) Access control; 164.312(d) Authentication; 164.308(a)(4) Information access management; 164.310(a)–(d) Physical safeguards
Role-based access, provisioning and deprovisioning, user verification, facility controls
Unique user IDs (R), a documented emergency access procedure (R), automatic logoff (A), and device and media disposal and re-use controls (164.310(d)). Role-based access must also align with the Privacy Rule’s minimum necessary standard (164.502(b)).
CC7.2–CC7.5 System Operations
164.308(a)(6) Security incident procedures (R)
164.312(b) Audit controls (R)
164.308(a)(1)(ii)(D) Information system activity review (R)
Logging, anomaly detection, incident response and recovery
Scheduled review of ePHI access logs, not only alerting. Every incident also needs a four-factor breach risk assessment under 164.402, and notification to affected individuals within 60 days of discovery under 164.404.
CC8.1 Change Management
164.308(a)(8) Evaluation (R); 164.308(a)(1)(ii)(B) Risk management
Authorized, tested and approved system changes
A periodic technical and non-technical evaluation of the whole Security Rule program. A change that affects ePHI flows or storage should trigger a risk analysis update.
CC9.2 Vendor Management
164.308(b)(1), 164.314(a) and 164.504(e) Business associate contracts
Vendor due diligence and ongoing third-party risk reviews
A signed BAA with every vendor that touches ePHI. It must include the required contract terms, flow-down BAAs with subcontractors (164.502(e)(1)(ii)), and breach reporting from the business associate to the covered entity (164.410).
CC1.4 / CC2.2 Competence and Communication
164.308(a)(5) Security awareness and training; 164.308(a)(1)(ii)(C) Sanction policy (R)
Onboarding and recurring security training
Training that covers security reminders, malware protection, log-in monitoring and password management (all A).
It must also be tied to your own HIPAA policies and backed by a written, enforced sanctions policy.
A1.2–A1.3 Availability
164.308(a)(7) Contingency plan
Backups, disaster recovery and recovery testing
A data backup plan (R), a disaster recovery plan (R) and an emergency mode operation plan (R), plus contingency testing (A) and an applications and data criticality analysis (A) that ranks which ePHI systems get restored first.
CC6.1 / CC6.7 / C1.1 Encryption and Confidentiality
164.312(a)(2)(iv) Encryption and decryption (A); 164.312(e)(1) Transmission security
Encryption at rest and in transit
For each ePHI system, a documented decision (164.306(d)(3)): either encrypt, or record why encryption is not reasonable and appropriate and what equivalent control is in place. Data encrypted to HHS guidance also qualifies for breach safe harbor.
Notes:
(R) Required: HIPAA says you must do this. (A) Addressable: you must either do this, do something equally effective, or write down why it doesn’t apply to you. It is not optional.
CC, A1 and C1 are SOC 2 criteria codes. CC covers security, A1 covers availability, and C1 covers confidentiality.
The “where they overlap” column lists controls that SOC 2 and HIPAA share, so you build each one once and reuse the same evidence for both frameworks. The “what HIPAA still requires” column lists what SOC 2 doesn’t cover, and that’s where your HIPAA work should go.
One caution from our audit: a SOC 2 control only counts toward HIPAA if it covers the systems that hold ePHI. We’ve seen well-run access reviews that proved nothing for HIPAA because they covered the wrong systems. Before you count any control toward HIPAA, check that the systems in your SOC 2 report match the systems that store or process ePHI.
Already Have SOC 2? What Do You Still Need for HIPAA?
If you already have a SOC 2, you don’t need to start over. You need the HIPAA-specific pieces SOC 2 never produces, an ePHI risk analysis, BAAs, breach procedures, Privacy Rule processes and HIPAA documentation.
In one recent SOC 2 engagement, the two most significant gaps we found were an information classification policy that didn’t govern how sensitive data was communicated, and breach detection that relied on manual review with no SIEM. Both passed as “reasonable” in early SOC 2 readiness discussions. Under HIPAA, both would be serious exposures, because you can’t meet a notification deadline for a breach you can’t reliably detect.
SOC 2 to HIPAA Gap Checklist
- HIPAA applicability and business associate status: Write down whether HIPAA applies to you and in what role.
- ePHI inventory and data flows: Map every database, backup, log, integration and AI tool that touches patient data. Then check that your SOC 2 scope covers all of them.
- HIPAA Security Rule risk analysis: Extend your SOC 2 risk assessment to cover threats to ePHI specifically.
- HIPAA-specific policies and procedures: Add a sanctions policy, minimum necessary access rules, device and media disposal, and a named security official to the policy set you already have.
- BAAs and subcontractor relationships: Sign BAAs with customers, and with every vendor that touches PHI on your behalf, including cloud, email and AI model providers.
- Privacy Rule obligations: Use and disclose PHI only as your BAAs allow, and support patient access requests when customers need them.
- Breach assessment and notification procedures: Build on your SOC 2 incident response plan. Add a documented way to decide whether an incident is a reportable breach. As a business associate, you must notify your covered entity without unreasonable delay, and no later than 60 days after discovery. Many BAAs set a shorter deadline
- HIPAA documentation: Keep policies, risk analysis, and decisions for six years.
- Technical validation of controls: Test your safeguards with vulnerability scans and penetration testing, not just written policy.
Most items on this list extend something your SOC 2 program already has. Only BAAs and Privacy Rule processes start from zero.
If you’re building both frameworks from scratch, the same approach applies. You just set it up that way from day one.
How to Become HIPAA and SOC 2 Compliant Without Duplicating the Work
- 1. Determine HIPAA applicability. Confirm whether you are a covered entity, a business associate or neither.
- 2. Map your ePHI. List every system and data flow that touches patient data.
- 3. Define your SOC 2 scope. Make sure it includes every ePHI system from step 2.
- 4.Perform one risk assessment. Design it to meet SOC 2's CC3 criterion and HIPAA's risk analysis requirement at the same time.
- 5. Build the crosswalk. Map each control to both frameworks using the table above.
- 6. Implement common controls. Access, encryption, logging, incident response, training and vendor management.
- 7. Close HIPAA-only gaps. BAAs, breach procedures, Privacy Rule processes and documentation.
- 8. Collect common evidence. Gather each piece of evidence once and tag it to both frameworks.
- 9. Go through the SOC 2 examination. Ask your CPA firm whether a SOC 2+ report can include HIPAA Security Rule criteria.
- 10. Test both frameworks continuously. Run regular vulnerability scans, penetration tests and access reviews. HHS's proposed Security Rule update would make these mandatory.
At KLEAP, we take a manual-first approach to compliance readiness. What we do is make sure you walk into that audit ready. We run manual gap assessments against SOC 2 and the HIPAA Security Rule, help implement controls and draft policies, conduct pre-certification internal audits, and help close any gaps we find.
Because we’re also a penetration testing firm, the controls we help you build get tested the way an attacker would test them. That covers your web and mobile apps, APIs, cloud, and the LLM and AI systems that increasingly touch patient data.
Talk to Your Concierge about a combined SOC 2 and HIPAA readiness assessment.
Frequently Asked Question
What are the differences and overlaps between SOC 2 and HIPAA?
HIPAA and SOC 2 overlap in areas such as access control, risk management, security monitoring, incident response, encryption, and vendor risk management. The main difference is that HIPAA is a federal law governing the protection and permitted use of protected health information (PHI), while SOC 2 is an independent attestation against the AICPA Trust Services Criteria. SOC 2 controls can support HIPAA compliance, but a SOC 2 report does not establish HIPAA compliance.
Does SOC 2 cover HIPAA compliance?
No. SOC 2 can cover controls that also support HIPAA requirements, but a SOC 2 report does not establish HIPAA compliance. SOC 2 may provide evidence for areas such as access control, risk management, monitoring and incident response. HIPAA adds requirements including PHI-specific risk analysis, BAAs, Privacy Rule processes, breach procedures and documentation.
How to deal with SOC 2 and HIPAA at the same time?
Manage SOC 2 and HIPAA through one control program rather than two separate compliance projects. Map the overlapping requirements, implement shared controls once, collect evidence once, and separately address HIPAA-specific requirements such as BAAs and applicable Privacy and Breach Notification Rule obligations. This reduces duplicated compliance work without assuming that a SOC 2 control automatically satisfies HIPAA.
SOC 2 or HIPAA, which does a digital health startup actually need?
It depends on what the startup does and the data it handles. HIPAA applies when the startup qualifies as a covered entity or business associate; simply being a digital health company does not automatically make it subject to HIPAA. SOC 2 is separate and may be pursued to provide customers with independent assurance over security controls. A digital health startup that is subject to HIPAA and also needs SOC 2 assurance for customers may therefore need to address both.
If we already have SOC 2 Type II, what should we do before pursuing HIPAA compliance?
Start with a HIPAA-specific gap assessment rather than rebuilding your security program. Determine whether HIPAA applies, map where ePHI is created, received, maintained or transmitted, conduct the required HIPAA risk analysis, and map your existing SOC 2 controls against the applicable HIPAA requirements. HHS specifically expects risk analysis to consider the systems and applications that access or house ePHI. From there, identify what your SOC 2 program does not address, such as required BAAs and other HIPAA-specific processes and documentation.
