Does Your Call-Recording Vendor Need a BAA? Here’s How to Tell

No federal agency issues a “HIPAA certification.” HHS does not certify, accredit, or approve vendors as HIPAA compliant. When a vendor’s sales page says “HIPAA certified,” that’s a marketing claim, not a legal fact — and it tells you nothing about whether they’ll actually sign a BAA, or what that BAA will cover once you ask for one.

What does exist, per HHS, is a defined relationship: a covered entity (a health plan, provider, or clearinghouse) that engages a business associateto create, receive, maintain, or transmit PHI on its behalf must have a written BAA with that vendor. A Medicare telesales agency sits in a similar position — the agencies your carriers hold you to expect the same discipline even though the underlying HIPAA mechanics run through the carrier as the covered entity. Either way, the practical test is the same: does the vendor touch data that identifies a real person’s health-plan activity? If yes, get a BAA. If a vendor won’t sign one, that’s your answer about whether to use them for anything PHI-adjacent.

Skip the marketing language and ask one question for every tool in your stack: can this vendor see, store, or process information that ties a specific beneficiary’s name or contact info to a health condition, plan selection, or enrollment status?

• •A call recording of a beneficiary discussing chronic conditions or plan benefits is PHI the moment it’s captured — the vendor storing that file needs a BAA, full stop.
• •A CRM record with a name, phone number, and “interested in Plan G” noted against it is PHI, even though it looks like ordinary sales data.
• •A dialer that only stores phone numbers with no health context attached is a closer call — but if it’s wired into the same CRM or call log that holds PHI, it likely needs coverage too.
• •An AI transcription tool that converts your recorded sales calls to text is processing PHI, even if the output only lives for a few minutes before it’s deleted.

Here’s how that test plays out across the tools most Medicare agencies and call centers already run:

The pattern: if a tool sits anywhere near the call itself — recording it, storing it, transcribing it, or logging notes about what was said — assume it needs a BAA until a vendor or your counsel tells you otherwise. Tools that are purely logistical (scheduling, general marketing analytics) are the exception, not the rule.

1. 1Do you offer a signed BAA, or only a generic “security overview” PDF? A security whitepaper is not a substitute for a contract.
2. 2What specifically is covered — call recordings, CRM fields, transcripts, all of the above, or just a subset?
3. 3What’s explicitly excluded? Some vendors will sign a BAA for their core storage layer but exclude a connected AI or analytics add-on — ask directly.
4. 4Who has access on their end, and do their own subprocessors (cloud hosting, backup providers) have BAAs in place with them?
5. 5What happens to the data if you cancel the contract — is it deleted, and on what timeline?

The most common error we see is agencies treating Medicare sales calls as pure sales data — no different from a mortgage lead call. But the moment a beneficiary mentions a diagnosis, a current medication, or which plan they’re leaning toward, that recording contains PHI. It doesn’t matter that the call originated as a marketing call rather than a clinical one. If the content identifies a person and touches their health status or plan choice, treat it as PHI and make sure every vendor touching it is covered.

A signed BAA transfers legal responsibility for specific safeguards to the vendor — it does not make your agency “HIPAA compliant” as a purchasable end state. Compliance is a shared responsibility: your vendor secures their systems, and you still need your own policies for who on your team can access recordings, how long you retain them, and how you respond if something goes wrong. A vendor with an airtight BAA and a call center with no internal access controls is still exposed.

A signed BAA satisfies HIPAA. It does nothing for your CMS TPMO obligations, which run on a separate track: documented Scope of Appointment, disclaimer timing, and consent capture. See what changed (and didn’t) with the FCC one-to-one consent rule for how CMS’s own consent expectations sit apart from both HIPAA and the vacated FCC rule. The overlap is practical, not legal: the same call-recording vendor that needs a BAA for HIPAA is usually the same system you rely on to prove SOA and disclaimer timing for CMS. One system, two separate compliance obligations riding on top of it — which is the gap most Medicare vendor stacks were never built to close.