SOC 2 for Healthcare SaaS: Does a SOC 2 Report Cover HIPAA?

No. A SOC 2 report does not cover HIPAA, and holding one does not make a healthcare SaaS company HIPAA compliant. SOC 2 is a voluntary attestation that a CPA firm issues against the AICPA Trust Services Criteria. HIPAA is federal law, enforced by the Office for Civil Rights (OCR) at the Department of Health and Human Services.

The question comes up because the two share a lot of security controls. A hospital's procurement team sees a SOC 2 Type 2 report and assumes the vendor has HIPAA handled. The vendor often assumes the same thing.

If your product stores or processes protected health information (PHI) for a provider, clinic or health plan, you are a business associate under HIPAA. That status carries legal duties a standard SOC 2 examination never tests. This guide covers what a SOC 2 report gives a healthcare SaaS company, what it leaves out and how to meet both with one set of controls.

SOC 2 vs HIPAA at a glance

SOC 2 is a report your customers ask for. HIPAA is a law you answer to. The table shows how that difference plays out.

One row deserves a second look. HHS does not issue or recognize a HIPAA certification, so any "HIPAA certified" badge comes from a private company. A buyer who knows this will ask for evidence instead.

SOC 2 and HIPAA: where they overlap

Most of the overlap sits in the HIPAA Security Rule. The rule groups its requirements into administrative, physical and technical safeguards, and nearly every group has a counterpart in the SOC 2 Security criteria.

A healthcare SaaS company that runs SOC 2 with its PHI systems in scope already holds much of what OCR would ask for under the Security Rule. The same access review that satisfies your auditor also answers a hospital's security questionnaire.

What HIPAA requires that a SOC 2 report leaves out

A SOC 2 auditor tests the controls in your system description against the criteria you selected. HIPAA asks for several things that fall outside that test.

• Business associate agreements. You need a signed BAA with every covered entity you serve and with each subcontractor that touches PHI, including your cloud host and support tools. SOC 2 looks at vendor management in general. It does not check that a BAA exists or that it contains the terms HIPAA requires.

• Limits on using and disclosing PHI. A business associate may use PHI only as the BAA allows and must keep access to the minimum necessary. The SOC 2 Privacy criteria are optional and are written around your own privacy commitments, which may say nothing about HIPAA.

• Breach notification. After discovering a breach of unsecured PHI, a business associate must notify the covered entity without unreasonable delay and within 60 days at the latest. Many BAAs shorten that window to a few days. SOC 2 confirms you have an incident process. It does not test the HIPAA clock or the breach risk assessment.

• A risk analysis that covers all ePHI. OCR expects an accurate and thorough analysis of risks to every system holding electronic PHI. A SOC 2 risk assessment only has to cover the system in the report.

• Scope you did not include. SOC 2 scope is your choice. If the product that handles PHI sits outside the system boundary, the report says nothing about it.

• Six-year documentation. HIPAA policies, procedures and records of required actions must be kept for six years. A Type 2 report usually covers 6 to 12 months.

The Security Rule update is still pending

In January 2025, HHS proposed a rewrite of the Security Rule that would make encryption, multifactor authentication, network segmentation and annual penetration testing explicit requirements. The proposal is not final. The federal regulatory agenda now shows July 2027 as the target for final action, so the current rule still applies.

The proposal would also require business associates to verify their technical safeguards to the covered entities they work for. Healthcare SaaS vendors should expect customers to ask for that evidence before any rule forces them to.

SOC 2+ HIPAA: one examination for both

A SOC 2+ report is a SOC 2 examination with additional subject matter added to it. For healthcare SaaS, the addition is usually the HIPAA Security Rule, and sometimes the Breach Notification Rule as well. The CPA firm tests your controls against the Trust Services Criteria and the HIPAA requirements in the same engagement, and the report includes a mapping between the two.

Controls that satisfy both are tested once. Your team answers one set of evidence requests and your customer reads one document.

A SOC 2+ report has limits you should explain to your sales team before they overstate it:

• It is an auditor's opinion. OCR does not treat it as proof of compliance.

• It covers the system and period in the report, the same as any SOC 2.

• It usually addresses the Security Rule. Privacy Rule duties under your BAAs still need their own policies and records.

A SOC 2+ makes sense when customers keep sending you a SOC 2 request and a separate HIPAA security questionnaire. Some large health systems ask for HITRUST instead, so check what your top prospects require before choosing.

SOC 2 for healthcare SaaS: what buyers ask for

No law requires SOC 2 for healthcare companies. Buyers require it. A provider or health plan evaluating a SaaS vendor that will hold PHI typically asks for the following before signing:

• A signed BAA, often on the buyer's own template

• A current SOC 2 Type 2 report with the PHI systems inside the scope

• A summary of your most recent HIPAA risk analysis

• A recent penetration test summary with remediation status

• A completed security questionnaire

• A list of subprocessors that handle PHI, with confirmation that BAAs are in place

The SOC 2 report answers a large part of the questionnaire and shortens the security review. The BAA and the risk analysis are what make the deal legal. A vendor with only the report gets stuck at contract stage, and a vendor with only the BAA gets stuck in security review.

How to cover SOC 2 and HIPAA with one program

Running the two as separate projects means writing the same policies twice and collecting the same evidence twice. These steps build one control set that serves both.

1. Map where PHI lives. List every application, database, backup, log store and vendor that creates, receives, stores or transmits PHI.

2. Put those systems inside the SOC 2 boundary. A report that excludes your PHI environment will not satisfy a healthcare buyer.

3. Choose criteria that match your commitments. Security is required. Healthcare SaaS companies commonly add Availability and Confidentiality, and add Privacy when customers ask for it.

4. Build one control matrix with a HIPAA column. For each control, record the Trust Services Criteria it meets, the Security Rule citation it meets, the owner and the evidence.

5. Close the HIPAA-only gaps. Sign BAAs upstream and downstream, write a breach notification procedure with the 60-day limit and your contract deadlines, document permitted uses of PHI and set six-year retention.

6. Decide between SOC 2 and SOC 2+ with your CPA firm. Make the call before the review period starts, because it changes what the auditor tests.

7. Collect evidence once. Tag each item to both frameworks so the same access review or backup test answers the auditor and the customer questionnaire.

Digisecuritas handles the readiness side of this work: scoping, control mapping, gap remediation and evidence review. An independent CPA firm then performs the examination and issues the report.

Get SOC 2 and HIPAA mapped in one pass

If your product handles PHI and a customer has asked for a SOC 2 report, start with the scope. Digisecuritas will map your SOC 2 controls to the HIPAA Security Rule, list the gaps and give you a plan for a Type 1 or Type 2 examination.

Schedule a SOC 2 readiness assessment