AI Receptionist Security: What a Signed BAA Doesn't Tell You

A vendor tells you they sign a BAA. You check that box, sign the contract, and move on to training staff on the new phone flow. Six months later a call recording ends up somewhere it should not, and the BAA tells you who is liable. It tells you nothing about why the leak happened in the first place, because a BAA was never built to answer that question.

This site already walks through the BAA-level basics in is an AI receptionist HIPAA compliant: the 8 questions to ask, why a "HIPAA compliant" badge on a homepage is a self-attested marketing claim, and what a signed BAA does and does not buy a practice. If you have not run that checklist yet, start there. This post picks up exactly where it stops.

A vendor that passes the BAA questions has cleared the legal minimum. That is not the same thing as a verified technical security posture, and treating the two as interchangeable is exactly how practices end up trusting a policy document instead of a tested system. The rest of this post is about the layer underneath the paperwork: encryption specifics, access controls, subprocessors, and what "SOC 2 certified" actually needs to mean before it is worth anything.

None of this replaces the cornerstone standard already set for evaluating any AI receptionist: what an AI receptionist does and where it stops. Security posture and the clinical-judgment boundary are 2 different questions a serious vendor should be able to answer without flinching at either one.

What a healthcare data breach actually costs, and who attackers still target

Healthcare remains the costliest industry for a data breach for the 13th consecutive year, averaging $6.64 million per incident in 2026, and healthcare organizations faced 410 ransomware attacks in just the first half of the year, roughly 2.3 a day.

Published ranges, each sourced. The reason to verify a vendor's security, not just its paperwork.

96% of healthcare ransomware incidents now include data exfiltration, meaning attackers steal a copy of the data before locking anything, which gives them leverage over a practice even if a ransom is refused and backups restore cleanly. Encryption and access controls matter more, not less, once theft rather than lockout is the primary threat.

The instinct to assume attackers only target large hospital systems does not hold up. An estimated 53% of breaches involve fewer than 5,000 records, the range a single independent practice or small multi-location group would actually produce, not a regional hospital network. Smaller practices are common targets precisely because they are commonly under-defended.

An AI receptionist widens what is at stake here, not because the tool itself is inherently riskier, but because it touches every incoming call rather than a subset of them. A vendor handling that volume without a verifiable security program is concentrating risk in exactly the system a practice now depends on daily.

Detection, escalation, and lost business, not the ransom payment itself, drive most of that $6.64 million figure. A breach caught in days costs far less than one that goes unnoticed for weeks, and a practice's own monitoring habits factor into that window almost as much as a vendor's do. Asking a vendor how they would even notice unusual access to your data is a fair, answerable question, and a vendor with a real program has a specific answer ready rather than a shrug.

A signed BAA versus a verified security posture

A BAA is necessary and makes a vendor legally accountable for a breach. It does not, by itself, confirm that data is actually encrypted to a real standard, that internal access is actually restricted, or that anyone has ever tested what happens during a real incident rather than just writing a policy describing one.

The BAA is the legal floor. It was never meant to be the technical ceiling.

Look at what each side of that comparison actually requires from a vendor. A BAA takes a signature. A verified security posture takes a report you can read, a subprocessor list you can check, and a plan you can ask whether it has ever been rehearsed. Only one of those is something a vendor can produce in the same meeting where they sign the contract.

This distinction matters most exactly where a practice is tempted to skip it: after the BAA is already signed and the relief of clearing that hurdle makes the next set of questions feel like overkill. It is not overkill. It is the difference between a vendor who is legally on the hook after something goes wrong and a vendor whose setup makes something going wrong meaningfully less likely.

SOC 2 Type II is the real signal, not the SOC 2 name alone

"SOC 2 certified" gets used the same way "HIPAA compliant" does, as a badge rather than a specific claim. The type of SOC 2 report matters enormously, and most vendor marketing never mentions which type they have, even though the difference between the 2 types is large enough to change what the certification is actually worth.

A Type I report is a snapshot. It tells you a vendor designed reasonable-looking controls as of one specific day, which is a real step above nothing, but it says nothing about whether those controls held up under the ordinary pressure of daily operations. A Type II report is closer to a track record: an independent auditor checked whether the controls were actually followed, month over month, not just described.

Ask a vendor directly which type they hold, and ask to see the report itself rather than accepting the name of the framework as sufficient. A vendor that hesitates to share a summary of its own SOC 2 report, citing confidentiality, can usually still provide a redacted version or a bridge letter covering the gap since the last audit period. A vendor that cannot do either of those has likely never completed the audit at all.

The technical questions that separate a real security program from a policy document

Beyond the report itself, a handful of specific, plainly worded questions expose the gap between a real security program and a document written to sound like one, without requiring the person asking to have any technical background at all, or to know anything more than what a specific answer sounds like versus a vague one.

None of this requires a technical background. It requires asking for evidence instead of a claim.

The subprocessor question deserves special attention because it is the one most vendors answer incompletely. A call does not just touch the AI receptionist vendor. It typically touches a cloud hosting provider, an LLM provider, a transcription service, and sometimes a separate telephony carrier, and each one is a company that had access to some slice of that call's data. A vendor that can only name the LLM provider, and shrugs at the rest, has not actually mapped its own data flow.

Where this fits with the BAA checklist you already ran

The sequence matters as much as the individual questions. BAA and subcontractor naming come first, since a vendor that fails that baseline has no business being evaluated on security depth at all. Technical verification comes second, and only after both layers clear does a long-term commitment make sense.

Route by what has actually been verified, not by what a vendor asserts.

Walk the flow once: a vendor without a signed BAA naming its LLM subcontractor fails before security specifics are even worth discussing. A vendor that clears the BAA but cannot produce a current SOC 2 Type II report has an unverified security claim, not a verified one. A vendor that clears both and can name its subprocessors and describe a tested incident response plan has earned a long-term commitment on security grounds specifically, separate from whatever else makes the tool a good fit.

This is additive to the compliance baseline, not a replacement for it. A vendor can fail either layer independently of the other: a legally sound BAA sitting on top of a weak technical setup, or a genuinely strong security program attached to a vendor that never actually signs the paperwork correctly. Checking one layer tells you nothing reliable about the other.

In practice, most of this fits into the same vendor conversation as the BAA questions, just later in it. A vendor worth a long-term contract will not treat a request for a SOC 2 report or a subprocessor list as an unusual ask. Expect them to have handled the question often enough that the answer is already written down somewhere, ready to send, rather than assembled fresh in response to you specifically.

Verify before you sign anything long-term

Before committing to any vendor beyond a short pilot, confirm the technical layer the same way you already confirmed the legal one: in writing, with evidence, not a verbal assurance from a sales call. Four specific items separate a genuinely verified vendor from one that only sounds like it on a homepage.

None of this needs to feel adversarial. A vendor with a real security program treats these questions as routine, because they answer them constantly, and a vendor that bristles at being asked has told you something worth knowing before a contract, not after an incident. If you would rather have your current call-handling setup reviewed for gaps like this alongside your broader front-desk numbers, the free Growth Leak Audit works from your own numbers before anyone talks tools.