SOC 2 Type II for Clinical Dental AI Vendors: What to Demand Before You Sign

You probably think a signed business associate agreement means your AI vendor's security has been handled. A BAA is a contract about liability, though — a promise to be accountable for protected health information, not evidence that the vendor has the controls to actually protect it.

That gap is exactly where SOC 2 Type II lives. It is the difference between a vendor telling you they are secure and an independent auditor watching them operate securely for six to twelve months, then writing down what they saw.

For any practice or DSO evaluating clinical dental AI, HIPAA compliance and a signed BAA are the floor, not the ceiling. SOC 2 Type II is fast becoming the vendor-security bar that procurement and IT leaders require before PHI ever touches a third-party model.

What SOC 2 Type II Actually Attests To — And What It Does Not

SOC 2 is an attestation report produced under the AICPA's standards, in which a licensed CPA firm evaluates a service organization's controls against the Trust Services Criteria. The report is an opinion backed by testing evidence, not a certificate you frame on a wall.

Type II is the version that matters. It covers a defined audit window — typically six or twelve months — and the auditor samples real evidence to confirm each control did not merely exist on paper but operated consistently across that window.

Keep in mind what SOC 2 does not do. It does not certify your clinical accuracy, it does not validate your model's output, and it does not, on its own, make a vendor HIPAA-compliant.

Type I Versus Type II: Why The Distinction Decides Everything

A Type I report is a snapshot. The auditor confirms controls are suitably designed as of a single date — a photograph of the vendor's security posture on one convenient morning.

A Type II report is a film. It confirms those same controls operated effectively across the entire audit period, which is the only version that tells you how the vendor behaves on an ordinary Tuesday.

This is why the distinction is not pedantic. A vendor can design an elegant access-review control, screenshot it for a Type I, and never run it again — and you would never know from the snapshot.

The Five Trust Services Criteria, Read Like An Operator

SOC 2 is scoped against up to five Trust Services Criteria, and that scope is a choice the vendor makes. Security is the only mandatory criterion; the other four are included at the vendor's discretion.

That discretion is the first thing to interrogate. A clinical AI vendor that scopes only Security — and quietly omits Confidentiality and Privacy — has told you something about how it thinks about your patient data.

Here is how each criterion should map to a dental AI vendor's obligations, in plain operator terms:

• Security. The mandatory baseline — access controls, encryption, change management, and incident response. Its presence alone is table stakes and tells you almost nothing distinctive.
• Availability. Whether the system meets its uptime and recovery commitments. For chairside inference this is not cosmetic, because a model that is down mid-exam is a clinical workflow failure.
• Processing Integrity. Whether the system processes data completely and accurately. For an AI vendor this is the criterion closest to whether your charting or claims data arrives intact.
• Confidentiality. Whether information designated confidential is protected end to end. A clinical vendor omitting this criterion should have to explain why.
• Privacy. Whether personal information is collected, used, retained, and disposed of per the vendor's stated notice. This is the criterion most directly adjacent to your own HIPAA obligations.

The takeaway is not that every vendor must scope all five. It is that scope reveals priorities, and a clinical AI vendor scoping only Security is narrowing what it will be held accountable for.

What To Demand Before You Sign

Do not accept a logo on a trust page or a one-line claim in a sales deck. Demand the artifacts, and read them the way you would read a control-plane change before approving it.

Here is the list of what to request, and what each item actually tells you:

• The full report, not the badge. There is no SOC 2 "certificate" — there is a report with an auditor's opinion, a control matrix, and test results. A vendor who can only produce a logo is hiding the exceptions.
• The audit window and its recency. A report covering a window that ended fourteen months ago is stale. Ask for a current report or a bridge letter covering the gap.
• The auditor's opinion. Look for a "qualified" versus "unqualified" opinion, because a qualified opinion means the auditor found the controls did not fully meet the criteria.
• The exceptions list. Every real Type II report has exceptions, and a report with zero is either trivially scoped or not being read closely. Read what failed and how the vendor responded.
• The subservice organizations. Find out whether the vendor used the carve-out or inclusive method for its cloud and model providers, because carve-out means those controls were not tested in this report.
• The complementary user entity controls. These are the controls the report assumes you will run on your side. If you do not implement your CUECs, the vendor's SOC 2 does not cover the resulting gap.

Reading The Report: Exceptions, Carve-Outs, And The Bridge Letter

An exception is a control instance the auditor tested and found deficient. Exceptions are normal — what matters is severity, pattern, and the vendor's documented management response.

A single missed access review with a corrective note is one thing. A pattern of encryption or logging exceptions on a system holding PHI is a different conversation entirely.

The carve-out method is where most clinical AI risk actually hides. When a vendor runs inference on Amazon Bedrock, it typically carves out AWS's controls, meaning AWS's own SOC 2 covers the infrastructure and the vendor's report covers only what it built on top.

That is a reasonable structure, but you have to follow the chain. You are now relying on two reports, and the seam between them is where a stale-state read or an unlogged access can slip through.

The bridge letter closes the time gap. It is a signed statement from the vendor asserting that no material changes to controls occurred between the report's end date and today.

A bridge letter is an assertion, not an audit. Accept it for a short gap, and treat any vendor leaning on one for more than three months as overdue for a fresh report.

How SOC 2 Interacts With Subprocessors And The Model Layer

Clinical dental AI is never one system. It is an orchestration of a foundation model, a vector store, an inference layer, and usually a handful of integrations into your practice management system.

Each of those is a potential subprocessor, and each is a place PHI can move. SOC 2 scope tells you which of those hops the auditor actually examined — and which, like a carved-out vector database holding clinical embeddings, sit outside the tested boundary.

The model layer deserves specific scrutiny. Ask whether prompts and completions containing PHI are logged, where those logs live, and whether they are used for model training or evaluation.

A vendor running on Bedrock with a proper configuration keeps your data out of foundation-model training by default. But "by default" is a configuration claim, and SOC 2 is where you check whether that configuration is actually enforced and monitored.

This is also where your own evaluation discipline matters. SOC 2 attests to security controls, not to whether the model's clinical outputs are correct — and confirming that correctness is what a clinical AI evaluation suite exists to do.

When SOC 2 Type II Still Is Not Enough

SOC 2 is a security-controls attestation. It is not a clinical-safety certification, and treating it as one is its own category mistake.

A vendor can hold a spotless Type II report and still ship a model that drifts, misreads a tooth number, or degrades silently after a retraining cycle. Those are model-behavior risks, and they live entirely outside the SOC 2 boundary.

This is why SOC 2 belongs in a stack of requirements, not at the top of it. Pair it with a HIPAA BAA, a documented evaluation suite, ongoing model drift monitoring, and clear data-handling terms — then read each one for what it actually covers.

Before You Sign, Get A Second Set Of Eyes On The Report

If you are evaluating a clinical dental AI vendor and staring at a SOC 2 Type II report you are not certain how to read, that is exactly the moment to slow down. The exceptions list and the subservice scope are where the real risk sits, and both take an operator's eye to parse.

The team at NexV builds and operates HIPAA-grade clinical dental AI on Bedrock, and reviews vendor SOC 2 packages as part of our own diligence every week. Reach out for a working session — we will read the report with you, map where PHI actually moves in your stack, and name the control gaps you are about to inherit.