SOC 2 and HIPAA: what healthcare buyers check beyond the report

Healthcare buyers run a different review from everyone else. A hospital system, a payer, or a digital health platform will ask for your SOC 2 report, and then keep going: a business associate agreement, a security risk analysis, and a questionnaire that assumes you already know which safeguards apply to you. Here is what that review is made of, and how one control program covers both.

SOC 2 and HIPAA answer different questions

SOC 2 is an attestation report issued by a licensed CPA firm against the AICPA Trust Services Criteria. It answers whether an independent auditor examined your security program and what they concluded. It is voluntary, it is general purpose, and no regulator requires it.

HIPAA is federal law. There is no such thing as being HIPAA certified, and any vendor claiming a HIPAA certification is describing something that does not exist. The Security Rule sets out administrative, physical and technical safeguards for electronic protected health information, and those obligations attach to you the moment you handle that data on a covered entity’s behalf.

The practical relationship is this: SOC 2 gives you the evidence machinery, and HIPAA tells you which additional obligations that machinery has to satisfy. Most of the work overlaps. Access control, audit logging, encryption, incident response, workforce training and vendor management appear in both. What does not overlap is the part healthcare buyers check hardest.

The three things a SOC 2 report will not answer for a healthcare buyer

The business associate agreement. If you create, receive, maintain or transmit protected health information for a covered entity, you are a business associate and a signed agreement is required before the data moves. Your subcontractors who touch that data need agreements too, flowing down the same obligations. A SOC 2 report says nothing about whether those agreements exist, and a buyer’s counsel will ask for them by name.

The security risk analysis. The Security Rule requires an accurate and thorough assessment of risks and vulnerabilities to electronic protected health information, kept current. This is the single most cited failure in enforcement actions, and it is a specific deliverable, not a general statement that you take security seriously. SOC 2’s risk assessment criteria get you most of the way; naming the analysis and scoping it to protected health information specifically is what closes it.

Breach notification timing. HIPAA’s notification obligations run on statutory clocks, and business associate agreements routinely impose tighter contractual ones on top. Your incident response plan has to be able to meet the shortest deadline you have signed up to, and that is usually contractual rather than statutory. Compare the two before an incident, not during one.

What is actually happening with the Security Rule right now

In January 2025 the Office for Civil Rights published a proposed rule that would substantially rewrite the Security Rule, most notably by removing the distinction between required and addressable implementation specifications, which today lets an organization document why a safeguard is not reasonable and appropriate rather than implementing it. The proposal would also make encryption, multi-factor authentication, asset inventories and network segmentation explicit expectations.

It is still a proposal. The comment period closed in March 2025, roughly 4,745 comments were filed, and more than a hundred hospital systems and provider associations formally asked for withdrawal. The federal regulatory agenda now targets final action in 2027, and that target has already moved once. The existing Security Rule remains in force in the meantime, and any article telling you the new rules are in effect is wrong.

The useful read is not to build for a proposal that may change. It is to notice that everything in it, encryption, multi-factor authentication, asset inventory, segmentation, is already what a SOC 2 examination and a healthcare buyer’s questionnaire ask you about. Build those well and the rule change is an update rather than a project.

The order that works

1. Establish where protected health information actually lives. Every store, every flow, every subcontractor. This is the input to the risk analysis, the business associate agreements, and the SOC 2 system description all at once.
2. Get the agreements in place and flowed down. Before the buyer asks, and before the data moves.
3. Build one control set. Map the Trust Services Criteria and the Security Rule safeguards to the same controls, so one access review, one training record and one incident plan serve both.
4. Run the security risk analysis as its own named deliverable, scoped to protected health information, and keep it current rather than annual by accident.
5. Time the SOC 2 audit against your sales calendar. Auditor calendars fill months out, so the CPA firm is engaged early rather than when a deal is waiting.

One honest limit

We build the security program and the evidence that a healthcare buyer’s review depends on, and we fold Security Rule safeguards into the same control set your SOC 2 runs on. We do not give legal advice, we do not determine your status as a covered entity or business associate, and we do not draft your business associate agreements. Those are questions for your counsel, and a consultant who answers them for you is doing you harm.

Where we fit

Control and Function runs SOC 2 readiness as a fixed-fee engagement. We are not an audit firm and we do not issue SOC 2 reports: we build the program, prepare the evidence, refer you to a licensed CPA firm, and manage the audit through report issuance. We never assess our own preparation work, and we take nothing from any firm we introduce.

If you are somewhere between “a buyer just sent us a security review” and “we need a report by a deadline,” a 30-minute call will tell you where you actually stand. Book a readiness call or email hello@controlandfunction.com.