Back to HIPAA

HIPAA vs SOC 2: Differences, Overlap, and Which You Need

HIPAA vs SOC 2: Differences, Overlap, and Which You Need Photo: Unsplash

If you sell software to hospitals, clinics, payers, or digital health companies, two compliance questions arrive early in almost every deal: "Are you HIPAA compliant?" and "Can we see your SOC 2 report?" They sound similar, and the controls behind them overlap heavily, but they are different things with different consequences. This guide explains how HIPAA and SOC 2 differ, where they overlap, what SOC 2 does not cover for HIPAA, and how HealthTech teams can run both without doing the work twice.

Key takeaways

  • HIPAA is a law. SOC 2 is an audit report. HIPAA applies to you automatically if you handle protected health information (PHI) for a covered entity. SOC 2 is a voluntary attestation you choose to get because customers ask for it.
  • There is no official HIPAA certification. HHS does not certify anyone. You show HIPAA compliance through evidence: a risk analysis, policies, training records, business associate agreements, and often an independent report such as SOC 2.
  • The two overlap by a large margin. Access control, risk assessment, logging, incident response, vendor management, and encryption appear in both. One well-designed control set can satisfy most of each.
  • SOC 2 alone does not make you HIPAA compliant. Business associate agreements, breach notification to HHS, Privacy Rule obligations, and six-year documentation retention sit outside a standard SOC 2 scope.
  • Most HealthTech vendors end up needing both. HIPAA because the law requires it, SOC 2 because enterprise and health system buyers use it to verify your security program.

HIPAA and SOC 2 at a glance

HIPAA SOC 2
What it is US federal law (1996) with implementing rules from HHS Attestation report under AICPA standards
Who it applies to Covered entities and their business associates that handle PHI Any service organization that chooses to be audited
Mandatory? Yes, if you create, receive, maintain, or transmit PHI for a covered entity No, it is market driven
Who checks it HHS Office for Civil Rights (OCR) investigates complaints and breaches; state attorneys general can also enforce An independent licensed CPA firm
What you get No certificate. You hold documentation and evidence A SOC 2 Type 1 or Type 2 report you can share under NDA
Scope Protected health information, in any form The systems and Trust Services Criteria you choose to include
Consequence of failure Civil and criminal penalties, corrective action plans, breach notification duties A qualified opinion or exceptions in your report, and lost deals

What HIPAA requires from a software vendor

When your product stores or processes PHI on behalf of a hospital, clinic, health plan, or another covered entity, you are a business associate. That brings three sets of obligations.

The Security Rule. This is where most of an engineering team's work sits. It requires administrative, physical, and technical safeguards for electronic PHI (ePHI):

  • Administrative safeguards: a documented risk analysis and risk management plan, a designated security official, workforce training, a sanctions policy, access management procedures, incident response, contingency planning, and periodic evaluation.
  • Physical safeguards: facility access controls, workstation security, and device and media controls, much of which your cloud provider covers for its data centers.
  • Technical safeguards: unique user IDs, emergency access procedures, automatic logoff, audit controls, integrity controls, authentication, and transmission security.

Each specification is either "required" or "addressable". Addressable does not mean optional. You either implement it or document why an equivalent measure is reasonable for your environment.

The Breach Notification Rule. If unsecured PHI is breached, you must notify the covered entity without unreasonable delay and within 60 days of discovery. The covered entity then notifies affected individuals, HHS, and in larger breaches the media. Your BAA often sets a shorter deadline, so read it.

The Privacy Rule, as it applies to business associates. You can only use and disclose PHI as your business associate agreement permits, must apply the "minimum necessary" standard, and must support the covered entity when patients exercise their rights, such as access to their records.

On top of these, you need a business associate agreement (BAA) with each covered entity you serve and with each subcontractor that touches PHI, such as your cloud host, email provider, or support tooling. Our guide to HIPAA business associate agreements covers what they must contain.

One change to watch: in January 2025 HHS proposed a major update to the Security Rule that would remove most of the required versus addressable distinction and make measures such as encryption and multi-factor authentication explicit requirements. Check the current status before you finalize your program, and design for the stricter version where you can. It is where buyers are already heading.

What a SOC 2 audit covers

SOC 2 is an examination performed by a licensed CPA firm against the AICPA's Trust Services Criteria:

  • Security (required in every SOC 2): the Common Criteria covering control environment, risk assessment, monitoring, logical and physical access, system operations, change management, and vendor risk.
  • Availability, Processing Integrity, Confidentiality, and Privacy: optional categories you add when they matter to your customers.

A Type 1 report tests whether controls are designed properly at a single point in time. A Type 2 report tests whether they operated effectively over a period, usually 3 to 12 months. Health systems and larger buyers almost always want Type 2. See SOC 2 Type 1 vs Type 2 for how to choose.

Unlike HIPAA, SOC 2 produces something you can hand over: a report with the auditor's opinion, a description of your system, and the test results for each control.

Where HIPAA and SOC 2 overlap

Most HIPAA Security Rule safeguards have a direct counterpart in the SOC 2 Security criteria. That is why teams that build the controls once can use them for both.

HIPAA Security Rule safeguard Where it shows up in SOC 2
Risk analysis and risk management CC3 risk assessment criteria
Security official and workforce training CC1 control environment and CC2 communication
Access management, unique user IDs, authentication CC6 logical access controls
Audit controls and activity review CC7 system monitoring
Security incident procedures CC7 incident detection, response, and recovery
Contingency plan, backups, disaster recovery Availability criteria and CC7 recovery
Evaluation of safeguards CC4 monitoring activities
Business associate contracts with subcontractors CC9 vendor and business partner risk
Transmission security and encryption CC6 data protection controls
Device and media controls CC6 physical and asset controls

In practice this means one access review, one incident response plan, one vendor register, one set of logging and monitoring controls, and one training program can produce evidence for both.

What SOC 2 does not cover for HIPAA

A clean SOC 2 report is strong evidence, but a standard SOC 2 scope leaves these HIPAA obligations uncovered:

  • Business associate agreements. SOC 2 checks that you manage vendor risk. It does not check that a compliant BAA is signed with every party that touches PHI.
  • Breach notification. SOC 2 checks that you respond to incidents. HIPAA sets specific rules for deciding whether an incident is a reportable breach and who must be told, and when.
  • Privacy Rule duties. Minimum necessary use, permitted disclosures, and supporting patient rights requests are outside the Security criteria. The optional Privacy category helps but is not mapped to HIPAA by default.
  • A HIPAA-specific risk analysis. SOC 2 requires a risk assessment, but HIPAA expects an accurate and thorough analysis focused on where ePHI lives and what threatens it. Missing or outdated risk analyses are a recurring finding in OCR enforcement.
  • Documentation retention. HIPAA requires you to keep policies and related documentation for six years.
  • Scope. If the system that processes PHI is outside your SOC 2 boundary, the report says nothing about it.

If buyers want one document that addresses HIPAA directly, ask your auditor about a SOC 2+ report. It adds HIPAA Security Rule requirements as additional subject matter, so the same examination reports on both.

Do you need HIPAA, SOC 2, or both?

  • You handle PHI for covered entities: HIPAA compliance is not optional. Start there.
  • You sell to health systems, payers, or enterprise buyers: expect them to ask for SOC 2 Type 2 as proof of your security program, in addition to your HIPAA documentation and a signed BAA.
  • You are a digital health startup selling directly to consumers, with no covered entity involved: HIPAA may not apply, but state health privacy laws and the FTC Health Breach Notification Rule might. SOC 2 is still what B2B partners will ask for.
  • Your buyers are large health systems: some will ask for HITRUST instead of, or in addition to, SOC 2. See HITRUST vs SOC 2 before you commit.

For most B2B HealthTech companies, the answer is both, built on one control set.

How to run HIPAA and SOC 2 together

  1. Map where PHI flows. Trace how PHI enters, moves through, and leaves your product, including databases, logs, backups, analytics, and vendors. That map sets the scope for both frameworks.
  2. Do the HIPAA risk analysis first. It is required by law, and it doubles as the risk assessment SOC 2 expects. Use our HIPAA risk assessment checklist as a starting point.
  3. Build one control set mapped to both. Write each control once, then map it to the HIPAA safeguard and SOC 2 criterion it satisfies.
  4. Close the HIPAA-only gaps. Put BAAs in place, write breach assessment and notification procedures, and set six-year retention for documentation.
  5. Collect evidence continuously. Access reviews, training completion, device checks, and configuration settings should be captured as they happen, not rebuilt before an audit.
  6. Choose your SOC 2 scope carefully. Make sure every system that processes PHI is inside the boundary, and consider adding Confidentiality or Privacy if buyers ask.
  7. Book your SOC 2 Type 2 audit. Once controls have operated for your observation window, the auditor tests them. See how much a SOC 2 audit costs to budget for it.
  8. Keep both current. Revisit the risk analysis when systems change and at least annually, and renew SOC 2 each year.

How SecureSlate helps

SecureSlate runs HIPAA and SOC 2 as one program for HealthTech teams, for one fixed price:

  • A dedicated compliance lead maps your PHI, runs the risk analysis, drafts policies, and manages business associate agreements, so your engineers approve instead of interpreting the regulation.
  • One control set mapped to both frameworks. Evidence is collected once and satisfies HIPAA safeguards and SOC 2 criteria together. See multi-framework compliance.
  • Continuous evidence from your cloud provider, identity provider, code host, and devices, covering access, logging, and encryption settings.
  • An audit partner network for your SOC 2 examination, or bring your own firm.

If you are building a healthcare product, see SecureSlate for healthcare.

FAQ

Is SOC 2 the same as HIPAA compliance?

No. HIPAA is a federal law that applies to organizations handling protected health information, while SOC 2 is a voluntary audit report on your security controls. A SOC 2 report is useful evidence for HIPAA, but it does not cover business associate agreements, breach notification, or Privacy Rule duties.

Can I get HIPAA certified?

No. HHS does not certify organizations, and no official HIPAA certification exists. Third-party "HIPAA certificates" only show that someone assessed you. Buyers judge your HIPAA program on its evidence, such as your risk analysis, policies, training records, and signed BAAs.

Does SOC 2 cover HIPAA requirements?

It covers most of the HIPAA Security Rule safeguards, because the controls overlap. It does not cover HIPAA-specific obligations such as BAAs, breach notification rules, and six-year documentation retention. A SOC 2+ report can add HIPAA requirements to the same audit.

Which should a HealthTech startup do first, HIPAA or SOC 2?

Start with HIPAA if you handle PHI, because it is a legal requirement from the first patient record. Build the controls so they also map to SOC 2, then schedule a SOC 2 audit when buyers start asking for a report.

Do I need a BAA if I have a SOC 2 report?

Yes. A BAA is a legal requirement between a covered entity and a business associate, and between a business associate and its subcontractors. A SOC 2 report does not replace it.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. Requirements vary by framework, industry, and jurisdiction. Consult qualified advisors for your specific obligations.

Need compliance without the complexity?

SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.

Find compliance gaps in 30 seconds

Filed under:

Author: SecureSlate Team

4.8(219 reviews)

Keep reading

Sep 29, 2026 · HIPAA

After SOC 2: The Compliance Roadmap for HealthTech Companies

Jul 19, 2026 · HIPAA

AWS Control Tower and HIPAA: how to govern multi-account ePHI workloads

Jul 19, 2026 · SOC 2

SOC 2 Evidence for Change Management: What Auditors Expect from Agile Teams

View more posts
Jamie
Virtual Agent

Hi! I'm Jamie. Curious about your current compliance challenges and how automation might help your team?