What makes an answering service HIPAA compliant? Checklist

When a practice hands its phones to an outside service, HIPAA still treats every patient call as the practice's responsibility. You can outsource the ringing; you keep the liability for what happens on those calls. Picking a HIPAA compliant answering service is due diligence the covered entity cannot skip.

The stakes are not abstract. Business associates are involved in roughly one in three reported healthcare breaches, and third-party involvement in those breaches doubled from 15% to 30% in a single year. Separately, operating without a required BAA is itself a HIPAA violation, breach or no breach.

Most of what ranks for this topic was written by the medical answering services themselves: four bullets about encryption, then a pitch. This guide is written from the practice's side of the table. It covers what separates a service that is genuinely ready from one that repeats the word "compliant": the BAA, the subcontractor chain, how PHI moves through texts, voicemail, and recordings, and the ten marks of a compliant operation — followed by where Greetmate stands on each of them.

Does your answering service even need to be HIPAA compliant?

Yes, with one carve-out that will not help you. If your answering service takes messages with patient names, routes calls about appointments, or stores any patient information on your behalf, it is a business associate under HIPAA. A signed BAA is required before it handles a single call, and the practice keeps responsibility for how that vendor handles PHI.

HIPAA has a narrow conduit exception for services that move data without accessing or storing it, such as postal mail or an internet provider. Answering services do not qualify. They read messages, keep transcripts, route calls based on what callers say, and often store recordings. That persistent access to patient information is what makes the vendor a business associate.

In practice the question settles itself fast. The moment a message pairs a patient name with an appointment reason, a callback number tied to a chart, or a question about a refill, protected health information is in the vendor's hands. Even a service that claims to take "just names and numbers" usually handles PHI, because the context makes the information identifiable.

A BAA is the entry ticket: here's what should be inside it

Every vendor page says "we'll sign a BAA." That is the entry ticket, and it is the bare minimum. What separates a real agreement from a signature page is what the document obligates the vendor to do. Four things belong in it:

Permitted uses, spelled out. The BAA should list exactly what the vendor may do with PHI: answer calls, take messages, relay them to your staff, support scheduling. Anything not listed is off-limits. Vague language like "as needed to provide services" is how scope creep gets in.

Subcontractor flow-down. Your BAA with the vendor does not automatically bind the vendor's own vendors. The terms do not travel down the chain on their own — a separate downstream agreement must exist before any subcontractor touches PHI. A serious vendor maintains those agreements and tells you when the list changes.

A breach notification window with a number in it. A practice must notify affected patients within 60 days of discovering a breach. Well-drafted contracts put the vendor's obligation at 24 to 48 hours so your team has room to run that clock. "Promptly" is an adjective; a serious vendor commits to hours.

Termination and PHI destruction. The BAA should state what happens to message logs, transcripts, and recordings when the contract ends: return or certified destruction of all PHI, on a stated timeline, with written confirmation.

OCR's enforcement record shows what that costs. Raleigh Orthopaedic paid $750,000, North Memorial paid $1.55 million, Cottage Health paid $3 million, and Pagosa Springs paid $111,400 in enforcement actions where BAAs were missing or inadequate. In each case the fine landed on the practice or the health system. The BAA was the covered entity's job.

How PHI actually moves: messages, texts, voicemail, and recordings

Who answers the call is one question. What the call leaves behind is another, and each channel carries its own rules.

Text messages

Standard SMS is not banned, but it is not automatically compliant either. Texting patient information takes a service covered by a BAA, a setup configured for how the PHI will be used, and in many cases affirmative opt-in from the patient. A ready operation has all three and can say which is which.

Voicemail

PHI should not be left on a patient's voicemail without the patient's consent. The script should handle it deliberately: name and callback number only, or full details once the caller says it is okay to leave them.

Call recordings

If the vendor records calls for quality or training, state recording and consent laws apply on top of HIPAA. Some states require one party to consent; others require everyone on the call. A vendor recording calls from multiple states needs to meet the strictest rule that applies to your callers.

A small local service and a large HIPAA compliant call center face the same obligations on texts, voicemail, and recordings. The channel sets the rules.

The subcontractor chain: who else touches your calls

Signing with an answering service means signing with its stack. One call can pass through a telephony carrier, a cloud host that stores the messages, a transcription or AI vendor that summarizes the call, and in some services an agent pool in another country. Any of those companies that touches PHI is a subcontractor business associate, and a downstream BAA must be in place before access happens.

A serious vendor can name that stack on request — a current list of subcontractors with PHI access, including where they operate, and confirmation that downstream BAAs exist for every company on it. Offshore processing is not prohibited, but it changes the risk picture and can change your notification obligations if something breaks.

This is where newer AI answering services most often fall short. The voice model, the telephony layer, the storage, and the analytics dashboard are frequently four different companies. A vendor that cannot name its own stack has a compliance story built on hope.

People and access: training, controls, and what happens after a breach

A signed agreement does not control what a live agent does at 2 a.m. with a message about a patient's refill. Three areas separate a ready operation from a hopeful one:

Training. Agents who handle PHI are trained on HIPAA basics at hire and refreshed on a schedule, and the training is documented. What happens when an agent mishandles a message is written down, not improvised.

Access controls. Not every agent needs to see every message. Solid vendors limit access by client and role, log who opens what, and can produce those logs. "All our agents are background-checked" is a statement about hiring. It is not an access control.

Breach response. A ready vendor has an incident process: who investigates, who notifies the practice, and how fast. Your 60-day patient notification clock does not pause while you chase a quiet vendor.

The enforcement climate explains the scrutiny. OCR closed 2025 with 21 settlements, the second-highest annual total on record, and IBM puts the average healthcare data breach at $7.42 million. Most practices cannot absorb that.

The ten marks of a genuinely compliant operation

Readiness shows up in specifics. A service that is actually running a compliant operation can be identified by these ten marks — and a service that is not will show a tell on the same list.

1. The BAA exists and names its terms. Permitted uses, subcontractor coverage, a notification window measured in hours, and end-of-contract destruction. The tell: a one-page template that never mentions what the vendor does.

2. The stack is nameable. Telephony, hosting, transcription — the service can say who touches PHI and where they operate. The tell: "we handle all of that internally."

3. Texting is set up deliberately. A BAA-covered messaging setup, opt-in recorded, message content kept minimal. The tell: "we use regular texting, it's fine."

4. Recording is built around consent rules. A written policy meeting the strictest state consent rule that applies to your callers. The tell: "we record for quality," with no consent answer.

5. Voicemail is scripted. Name and callback number only, unless the patient agreed to more. The tell: "the agent uses judgment."

6. Training is documented. On hire, refreshed on a schedule, with aggregate records. The tell: "our agents are experienced."

7. Access is limited and logged. Individual logins, least-privilege, logs available on request. The tell: "everyone here is trusted."

8. Breach notification is a number. Hours, not adjectives, written into the agreement. The tell: "immediately," with no number anywhere.

9. PHI has an exit plan. Certified return or destruction on a stated timeline when the contract ends. The tell: "deleted per our retention policy," with no timeline.

10. Compliance survives the signature. Annual reviews, access audits, a named compliance contact — treated as normal, not exceptional. The tell: the signing treated as the last compliance conversation that will ever happen.

These marks apply to live-agent services and AI vendors alike. A vendor confident in its operation can walk through all ten — so here is where ours stands.

Where Greetmate stands on the ten

• The BAA is part of the engagement. Greetmate is HIPAA-ready, with a BAA available. BAAs are sent and signed at the time of contracting, and what the agreement covers can be read in full.
• There is no agent pool reading your messages. The people-side risks above — training gaps, shared logins, an agent browsing a patient's history — do not exist in this model. The diligence shifts to systems: where conversation logs live, how long they are kept, and who on your team can see them, worked through during scoping.
• The stack can be named. Every deployment runs on a specific set of systems, and we walk through what yours uses and what depends on the practice's own systems — including dozens of EHR integrations — with the specifics confirmed during scoping.
• Escalation is designed, not improvised. Which calls route straight to a person on your team is part of the workflow, with timeouts and fallbacks tested before launch.
• Compliance visibility comes as reporting. Every workflow generates reporting on call activity, outcomes, and items that need staff action, so the ongoing picture is a report you read. The platform page shows what that looks like.

After the signature: what changes and what doesn't

A signed BAA is a snapshot, and vendors change. They add subcontractors, migrate platforms, get acquired, and swap telephony providers — usually without telling clients, because the average contract does not require them to.

The difference between vendors here is posture. A vendor that treats compliance as ongoing expects the relationship to include visibility: what changed in the stack, what the numbers look like, where things stalled. A vendor that treats the signature as the finish line leaves the practice to notice problems through patient complaints.

The blind spot in the traditional category is reporting: many answering services report little beyond a message count, so leadership cannot see what came in, what it produced, or where handoffs stalled. A service built with reporting in the workflow closes that gap on its own.

Frequently asked questions about HIPAA compliant answering services

Do I actually need a HIPAA compliant answering service?

If the service handles patient information on your behalf (names, appointment details, messages), yes. It is a business associate, and a BAA is required before it takes a single call. Even a service that only records names and callback numbers usually qualifies, because the context makes the information identifiable.

What does a HIPAA compliant answering service do differently?

Operationally, quite a lot: it signs BAAs up and down its chain, trains agents on PHI handling, limits who can see messages, scripts what gets left on voicemail, configures texting properly, puts a breach notification window in the contract, and destroys PHI when the contract ends. A vendor that describes compliance as a badge instead of those specifics is describing hope, not an operation.

Why are some AI answering services not HIPAA compliant?

Many consumer-grade voice tools were never built for patient information. The common failures: no BAA offered at all, call data used to improve models, no downstream agreements with the telephony, model, and storage providers, and transcripts stored without access controls. AI services can be compliant, but the burden of proof sits with the vendor. We go deeper in our review of HIPAA-compliant voice AI agents and our ranking of HIPAA-compliant voice AI receptionists.

If the answering service leaks patient information, who carries the liability?

Both sides can. The vendor is directly liable for its own violations, and the practice is liable for failing to vet and oversee it. The practice also owns the patient notification duty and the 60-day clock. That shared exposure is why the BAA and the subcontractor chain matter as much as the technology.

The responsibility stays with the practice

Everything above reduces to one fact: the phone stays the practice's responsibility no matter who answers it. The BAA, the subcontractor chain, the texting setup, and the access controls all exist because HIPAA holds the covered entity accountable for the vendors it chooses.

Greetmate approaches this space as healthcare voice and SMS infrastructure, delivered as a tech-enabled service: the team scopes each workflow, builds it, connects it to the systems the practice already runs, and tests it before go-live. Greetmate is HIPAA-ready, with a BAA available.

If you want to see where a deployment stands on each of the ten marks — the BAA, the stack, the storage, the escalation — book a demo and we'll walk through yours.