The healthcare buyer's checklist for a phone system that signs a BAA

Introduction

Every phone system vendor targeting healthcare will tell you they're HIPAA-compliant. Very few of them will tell you what that means in terms of their architecture, their BAA, or what happens when something goes wrong. This checklist is designed to cut through the marketing and surface the questions that matter for procurement — the ones that determine whether you'll sail through your next OCR audit or scramble to explain a gap you didn't know existed.

1. Will they sign a Business Associate Agreement?

This is the baseline. A BAA is required under HIPAA for any vendor that handles Protected Health Information (PHI) on your behalf. 'HIPAA-compliant' without a signed BAA is meaningless — the compliance only applies to covered entities and their business associates, and the association requires a signed agreement.

Ask the vendor: can you provide a BAA before we sign the service contract, not after? Review it before you commit. Key items to check: does it define PHI consistently with HIPAA's definition? Does it describe the vendor's obligation to notify you of a breach within 60 days? Does it specify how PHI is destroyed or returned at contract end?

2. Where are call recordings stored, and for how long?

Call recordings in a healthcare context frequently contain PHI: patient names, dates of birth, symptom descriptions, appointment details. Ask specifically:

• Are recordings stored in a region with data residency controls, or in a global pool?
• What encryption standard is used at rest and in transit? (AES-256 at rest and TLS 1.2+ in transit are the current minimum expectations.)
• What is the default retention period, and can you set a shorter one?
• Who in the vendor organisation can access recordings, and under what conditions?
• Are access logs maintained, and are they available to you for audit purposes?

3. How are voicemail transcripts handled?

Voicemail transcription is a common HIPAA gap. If a vendor transcribes voicemails using a third-party ASR model, that model is likely a sub-processor — and the vendor's BAA should explicitly cover sub-processors and their obligations. Ask: which vendors process your transcription, are they HIPAA-trained, and are they listed in the vendor's sub-processor registry?

Also check whether transcripts are stored separately from recordings, and whether they can be purged independently if a patient requests deletion under applicable state privacy laws.

4. What does the audit trail actually cover?

HIPAA's technical safeguards require audit controls that record and examine activity in information systems containing PHI. For a phone system, that means logs of who accessed recordings, when, and from where. Ask for a sample audit log before you sign — it should include user ID, timestamp, action type, and the resource accessed. Logs that only cover login events and not resource-level access are not sufficient.

Also confirm that audit logs are tamper-evident. A log that can be modified by an admin is not a reliable audit trail. Look for logs that are written to an immutable store and are available for export to your SIEM or audit system.

5. What is the breach notification process?

HIPAA requires notification of a breach involving PHI within 60 days of discovery. Ask the vendor: how do you define a breach, and how will you notify us? The answer should include a defined notification timeline shorter than 60 days (most good vendors commit to 48-72 hours of discovery), a named point of contact for security incidents, and a description of the forensic process that determines whether a breach involved PHI.

A vendor that cannot describe their breach notification process with specifics has not run a tabletop exercise on it. That is itself a risk indicator.

6. Does the AI layer touch PHI, and how?

AI features — transcription, sentiment analysis, AI receptionist — increasingly sit in the processing path of calls that contain PHI. Ask: are these features built on first-party models, or do calls get sent to a third-party LLM API? If it's a third-party API, is that provider listed as a sub-processor in the BAA? Is the data sent for AI processing anonymised before it leaves your tenant?

Conclusion

This is the fastest-moving compliance gap in the market right now. Vendors who added AI features quickly may not have updated their BAA or their sub-processor registry to reflect where patient call data is now going.

The procurement checklist

• BAA available before contract signing — not after, not on request
• BAA covers all sub-processors explicitly
• Call recordings encrypted at rest (AES-256) and in transit (TLS 1.2+)
• Recordings stored in a defined region with access controls
• Audit logs capture resource-level access, not just logins
• Audit logs are tamper-evident and exportable
• Voicemail transcription sub-processors are named and BAA-covered
• Breach notification commitment is specific and shorter than 60 days
• AI features document how they handle PHI in the processing path
• Data destruction or return process is defined in the BAA