What SOC 2 Type II Actually Certifies — and What It Does Not

SOC 2 Type II is an attestation report, produced by an independent CPA firm working under the AICPA framework. It is not a certification issued by any governing body, and a vendor describing itself as "SOC 2 certified" is using a term that does not exist in the standard. There is no SOC 2 seal, no registry, no pass/fail stamp a company earns once and keeps forever. There is only a report, written by an auditor, covering a specific period, scoped to a specific set of systems.

That distinction matters for what a buyer should actually ask for. The correct artifact is the report itself, read under NDA, with attention to its scope, its period, and any exceptions the auditor noted. A badge on a website, a line in a sales deck, or a summary slide a vendor hands over in a sales call is not evidence of anything. Those are marketing claims standing in for a document that either exists in reviewable form or doesn't.

The audit comes in two forms, and the difference between them is not cosmetic. A Type I report evaluates whether controls are suitably designed at a single point in time, a snapshot of whether the right mechanisms exist on paper. A Type II report goes further: it evaluates both design adequacy and operating effectiveness across a continuous observation period, typically lasting several months. That means the auditor isn't just confirming that an access-review policy exists. Type II asks whether the controls worked in practice, not just whether someone wrote them down.

The AICPA defines five Trust Services Criteria a report can be built around: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security, often called the Common Criteria, is required in every SOC 2 report regardless of scope. Security alone breaks down into 33 Common Criteria grouped as CC1 through CC9, spanning control environment, communication and information, risk assessment, monitoring activities, control activities, logical and physical access controls, system operations, change management, and risk mitigation. In practice, CC6, CC7, and CC8, covering access controls, system operations, and change management, generate the largest share of evidence requests and the largest share of audit findings.

None of this evaluates the vendor's security in some general sense. The report describes controls relevant to the security of customer data within a scope the vendor itself defines, not the security of the organization as a whole. Systems outside that scope boundary are not part of the audit, full stop on what the auditor can speak to. Buyers have to read the scope section of the report itself. Assuming SOC 2 covers everything a vendor touches is the first and most common misreading of the document.

Where SOC 2 and HIPAA compliance diverge even when both apply

A SOC 2 Type II report does not demonstrate compliance with HIPAA's Security Rule. Treating one as a stand-in for the other is the most consequential mistake a healthcare operator can make during vendor procurement, because the two frameworks overlap just enough to create false confidence.

The overlap is real as far as it goes. A vendor with a strong SOC 2 report has likely already built much of what HIPAA's Security Rule demands in these areas. The gap runs in both directions. HIPAA-native teams underbuild governance documentation; SOC 2-native teams underbuild PHI-specific obligations.

What HIPAA requires that SOC 2 does not formally touch is a distinct list: PHI-specific handling rules, the requirement that a vendor sign a Business Associate Agreement before it touches protected health information at all, breach-notification obligations owed to HHS and to affected individuals, and contractual language excluding PHI from model training or from human and machine review. None of these appear in the Trust Services Criteria, because SOC 2 was never built around a category of data called PHI.

The enforcement gap behind these obligations is just as stark. SOC 2 carries no government enforcement. The only consequence of failing to hold a SOC 2 report is that prospective customers decline to buy. One framework is backed by federal law; the other is backed by market pressure.

HIPAA's Safe Harbor method for de-identification, under 45 CFR 164.514(b)(2), requires stripping every identifier on a specific list, including zip codes and admission dates, and teams routinely leave both in supposedly de-identified data sets. No SOC 2 control evaluates whether a vendor's de-identification method meets that bar. A vendor can have a clean SOC 2 report and a broken de-identification process at the same time, because the audit was never asking that question. The reliable heuristic for a healthcare buyer is simple: ask for the signed BAA before asking for the SOC 2 report. A vendor that stalls on the BAA is telling the buyer something the SOC 2 report cannot.

What the subprocessor chain reveals beyond the SOC 2 report

A vendor can hold a clean SOC 2 Type II report while routing protected health information through a subprocessor that has never signed a BAA, breaking HIPAA compliance at a point the audit never reached.

A typical AI-assisted healthcare workflow moves data through several hops before it produces anything useful. Each hop is a point where a control could apply. Only the hops the vendor placed inside its SOC 2 scope were actually audited, and most vendors do not draw that scope boundary around every subprocessor in the chain.

Several of the largest third-party large language model API providers prohibit PHI transmission outright in their terms of service, regardless of whether a BAA exists anywhere else in the relationship. There is currently no exception path for some of the most widely used inference providers on the market. That means a vendor whose pipeline sends PHI to those APIs is out of HIPAA compliance the moment that data crosses the wire, no matter how strong the vendor's own SOC 2 report looks.

Anthropic is a named, verifiable case of exactly this boundary. A vendor or an individual analyst who routes PHI, clinical notes, EHR exports, patient correspondence, through the consumer or self-serve plans is out of HIPAA compliance the instant that data enters the interface, regardless of any other security posture that vendor holds.

The questions that expose this risk sit entirely outside the SOC 2 report. Which subprocessors touch PHI at any point in the pipeline? Which of those subprocessors have actually signed a BAA? A vendor that answers "our SOC 2 covers encryption and access controls" has answered a different question than the one being asked. Encryption and access controls govern data at rest and in transit within the audited scope. They say nothing about whether PHI was transmitted to a subprocessor whose terms of service forbid that transmission, or who never agreed to HIPAA obligations.

What SOC 2 omits about AI system behavior

SOC 2 contains no controls built specifically for artificial intelligence or machine learning systems. It applies to an AI vendor the same way it applies to any cloud software company handling customer data. Model behavior itself sits entirely outside what the audit evaluates.

Hallucination rates, the clinical accuracy of AI-generated output, bias in automated decisions such as prior authorization recommendations, and drift in model behavior over time: none of these appear anywhere in a SOC 2 report, because none of them are things the Trust Services Criteria were built to measure. It addresses whether system processing is complete, valid, accurate, timely, and properly authorized, and it is the criterion most relevant to AI output of any in the framework. But the auditor under Processing Integrity checks that a validation process exists and runs as documented. The auditor does not check that the AI's output is clinically correct or operationally sound.

For healthcare operations, that distinction has teeth. A vendor can pass every Processing Integrity control while its system produces prior authorization justifications, scheduling decisions, or claim summaries that are inaccurate or incomplete. The audit confirms the control mechanism exists and fires on schedule. It says nothing about whether the thing the mechanism produced was right.

SOC 2 was built around assumptions that autonomous AI agents violate directly. The framework presumes static controls, deterministic system behavior, and access that a human mediates at each step. An agent that generates and executes its own logic at runtime, adjusts its behavior based on training data, and makes decisions without a human authorizing each one, breaks every one of those assumptions at once. SOC 2 can confirm that the vendor's own code deployment process is disciplined. It cannot confirm that the agent's live decision-making, which changes by the minute depending on what it encounters, is sound.

Risks screen-operating agents introduce that the audit's legacy control model was not designed to assess

AI agents that operate payer portals and EHR workflows by navigating browser interfaces directly create operational and security exposure that SOC 2's change-management and access-control criteria were never designed to catch.

Credential storage is one clear example. SOC 2's access-provisioning controls under CC6 check whether access is granted appropriately and reviewed on schedule. They were not built to evaluate the architectural risk of aggregating large numbers of login credentials into a centralized store that an attacker only needs to breach once.

Payer portals also change constantly: new MFA requirements, new CAPTCHA logic, different session-handling rules. SOC 2 has no control that evaluates integration resilience or what actually happens operationally when an automated system fails mid-workflow. A vendor can hold a spotless SOC 2 Type II report while running entirely on opaque screen-scraping logic that no auditor has ever reviewed for clinical-workflow risk, because the audit covers the vendor's internal control environment, not the live behavior of its agents inside a payer portal's session.

The questions a buyer needs answered here don't appear in the report. How are portal credentials stored and protected at the agent level? What happens, specifically, when a payer portal changes its login flow without warning? Are agent sessions logged in a way that supports a later audit? What does the system do when an agent hits a screen state it wasn't built to recognize?

A vendor's architectural choice in answering these questions reveals more about its operational security than its SOC 2 report does. Agents that work across the same systems staff already use, EHRs, payer portals, other tools, by operating those interfaces the way a person would, so no stored-credential RPA integration wired into the back end ever exists for an attacker to find. Evaluating which of these two architectures a vendor has actually built tells a buyer more about operational security than the SOC 2 report sitting in the data room.

Regulatory obligations SOC 2 does not address but healthcare operators are accountable for

A SOC 2 Type II attestation says nothing about compliance with CMS interoperability rules or state-level AI governance legislation, and healthcare operators remain accountable for both regardless of what their vendor's report says.

State legislatures are moving fast on this front. Texas passed legislation in 2025 prohibiting utilization review agents from using an automated decision system to make an adverse determination, in whole or in part. None of these obligations appear anywhere in the Trust Services Criteria, because SOC 2 was never written with clinical decision-making authority in mind.

SOC 2 audits whether access controls and logging exist around data exchange. It does not assess whether a vendor's implementation complies with the 21st Century Cures Act, whether it interoperates correctly with specific EHR systems, or whether its data structures follow FHIR and HL7 standards properly. A buyer could read a flawless SOC 2 report cover to cover and come away with no information at all about whether the vendor's product can be legally deployed under Texas, Arizona, or Maryland law.

It's true that regulatory compliance is ultimately the operator's responsibility, not the vendor's. But a vendor's architecture decides whether the operator can meet that responsibility. A vendor whose automation issues fully automated prior authorization denials, with no step where a human reviews the decision before it goes out, puts its healthcare customer in violation of Texas, Arizona, and Maryland law the moment that workflow runs, no matter what the vendor's SOC 2 report says about its access controls.

Reading a SOC 2 Type II report as a healthcare buyer

Reading a SOC 2 Type II report well comes down to checking five specific things, none of which appear on the cover page or in a sales deck.

Check the scope section first and treat it as a boundary rather than a blanket. The report only speaks to the systems the vendor chose to put inside that boundary, and a narrow scope can leave entire parts of the product, including the parts handling PHI, outside what the auditor ever looked at.

Check the Trust Services Criteria the vendor actually included. Security is mandatory, but Processing Integrity, Confidentiality, Privacy, and Availability are optional additions, and a vendor handling PHI without Confidentiality or Processing Integrity in scope has chosen not to be tested on criteria directly relevant to healthcare data.

Check the exceptions the auditor noted. A Type II report that runs clean for six months with zero exceptions is rarer, and more meaningful, than a report with no exceptions disclosed at all, since every control environment of any complexity produces some findings over a multi-month observation window.

Check whether the vendor will sign a BAA before the SOC 2 report ever enters the conversation. A vendor that hesitates on the BAA has already answered the more important question.

Check the subprocessor list and ask, by name, which of those subprocessors touch PHI, which have signed BAAs, and what each one's contract says about using that data to train its own models. The SOC 2 report will not answer any of these questions, and a vendor that cannot answer them either has not mapped its own data flow carefully enough to be trusted with it.