SOC 2 vs HIPAA Key Differences and Overlaps

SOC 2 vs HIPAA is often framed as a choice between two security frameworks. It is not a choice. HIPAA is a United States federal law that applies the moment an organisation creates, receives, maintains or transmits protected health information. SOC 2 is a voluntary attestation that a service organisation commissions to show its customers how it protects their data.

That difference in legal nature shapes everything else: who is obliged, who assesses the work, what evidence exists at the end and what happens when something fails. Teams that treat the two frameworks as interchangeable spend months building the wrong thing and assume an obligation is settled when a clean report never touched it.

We work with technology companies that handle health data in Europe and the United States, and the same confusion appears in almost every project. This guide explains what each framework requires, where they overlap, where they diverge and how to approach them together without doing the work twice.

HIPAA is law, SOC 2 is evidence

The clearest way to separate SOC 2 vs HIPAA is to ask what each one is.

HIPAA is legislation. The Health Insurance Portability and Accountability Act dates from 1996, and the obligations that affect most software companies today come from three later rules:

• The Privacy Rule, which governs how protected health information (PHI) may be used and disclosed.
• The Security Rule, which sets administrative, physical and technical safeguards for electronic PHI (ePHI).
• The Breach Notification Rule, which defines what happens after a breach of unsecured PHI.

SOC 2 is an attestation engagement. A licensed CPA firm examines a service organisation’s controls against the AICPA Trust Services Criteria (TSC) and issues a report. There is no regulator behind it and no legal obligation to obtain one. A SOC 2 report exists because customers, usually enterprise buyers, ask for independent evidence before they sign.

One is an obligation you already have. The other is a document you decide to produce. Everything that follows stems from that.

What HIPAA actually requires

HIPAA applies to covered entities (healthcare providers, health plans and healthcare clearinghouses) and to their business associates, a category that includes most technology vendors that handle PHI on someone else’s behalf.

The Security Rule, published by the US Department of Health and Human Services, is the part that most resembles a security programme. It requires administrative, physical and technical safeguards for ePHI, and several features surprise teams coming from a purely technical background.

Risk analysis comes first. A documented, up-to-date assessment of the risks to ePHI underpins every safeguard decision. Without it, the rest of the programme has nothing to refer back to.

Contracts are a control. A covered entity must have a signed business associate agreement (BAA) with every vendor that handles PHI, and business associates must flow the same terms down to their subcontractors. A BAA is not a formality. It is the mechanism that extends the legal obligation along the supply chain.

The breach clock is fixed. Under the Breach Notification Rule, the covered entity must notify individuals without unreasonable delay and no later than 60 days after discovery, and a business associate must notify the covered entity within the same maximum period. Breaches affecting 500 or more people are also reported to the Secretary within that timeframe. These deadlines are not risk-weighted and they are not negotiable.

In many technology companies, these safeguards overlap with a broader data privacy and security programme that already exists for other regulations, and that is where the efficiency begins.

There is no HIPAA certificate. Compliance is an ongoing legal state, evidenced by the risk analysis, the safeguards, the contracts and the records that support them.

What a SOC 2 report actually shows

A SOC 2 examination tests controls against the AICPA Trust Services Criteria. The Security category, also known as the common criteria, is always included. Availability, Processing Integrity, Confidentiality and Privacy are optional, and the organisation chooses which to add based on what it promises its customers.

The output is a report, not a badge. It describes the system in scope, lists the controls the organisation stated, records what the auditor tested and issues an opinion. A Type 1 report covers the design of the controls at a specific date. A Type 2 report covers operating effectiveness over a period. Enterprise buyers almost always want Type 2.

Two features matter especially when comparing it with HIPAA. First, the organisation chooses the scope and agrees it with the auditor, so a SOC 2 can be narrow or broad depending on where the boundary is drawn. Second, the report is tested by an independent firm and shared under NDA, which is why it carries weight in a procurement process.

SOC 2 vs HIPAA: how they differ

Strip away the detail and the differences fall into a few categories.

Aspect	HIPAA	SOC 2
Legal nature	Federal law	Voluntary attestation
Governing body	US Department of Health and Human Services	AICPA
Who it applies to	Covered entities and business associates that handle PHI	Any service organisation whose customers ask for it
Data in scope	Protected health information	Whatever the organisation defines for the systems in scope
Who sets the scope	The law, for every system that handles PHI	The organisation and its auditor
Who assesses	No mandatory assessment; OCR investigates after complaints or breaches and conducts compliance audits	An independent CPA firm that the organisation hires and pays
Output	No artefact; compliance is a legal state	A report with the auditor’s opinion
Certification	Does not exist	Does not exist; SOC 2 is an attestation
Timing	Ongoing from the moment PHI is handled	Type 1 at a point in time; Type 2 over a period
What failure looks like	Investigation, corrective action plan, civil penalties, state action	Exceptions or a qualified opinion that buyers read

The table is useful for orientation, but the practical decision rarely depends on the rows. It depends on the overlap and the gaps.

Where SOC 2 and HIPAA overlap

The overlap is larger than people tend to think, and that is where the efficiency lies. Access control, joiner and leaver processes, awareness training, encryption in transit and at rest, logging and monitoring, incident response, vendor risk management and a documented risk assessment all serve both frameworks.

They are built once and evidenced once. A company that already runs an ISO 27001 management system will recognise almost the entire list, because the underlying controls belong to the same family.

The overlap is the reason a single programme can produce evidence for SOC 2, HIPAA and ISO 27001 at the same time, keeping each framework’s specific obligations visible instead of duplicating them.

Where HIPAA goes further than SOC 2

The gaps are narrower than feared, but sharper than expected. A standard SOC 2 examination, especially one limited to the Security criteria, will not test several things HIPAA requires:

• Business associate agreements and contractual flow-down to subcontractors.
• The breach notification mechanics against the 60-day deadline.
• The minimum necessary standard for using and disclosing PHI.
• Notices of privacy practices, for covered entities, and individual rights, including access, amendment and accounting of disclosures.
• HIPAA-specific contingency planning, such as emergency mode operation and data criticality analysis.
• Six-year retention of required documentation.

None of this means SOC 2 is weak. It means SOC 2 was designed to answer a different question. A report that satisfies customers on security is not the same as a legal programme that satisfies a regulator on PHI.

Where SOC 2 goes further than HIPAA

Traffic also flows the other way. SOC 2 asks for disciplines that HIPAA never sets out in the same detail:

• Change management with approvals, testing and rollback.
• Availability commitments and service expectations, when that criterion is in scope.
• Continuous monitoring and evidence that controls operated throughout a period, not just on the day of the review.
• A scope statement and system description that a buyer can read and verify.

For a company selling to enterprise healthcare customers, this is the part that closes deals. HIPAA may be the legal floor, but the SOC 2 Type 2 report is usually the artefact the security review actually asks for.

SOC 2, HIPAA and the European perspective

Most guides on SOC 2 vs HIPAA are written for a US audience and stop at the two frameworks. For European technology companies, the picture has an extra layer that is easy to miss.

A company headquartered in the European Union that handles health data for a US client can fall within the scope of HIPAA as a business associate, even without a US entity. At the same time, its processing in Europe is governed by the GDPR, with its own rules on lawful basis, data subject rights and international transfers.

The two regimes are not identical. The GDPR and HIPAA share concepts such as access control, minimisation and breach management, but they differ in definitions, deadlines and individual rights. Moving health data between the two jurisdictions also raises transfer questions that a domestic HIPAA programme never has to solve, and it makes privacy risks in SaaS harder to see, because the data is often spread across several third-party tools.

For these companies, the practical solution is a single control framework with three visible layers: the shared security controls, the HIPAA-specific obligations such as BAAs and the breach clock, and the GDPR-specific obligations such as lawful basis and international transfer safeguards. A company that already treats ISO 27001 vs SOC 2 as one decision rather than two is already thinking in the right shape.

SOC 2+ and the single-engagement route

If a company needs both, there is a route that avoids two disconnected projects: a SOC 2 examination with additional subject matter, usually called SOC 2+.

In a SOC 2+, the auditor maps the organisation’s existing controls against the safeguard standards of the HIPAA Security Rule, tests them alongside the Trust Services Criteria and then reports the results in a single document. It is not a HIPAA certification, because none exists, but it is usually the closest thing to a single answer when a buyer asks about both frameworks.

A SOC 2+ focused on the Security Rule does not cover the Privacy Rule or the Breach Notification Rule unless they are expressly added to the scope. Whatever falls outside remains a legal obligation the organisation must evidence through its own records and contracts.

How PrivaLex turns SOC 2 vs HIPAA into a single programme

When both frameworks apply, the hard part is rarely the controls. The hard part is deciding what a SOC 2 should cover, which HIPAA obligations fall outside that scope and how to evidence both without running two programmes.

PrivaLex is a compliance consultancy for technology companies, digital platforms and other data-driven organisations. We handle privacy, information security, certification and regulatory affairs as a single operating model, not as disconnected projects.

For companies that need HIPAA compliance support alongside a SOC 2, we usually start with scoping and a gap assessment. We map the systems, data flows, vendors and customer commitments that determine whether HIPAA applies and what a SOC 2 should cover, and then compare current controls against both frameworks.

From there we help build the shared control layer once and add the differentiating requirements on top. That means the risk analysis, policies, control owners, evidence logs, training, business associate agreements, vendor reviews and incident procedures are structured to serve several frameworks at once.

When a company operates across the United States and Europe, we keep HIPAA, GDPR and ISO 27001 obligations visible within a single programme. Shared controls reduce duplicated work, while each framework’s specific obligations remain documented and traceable for an auditor or a regulator.

The goal is a programme that a team can run day to day, explain to a customer and demonstrate to an assessor, not a folder of documents assembled for a single audit.

Which should you tackle first?

For anyone handling PHI, the sequencing question almost answers itself. HIPAA first, because it is already in force and cannot wait for a commercial reason. Then let sales drive the SOC 2.

A sensible order would be:

1. Confirm your status and document the reasoning

Determine whether you are a covered entity, a business associate or neither. Put the analysis in writing, because it shapes everything else.

2. Carry out the HIPAA risk analysis

Assess the risks to ePHI, record the method and findings and fix whatever the analysis brings to light.

3. Put policies, BAAs and training in place

Policies alone are not enough if the contracts are missing or staff have not been trained.

4. Choose the Trust Services Criteria

Base the choice on what you contractually promise your customers, not on the longest list available.

5. Run a readiness assessment

By this stage, most gaps are evidence gaps, not control gaps. Fix the evidence trail before the audit period begins.

6. Choose Type 1 or Type 2

A Type 1 can unlock a deal quickly. Type 2 is what enterprise buyers end up wanting, so start the observation period as soon as the controls are stable.

Evidence that serves both SOC 2 and HIPAA

The overlap becomes concrete in the evidence itself. When an auditor or a customer asks for proof, the same document usually answers for both frameworks, with a smaller set that belongs to HIPAA alone.

Evidence	What it shows	Framework
Risk analysis	Threats, impacts and treatment decisions	Both
Access control policy and access reviews	Least privilege and periodic recertification	Both
Awareness training records	Staff are trained and have acknowledged it	Both
Encryption standards in transit and at rest	Data protection controls in operation	Both
Logging and monitoring records	Activity capture and anomaly detection	Both
Incident response and breach log	Detection, response and notification handling	Both, with the HIPAA breach clock
Vendor and subprocessor reviews	Vendor risk and due diligence	Both
Change management records	Approvals, testing and rollback	SOC 2
Business associate agreements	Contractual flow-down for PHI	HIPAA only
Contingency and recovery plan	Recovery of systems that handle PHI	HIPAA, with availability in SOC 2 scope
Notice of privacy practices and rights log	Transparency and individual rights	HIPAA only
Six-year documentation retention	Records kept for the required period	HIPAA only

The practical rule is to tag each artefact once and reference it in both programmes. The items marked HIPAA only are the ones teams forget, because they sit outside the security archive. They need a named owner and their own review cycle.

Conclusion

SOC 2 and HIPAA are not alternatives. HIPAA is the legal floor that applies from the first time you handle protected health information, and SOC 2 is the report that lets your customers verify the controls behind it.

The efficient route is to treat them as a single programme: build the shared controls once, keep HIPAA-specific obligations such as business associate agreements and breach notification visible, and add the SOC 2 criteria your buyers ask for. Teams that do this save time and avoid maintaining two versions of the same policy.

Frequently Asked Questions (FAQs)