The Compliance Question Your SOC 2 Report Does Not Answer

If your product touches patient data on behalf of a healthcare organization, you are a business associate
under HIPAA. That status does not come from signing something. It comes from what your software does with the
data, and it brings direct liability with it.

A SOC 2 Type II report is a real achievement and it does not resolve this. The two frameworks answer different
questions, and the gap between them is where most health-tech companies get caught during a customer's
security review.

What each one covers

SOC 2 is an attestation. An auditor evaluates your controls against Trust Services Criteria that you and the
auditor scope together. You choose which criteria apply. The output describes whether the controls you
selected were designed and operating effectively over a period.

The HIPAA Security Rule is a regulation. The requirements are set at 45 CFR §164.308, §164.310, and §164.312,
and you do not scope them. Some implementation specifications are required. Others are addressable, which does
not mean optional. Addressable means you assess whether the specification is reasonable and appropriate for
your environment, implement it if it is, and document the reasoning if it is not.

That documentation requirement is the part teams miss. A decision not to implement something is a deliverable,
not an omission.

Where a SOC 2 leaves you exposed

Four gaps show up repeatedly.

The risk analysis. §164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of risks to the
electronic protected health information you create, receive, maintain, or transmit. A SOC 2 report contains a
risk assessment scoped to your Trust Services Criteria. Those are not the same document and one does not
satisfy the other.

Your own subcontractors. Every downstream vendor that touches the data on your behalf needs a Business
Associate Agreement with you, and that obligation flows all the way down the chain. Your cloud provider, your
logging platform, your error tracker, your support tool, your analytics. If an exception handler ships a stack
trace containing a patient identifier to a third-party service with no agreement in place, that is a
disclosure.

Breach notification. The Breach Notification Rule at 45 CFR §164.410 sets what you owe the covered entity
and when. SOC 2 has an incident response criterion. It does not define a regulatory notification clock or the
content of the notice.

Workforce training and sanctions. Required administrative safeguards. Frequently thin at engineering-led
companies where security is treated as an infrastructure concern rather than a people one.

The practical version

Before your next enterprise health system deal, work through this.

1. Write down every place patient data lands, including logs, queues, caches, backups, analytics, support tickets, and anything a developer can reach in a debugging session.
2. List every third party in that path and check whether a Business Associate Agreement exists with each one.
3. Run a risk analysis scoped to HIPAA rather than to your SOC 2 criteria, and keep the documentation.
4. Document your addressable-specification decisions with the reasoning, not just the outcome.
5. Confirm your breach notification path, including who decides and how fast.

Item two is where the surprises are. Teams routinely find services in the data path that predate anyone
thinking about HIPAA.

On the 2026 Security Rule

There is a proposed update to the HIPAA Security Rule under discussion. It is a proposal and has not been
finalized, so nothing in it is a current requirement. It is worth reading, because several of the proposed
changes point at exactly the areas above, but treat any vendor telling you the new rules are in force with
skepticism.

Doing the work

Most of this is tractable. The risk analysis is the piece that takes the longest, mostly because scoping it
correctly means finding every system in the data path first, which is the same inventory work as step one.

We build software for this at Medcurity, including Security Risk Analysis and
Business Associate tracking. The self-serve Security Risk Analysis starts at $499/year for organizations up to
20 staff and scales from there, and our advisors are available through the year rather than only at assessment
time. If it would help to talk through scope for a business associate specifically,
start a conversation with our team.

Either way, do not let a SOC 2 report stand in for a risk analysis. They are answering different questions,
and only one of them is a regulator's.