SOC 2 Type II vs HIPAA Certification for Healthcare AI Tools

Healthcare AI buyers routinely treat SOC 2 Type II and HIPAA certification as interchangeable signals of vendor trustworthiness. They answer different legal and operational questions entirely, and confusing them is how practices end up trusting a vendor that has passed one test while failing the other. HIPAA is a federal law enforced by the HHS Office for Civil Rights, and it applies automatically to any entity that handles Protected Health Information, whether that entity wants it to or not.

The incentive structures that produce each credential point in different directions. HIPAA compliance does not wait for a customer to ask. Any vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate under the law, and that status triggers legal obligations regardless of whether anyone requested proof of them.

The two also differ in what they produce at the end of the process. HIPAA has no equivalent document. There is no certificate to earn, no expiration date to track, and no single body that issues a HIPAA seal of approval. Compliance is a continuous legal state, and OCR enforces it through audits, breach investigations, and the Business Associate Agreements a vendor signs with its covered-entity customers.

The consequences for falling short are not symmetric either. Violate HIPAA, and you face civil penalties up to $1.5 million per violation per year, plus criminal penalties and direct enforcement action from OCR. A vendor that treats the two as equally serious compliance projects is misreading the stakes on one side of that comparison.

What SOC 2 Type II proves and leaves out

SOC 2 Type II is the stronger of the two SOC 2 report types because it tests whether a vendor's security controls held up over months of actual operation, not just whether they looked sound on paper at a single point in time.

The audit is organized around a set of Trust Services Criteria. Security is the one mandatory category, and four others, Availability, Confidentiality, Processing Integrity, and Privacy, are optional additions a vendor may or may not choose to include. A vendor's report can cover Security alone and leave Availability or Privacy completely untested. Two vendors can both hold "SOC 2 Type II" and have been audited on meaningfully different ground. Buyers need to request the actual report and read its scope section, because the badge on a website says nothing about which criteria were actually in play.

Timing carries real information too. A vendor that has recently earned SOC 2 Type II has, at minimum, been running those controls under live conditions for that stretch of time, which is a legitimate signal of organizational discipline.

None of that reaches patient data specifically. SOC 2 Type II does not require handling PHI in any particular way, does not require a Business Associate Agreement, and says nothing about how fast a vendor has to notify anyone after a breach. A vendor can pass a full SOC 2 Type II audit and never touch a patient record. It answers whether a vendor's security controls worked over time, not whether that vendor is legally allowed to handle PHI.

What HIPAA compliance requires a vendor to do

HIPAA compliance is a set of legal and technical obligations that all have to hold at the same time for handling PHI to be lawful, and missing any one of them breaks the chain.

Four rules do the work. The Privacy Rule governs what a vendor is allowed to do with PHI and who it can share it with. The Security Rule sets technical, administrative, and physical safeguards for electronic PHI. The Breach Notification Rule requires telling affected parties when PHI has been exposed. The Enforcement Rule lays out how HHS OCR investigates and penalizes violations. The Security Rule alone breaks down into a full set of standards and implementation specifications spread across those three safeguard categories, administrative, physical, and technical.

The Business Associate Agreement sits at the center of all of it. Any vendor that creates, receives, maintains, or transmits PHI for a covered entity has to sign one, and without it, no amount of encryption or access control makes that vendor's handling of PHI lawful. The scope of the agreement matters just as much as the fact that one exists. If a BAA covers the core product but skips integrations, logs, or support tooling, it leaves a gap in exactly the places PHI tends to leak out, so buyers have to check that the agreement names every surface the vendor will actually touch.

That chain of coverage does not stop with the vendor itself. In all three cases, the cloud provider offering a BAA does not mean a given vendor has actually accepted or applied it to the way it uses that infrastructure.

The Security Rule spells out concrete technical requirements too: encryption at AES-128 or higher for data at rest, with AES-256 recommended; TLS 1.2 or higher for data in transit, which is currently an addressable rather than mandatory safeguard, though a proposed update would make it required; role-based access controls; and audit logs that are tamper-evident and timestamped, recording who accessed what PHI, when, and from where. It has to be written into the BAA or master agreement, with the retention window for prompts and outputs specified alongside it. That requirement, that the BAA has to name every system and every subcontractor a vendor's product actually touches, is the exact weak point AI agents expose next.

AI agent PHI exposure surfaces neither certification was designed to catch

Computer-use AI agents read screens, move through payer portals, and work inside EHRs the way a staff member would, so PHI exposure can happen at nearly every step, not just the points a compliance checklist was built to inspect at rest. Every screen the agent reads, every document it pulls, and every action it logs can carry PHI, and that exposure piles up across logs, cached documents, retrieval history, and chat state in ways a one-time audit was never designed to track continuously.

The gaps are already visible at the platform level. Some platforms claim compliance without a published BAA at all, so a buyer cannot assume coverage exists. It has to be confirmed in writing, for the specific product and for every integration the agent touches.

The model underneath the product produces its own separate exposure point. If PHI reaches an AI vendor whose underlying model provider has no BAA in place with that vendor, the result is a breach no matter how secure the front-end interface looks to a user. Coverage has to extend all the way to the model provider: PHI sitting in an inference request that reaches a model outside the BAA's boundary is exposed, full stop, regardless of what the rest of the stack looks like.

No single certification closes all of these gaps by itself. SOC 2 checks whether a vendor's controls operated as designed. HIPAA sets the specific safeguards a vendor has to put in place. A vendor can satisfy both and still leave PHI exposed through an integration the BAA never named, a log retention policy nobody wrote down, or a model endpoint sitting outside the agreement's scope. For platforms that operate across multiple EHRs and payer portals at once, reading screens and maintaining access across dozens of practices simultaneously, SOC 2 Type II attestation carries particular weight: it confirms that access controls, incident response, change management, and infrastructure security held up under sustained, real-world operational load, Novoflow among the vendors in this category where that kind of attestation speaks directly to the agent's actual working conditions, not just its design intent.

Where the two frameworks' control sets overlap and diverge

SOC 2 and HIPAA overlap more than buyers usually expect. If a vendor has run serious SOC 2 controls for a full year, it has already built much of the technical groundwork HIPAA requires, and patient data protection actually lives or fails in the gap that remains between the two frameworks.

HIPAA still adds requirements that SOC 2 never touches. The Privacy Rule governs what a vendor is permitted to do with patient data, not just how well it is locked down technically, a distinction SOC 2's security-focused criteria don't address. Breach notification carries hard deadlines under HIPAA: a vendor has 60 days from discovering a breach to notify affected individuals, and must notify HHS and the media once 500 or more people are affected. The BAA itself, and the chain of subcontractor agreements it requires, has no SOC 2 counterpart. And the Security Rule's full set of 18 standards and 36 implementation specifications, spread across administrative, physical, and technical categories, goes well beyond anything SOC 2's criteria specify in scope or detail.

The practical consequence for a buyer evaluating a vendor: holding SOC 2 Type II without a BAA means the security engineering is sound but the legal commitment that makes PHI handling lawful was never made. One does not substitute for the other. Both have to be in place at the same time for PHI to move through a vendor's systems without creating legal exposure for the covered entity on the other end of the contract.

HIPAA compliant" on a vendor's website is not a verification

Because no government body issues a HIPAA certificate and there is no single document to request, the words "HIPAA compliant" on a vendor's homepage amount to a self-attestation, and that attestation can describe anything from a fully signed BAA with complete technical safeguards down to nothing more than an internal policy memo nobody outside the company has seen.

Real HIPAA readiness comes down to three facts that all have to be true together: the vendor will sign a BAA, the PHI actually runs through an environment that BAA covers, and PHI is contractually excluded from model training and human review. If any one of the three is missing, the other two stop meaning much. A signed BAA that does not cover the environment where data actually flows protects nobody, and a training exclusion that only lives in a sales conversation is not enforceable if a breach ever gets investigated.

SOC 2 Type II holds up to scrutiny in a way a HIPAA compliance claim does not, because the audit report is a document written by an outside party, with a defined scope section, disclosed exceptions, and a specific assessment period attached. Buyers can ask for that full report rather than settling for the badge on a landing page, and the scope section tells them something specific: if the product they are buying was not inside that scope, the certification says nothing about its controls.

The market already has vendors holding valid SOC 2 Type II reports who explicitly do not offer a BAA, and that disqualifies them from handling PHI no matter how clean their security audit looks. The certification and the compliance gap sit side by side, and the badge gives no hint that the gap is there. A vendor's claim to HIPAA compliance is only as solid as the Business Associate Agreement binding it to patient privacy obligations. If that agreement excludes the logs, integrations, or agent configurations a vendor's product actually runs on, PHI moving through those channels is unprotected no matter what the technical audit found. Buyers should insist the BAA names every surface where an agent accesses, reads, or processes patient data, not just the primary interface.

Compliance that is built into how a product works tends to hold up better than compliance that depends on an administrator configuring it correctly after the fact. If a product automatically keeps PHI workloads routed only to BAA-covered models, it closes off a failure mode that a policy document, however well written, cannot prevent on its own.

Verifying PHI handling in writing before sharing data with a healthcare AI vendor

Neither certification explains itself, and both are open to scope gaps a reader won't catch from a marketing page, so buyers need a specific, written verification process rather than a general impression that a vendor "looks compliant." Start by asking for the SOC 2 Type II report itself, not the badge, and read the scope section to see which Trust Services Criteria the audit covered and whether the product you're buying was included. Ask the vendor directly whether it will sign a Business Associate Agreement, and treat a hesitant or vague answer as disqualifying, because the BAA is the single legal instrument that makes PHI handling lawful. Get the BAA's exact scope in writing, confirming it names every integration, log, and piece of support tooling the product touches, not just the core interface a sales demo shows. Trace the subcontractor chain by name: confirm which cloud infrastructure the vendor runs on, whether that provider's BAA has actually been accepted (through AWS Artifact, the Google Cloud Console, or Microsoft's standard licensing terms), and whether the underlying AI model provider is covered by that same agreement. Get the model training and data retention terms written into the contract itself, rather than accepting a FAQ statement that data isn't used for training, because only contractual language holds up under an OCR investigation. Confirm the specific technical safeguards in place, including encryption standards for data at rest and in transit, role-based access controls, and audit logging that records who accessed PHI, when, and from where. And ask how the vendor's product handles AI agents operating across multiple systems: whether access scope is limited by design, whether PHI exposure is contained automatically rather than left to an administrator's configuration choices, and whether that architecture has been tested under the same kind of sustained, real-world conditions a SOC 2 Type II audit is built to examine.