If we have SOC 2 Type 2, do we still need a HIPAA risk assessment?

Almost certainly yes. HIPAA's Security Rule contains a specific, named requirement for a risk analysis covering the confidentiality, integrity, and availability of electronic protected health information — it is an obligation on your organization, not a control an auditor performs on your behalf. A SOC 2 Type 2 report is an auditor's opinion on whether the controls you defined operated effectively over a period of time; it is not itself the risk analysis HIPAA asks for, and it is not scoped to PHI unless you deliberately scoped it that way. In practice most teams can reuse a great deal of the underlying evidence — asset inventories, data flow diagrams, vendor lists, control descriptions — but they still need to produce a documented, PHI-specific risk analysis and a remediation plan flowing from it. Treat SOC 2 as a source of raw material for the risk assessment, not a replacement for it. This is a question worth confirming with counsel or a HIPAA-experienced auditor for your specific situation.

Can the same audit logging system satisfy both?

Usually yes, and this is the single largest piece of genuine reuse between the two frameworks. Both regimes want to know who accessed what, when, and what changed, and both want those records to be tamper-resistant and reviewed rather than merely collected. If you have already built append-only logging with actor, action, resource, timestamp, and outcome for SOC 2, the same pipeline generally covers HIPAA's audit controls requirement. The differences are in scope and review discipline rather than in architecture: HIPAA pushes you to make sure PHI access specifically is captured — including reads, not just writes — and to actually review those logs on a defined cadence with documented evidence that the review happened. The build is shared; the scoping decision and the review process need a second pass.

Does SOC 2 cover BAAs?

Not as a HIPAA obligation, no. SOC 2 has a vendor and subservice organization management expectation — you are supposed to know who your critical vendors are, assess their risk, and have contracts in place — so an auditor will look at your vendor agreements. But no part of SOC 2 requires the specific contractual instrument HIPAA calls a Business Associate Agreement, with the specific terms HIPAA requires it to contain. A company can hold a clean SOC 2 Type 2 report and have zero executed BAAs with the vendors processing PHI on its behalf, and that is a HIPAA gap the SOC 2 report will not surface. BAAs are a legal-document workstream, and the details of who needs one and what it must say should be reviewed with counsel.

SOC 2 vs HIPAA: what actually overlaps and what doesn't

A SOC 2 Type 2 report does not make you HIPAA compliant. Here is what genuinely overlaps between the two, what HIPAA requires that SOC 2 never asks about, and how to tell which gap you are actually in.

The sentence that starts most of these conversations is some version of: "We're SOC 2 Type 2, so we're fine on HIPAA, right?"

It is an understandable assumption. You went through months of evidence collection, an auditor looked at your access controls and your logging and your incident response plan, and a report came out the other end saying the controls operated effectively. If a hospital system is asking about your security posture, surely that report answers the question.

It answers a lot of the question. It does not answer all of it, and the parts it leaves out are the parts that carry legal exposure rather than sales friction.

Here is the honest mapping: what genuinely overlaps, what SOC 2 never touches, and how to figure out which gap you are in.

They are different kinds of things, not different levels of the same thing

This is the root of the confusion, so it is worth being precise about it.

SOC 2 is an attestation. You define a set of controls, you map them to the Trust Services Criteria — security, and optionally availability, processing integrity, confidentiality, and privacy — and an independent CPA firm issues a report expressing an opinion on them. A Type 1 report says the controls were suitably designed as of a point in time. A Type 2 report says they operated effectively across a period. Crucially, you substantially define the scope and the controls. The auditor tests what you claimed, not a fixed government checklist.

HIPAA is a law. It applies to covered entities and, through the business associate provisions, to the vendors that handle protected health information on their behalf. There is no HIPAA certificate. No auditor can make you "HIPAA certified," and any vendor selling you one is selling you their own opinion dressed up as a credential. Compliance is a continuous legal obligation, assessed after the fact — typically when something goes wrong and a regulator asks what you had in place.

So the shapes do not line up. A SOC 2 report is a deliverable you can hand a prospect. HIPAA compliance is a state you are either in or not in, demonstrated through your own documentation.

There is a second structural difference that matters more than it sounds. SOC 2 asks whether the controls you described worked. HIPAA asks whether you met obligations someone else wrote, with penalties that scale by how culpable your failure was. That means a SOC 2 report can be entirely accurate and still describe a program that misses a HIPAA requirement, because the requirement was never in the description the auditor tested. Nobody lied. The scope simply did not include it.

The practical consequence: you cannot audit your way to knowing whether you have a HIPAA gap. You have to read the rule and check yourself against it.

What genuinely overlaps

Enough that the work is far from wasted. If you have a mature SOC 2 program, you have already built most of the technical machinery HIPAA's Security Rule asks for.

Access control. Both regimes want the same thing: unique identity per user, least-privilege role assignment, a documented provisioning and deprovisioning process, and periodic access reviews. The SOC 2 evidence — your IdP configuration, your offboarding checklist, your quarterly access review artifacts — is directly reusable.

Audit logging. This is the strongest single overlap. Both want a durable record of who accessed what, when, and what changed, stored in a way that the people being logged cannot quietly edit. If you built append-only logging with actor, action, resource, timestamp, and outcome, that pipeline carries straight over. (The audit logging piece goes into the structural specifics.)

Encryption. Encryption in transit and at rest is table stakes for a SOC 2 security scope, and it maps cleanly onto HIPAA's expectations. One nuance worth knowing: within the Security Rule's structure, encryption sits among the addressable implementation specifications rather than the strictly required ones — which does not mean optional, it means you either implement it or document a defensible reason why an equivalent alternative is appropriate. In practice, in 2026, "we chose not to encrypt PHI" is a very hard position to document defensibly. And encryption carries a second benefit: properly encrypted data that is lost may not trigger breach notification at all.

Incident response. Both want a written plan, defined roles, and evidence that you exercise it. The SOC 2 version is a solid foundation for the HIPAA version.

Vendor risk management. Both want you to know who your critical third parties are and to have assessed them. Same inventory, same diligence process — though, as below, not the same contracts.

If you tally it up honestly, a well-scoped SOC 2 security program probably covers a substantial majority of HIPAA's technical safeguards. That is real, and it is why the "we already did SOC 2" instinct feels right.

What SOC 2 does not cover at all

Three categories. None of them are technical, which is exactly why engineering teams miss them.

1. Business Associate Agreements

If you handle PHI on behalf of a covered entity, you are a business associate, and there must be a signed BAA between you and that entity. And it does not stop at your front door: your own vendors who touch that PHI — your cloud provider, your logging vendor, your email service, your database host, your error-tracking tool — need BAAs with you in turn. The chain has to hold all the way down.

SOC 2 has vendor management expectations, and an auditor will look at whether you have contracts with critical vendors. But there is no SOC 2 control that says "you must have this specific legal instrument, containing these specific mandated terms, with every party that touches this specific category of data." A company can hold a spotless Type 2 report while having no BAAs whatsoever. Nothing in the audit would catch it.

This is the single most common gap I see. It is also the cheapest to close, because it is paperwork rather than engineering — as long as you discover it before a deal or an incident forces the question.

The engineering consequence shows up when a vendor will not sign. Plenty of excellent developer tools have no BAA on offer at your pricing tier, or none at all. When that happens you are not choosing between compliance and convenience; you are choosing between swapping the vendor, upgrading to a tier where a BAA exists, or architecting so that PHI never reaches that vendor in the first place. The third option is often the right one and is almost always the one nobody costed. Scrubbing PHI out of logs, error payloads, and analytics events before they leave your boundary is real work, and it is much cheaper to design in than to retrofit after a tool is wired into forty code paths.

2. Breach notification

HIPAA has a specific breach notification regime with specific timelines: notification to affected individuals without unreasonable delay and within a defined outer bound from discovery, notification to HHS, and, above a threshold number of affected individuals in a jurisdiction, notice to prominent media. The exact numbers and thresholds are set in regulation and are worth reading in the current text rather than trusting anyone's summary, this one included.

SOC 2 asks whether you have an incident response process. It does not encode a statutory clock. Your beautifully documented SOC 2 incident runbook can be fully compliant with your own stated controls while missing a legally mandated deadline entirely — because the deadline was never part of what you were audited against. If PHI is in scope for you, the notification timeline needs to be written into the runbook itself, not left to be looked up during the incident.

3. The Privacy Rule and patient rights

The largest structural gap. HIPAA's Privacy Rule governs uses and disclosures of PHI and grants individuals rights over their own health information: the right to access and obtain a copy of their records, the right to request amendments, the right to an accounting of certain disclosures, and constraints on how PHI may be used and shared.

SOC 2 has an optional Privacy criterion, but it is oriented around your commitments in your own privacy notice, not around a statutory bill of individual rights. Nothing in a standard SOC 2 security scope asks whether your product can respond to a patient's access request within the required window, or whether you can produce an accounting of disclosures.

For a product team this is frequently a feature gap, not a policy gap. If you cannot export one individual's complete record on request, no amount of policy documentation fixes it. That is a build.

So: do we need a separate HIPAA push?

If you touch PHI directly, the answer is almost always yes — but a much smaller one than the first SOC 2 push was.

The practical sequence I would use:

Determine whether PHI is actually in scope. Some products are adjacent to healthcare without ever holding PHI. This determination is a legal question, not an engineering one, and getting it wrong in either direction is expensive.
Do the risk analysis. It is a named requirement, it is PHI-specific, and it is where enforcement attention tends to land. You can reuse SOC 2 artifacts as inputs; you cannot substitute the report for the analysis.
Paper the BAA chain. You and your customers, then you and every downstream vendor with PHI exposure. Some vendors will not sign one — that is a procurement decision you need to surface early.
Write the notification clock into the runbook. Not a separate policy document nobody opens during an incident.
Audit the Privacy Rule surface as a product question. Access, amendment, accounting of disclosures. Find out what your system can and cannot do today.
Re-scope the logging you already have. Confirm PHI reads are captured, not only writes, and that someone actually reviews the logs on a cadence with evidence that they did.

Steps 1 through 4 are mostly legal and process work. Steps 5 and 6 are engineering, and they are the parts that quietly take a quarter if nobody scoped them.

The short version

SOC 2 gets you most of the way through HIPAA's technical safeguards and none of the way through its contractual, notification, and patient-rights obligations. The overlap is real and worth leaning on. The gap is not technical, which is precisely why teams full of good engineers walk past it.

If you are building a product that will touch PHI, the cheapest time to handle this is before the architecture sets — see HIPAA-conscious Next.js and Vercel deployments for the infrastructure side, or compliance-ready software for how I approach building it in from the start.

This page is written from an engineering perspective and is not legal advice. HIPAA determinations — including whether you are a covered entity or business associate, what your BAA obligations are, and what your notification duties are — should be reviewed with qualified counsel.