HIPAA, SOC 2, PCI — The Voice AI Compliance Checklist for Enterprise Procurement

The 6 frameworks every enterprise voice AI buyer must ask about

Most vendor security pages brag about a single badge — usually SOC 2 — and call it a day. Procurement teams running real reviews need six controls clarified on day one:

1. HIPAA — covered entities and business associates handling PHI on calls.
2. SOC 2 Type II — the operating-effectiveness report (not Type I, not the self-attested PDF).
3. PCI DSS v4.0.1 — anywhere a caller speaks or DTMF-keys a card number.
4. GDPR + UK GDPR — EU/UK callers, EU sub-processors, Article 28 DPAs.
5. Data residency — physical storage region for transcripts, recordings, embeddings.
6. Voice-specific risks — voiceprints, recording retention, training-data leakage.

If the vendor cannot answer all six in a single call, that is the answer. Skip the demo and move on.

HIPAA: BAAs, PHI in transcripts, model-training opt-out

Voice transcripts are PHI the moment a caller says their name plus a condition, medication, or appointment. Treat the transcript store, the embedding store, and the analytics warehouse all as PHI systems.

Minimum HIPAA bar for a voice AI vendor:

• Signed BAA with named sub-processors (LLM provider, ASR provider, TTS provider, telephony carrier, observability vendor). A BAA that excludes the LLM is not a BAA.
• Encryption in transit (TLS 1.2+, SRTP for media) and at rest (AES-256).
• Audit logs of every PHI access for 6 years.
• Zero-data-retention (ZDR) mode on the LLM call. OpenAI ZDR, Anthropic ZDR, and Google Vertex no-logging are all configurable — confirm which one is wired up for your tenant, not the marketing default.
• Model-training opt-out in writing. The vendor must contractually commit that your call audio, transcripts, and tool-call payloads are never used to train any model, theirs or a sub-processor's.

Example BAA clause to paste into the RFP:

"Vendor shall not, and shall ensure that each Subcontractor shall not, use Protected Health Information transmitted via the Voice AI Service to train, fine-tune, or evaluate any machine learning model, including but not limited to large language models, automatic speech recognition models, and text-to-speech models. Vendor shall configure all third-party model providers in a zero-data-retention or no-logging mode for Customer's tenant and shall provide written attestation of such configuration upon request."

If the vendor balks at that clause, they are storing your PHI in someone's training corpus.

SOC 2 Type II: what to verify beyond the badge

The SOC 2 badge on a footer means nothing. Demand the report itself under NDA and read the parts vendors hope you skip.

Checklist for the report:

• Type II, not Type I. Type I is a point-in-time design review. Type II covers 6–12 months of operating effectiveness. Anything less is theater.
• Trust Service Criteria covered. Security is mandatory. Availability, Confidentiality, and Processing Integrity should all be in scope for a voice AI platform handling live customer calls.
• Auditor. A real Big-4 or recognized CPA firm. Not a $5k mill-style auditor that issues clean reports as a feature.
• Exceptions section. Skip the cover letter. Go to the exceptions. Zero exceptions on a real Type II usually means the scope was drawn around nothing. One or two well-documented exceptions with remediation is normal and healthy.
• Sub-service organizations. Look for AWS, GCP, Azure listed as carve-outs with their own SOC 2s. If the LLM provider or telephony carrier is a sub-service org, their SOC 2 should be referenced too.
• Scope description. Confirm the voice AI product you are buying is named in scope. Vendors sometimes scope only the marketing site or the dashboard, not the inference path.

PCI DSS: how voice AI changes (or expands) your scope on payment calls

This is where most voice AI deployments quietly blow up the buyer's PCI scope. The instant a caller speaks 16 digits, the entire path — telephony carrier, ASR, LLM context window, transcript store, observability vendor — is inside the Cardholder Data Environment.

Two architectures, two very different audits:

The pause-and-resume / DTMF masking pattern (sometimes called "agent assist suppression") collapses your scope from "audit the universe" to "audit the integration."

Buyer questions:

• Is DTMF masking SBC-level or app-level? SBC-level keeps tones out of the media stream entirely.
• Does the ASR receive muted audio during the capture window, or just have its transcript redacted post hoc? Post-hoc redaction is not PCI-compliant — the data already touched the system.
• Does the vendor hold a current PCI DSS v4.0.1 AOC for the payment-capture component? Ask for the AOC, not a press release.
• Are call recordings of the payment segment stored, even encrypted? PCI requires they not be retained at all if they contain SAD post-authorization.

GDPR + EU residency: data location, sub-processors, DPA red flags

If any caller dials from the EU/UK, GDPR applies regardless of where your HQ is. The voice AI vendor is a processor (Article 28); your company is the controller.

DPA must specify:

• Named sub-processors with locations. "AWS" is not enough — "AWS eu-central-1" is.
• Standard Contractual Clauses (2021 modules) if any sub-processor is in the US, plus a Transfer Impact Assessment.
• Data residency guarantee in writing. "Best effort EU" is not residency. Look for a tenant-level region pin: audio, transcripts, embeddings, and vector indices all stay in eu-west-1 / eu-central-1 / eu-north-1.
• Deletion SLA. GDPR Article 17 deletion within 30 days, propagated to backups within the documented backup-rotation window.
• Sub-processor change notification with a real right of objection — 30 days minimum, not "we'll update the page."

Red flags in vendor DPAs:

• "Aggregated and anonymized data may be used to improve our services." Voice data is rarely truly anonymizable — voiceprints are biometric identifiers under GDPR Article 9. Strike this clause.
• US-only data center with "we comply with GDPR" but no SCCs and no TIA.
• Sub-processor list hidden behind a login or NDA. Article 28 requires it be available to you.

Voice-specific risks: recording retention, biometric voiceprints, training data leakage

The frameworks above were written for SaaS and payments. Voice AI adds three failure modes none of them fully cover:

1. Recording retention. Default retention on most platforms is 30–90 days, sometimes indefinite. Push for tenant-configurable retention down to 0 days (transcript only, no audio) and confirm hard deletion, not soft-delete flags.

2. Biometric voiceprints. Some platforms compute speaker embeddings (a 192-dim vector that uniquely identifies a voice) for diarization or fraud detection. Under GDPR Article 9, BIPA (Illinois), and Texas CUBI, that vector is biometric data with consent requirements that exceed normal PII. Ask: are voiceprints generated, where stored, can they be disabled per-tenant?

3. Training-data leakage. Even with a model-training opt-out, vendors sometimes use redacted transcripts to evaluate model performance or build eval sets. "Evaluation" can be a loophole. Make the clause cover any downstream model use, including evals and prompt-optimization datasets.

The downloadable RFP questionnaire (15 questions)

Paste these into your vendor questionnaire. Yes/no answers force the vendor to commit on paper.

1. Will you sign a HIPAA BAA covering all sub-processors including the LLM, ASR, and TTS providers?
2. Do you operate the LLM in a zero-data-retention / no-logging mode for our tenant by default?
3. Will you contractually commit that our audio, transcripts, and tool-call payloads are never used for model training, fine-tuning, or evaluation?
4. Provide your most recent SOC 2 Type II report under NDA. Which Trust Service Criteria are in scope?
5. Is the voice AI inference path explicitly named in the SOC 2 scope description?
6. List all exceptions in the most recent SOC 2 Type II and the remediation status of each.
7. Provide your current PCI DSS v4.0.1 AOC. Which component is certified?
8. How is payment card data captured — SBC-level DTMF suppression, app-level masking, or post-hoc redaction?
9. Are call recordings of payment segments retained in any form? If so, where and for how long?
10. Provide a sub-processor list with physical data center regions for each.
11. Can audio, transcripts, embeddings, and vector indices be pinned to an EU region at the tenant level?
12. What is your GDPR Article 17 deletion SLA, including backup propagation?
13. Do you generate speaker embeddings / voiceprints? Can they be disabled per-tenant?
14. What is the minimum configurable call-recording retention period? Can it be set to zero?
15. Provide a recent third-party penetration test summary (within the last 12 months) covering the voice inference path.

If a vendor cannot answer all 15 in writing within a week, they have not done the work yet — and you are paying to be their compliance R&D project.

Internal link suggestions

• Link "unit economics of a non-compliant deployment" → The Voice AI Latency Tax
• Link "infrastructure cost of voice AI failure" → The Cost of Downtime: Voice AI Infrastructure
• Link "SBC-level capture" → Bypassing the IVR Queue Tax with SBC-Level Voice Agents
• Link "cross-border data paths" → Cross-Border SIP Latency
• Link "PBX migration risk" → Beyond 3CX: Network Engineering for AI Voice

FAQ

Is HIPAA enough for a healthcare voice AI deployment? No. HIPAA is necessary, not sufficient. You also need SOC 2 Type II for the platform controls, a current pen test for the inference path, and state-level biometric coverage (BIPA, CUBI, Washington My Health My Data) if you generate voiceprints.

Does a SOC 2 Type II report mean the vendor is GDPR-compliant? No. SOC 2 covers operating effectiveness of internal controls. GDPR is a legal regime requiring a DPA, named sub-processors, SCCs for transfers, and data subject rights. A vendor needs both, and the two reports cover different surfaces.

Can a voice AI vendor reduce my PCI scope to zero? Close to it, not exactly zero. A vendor with SBC-level DTMF suppression and a Level 1 PCI AOC for the payment-capture component reduces you to SAQ A or SAQ A-EP territory in most card-present-by-phone deployments. You still own the integration and the call routing decision.

What is zero-data-retention (ZDR) mode and why does it matter? ZDR is a tenant-level configuration on the LLM provider that disables logging of prompts and completions. Without it, your call transcripts sit in the LLM provider's logs for 30 days minimum, which breaks both BAA and DPA commitments downstream.

FAQ JSON-LD: render this section as Question + Answer schema.org entities for the FAQPage type so the SERP gets the rich result. Standard Next.js MDX FAQ component on the blog already handles this — wrap the section in <FAQ> and the layout emits the JSON-LD.

CTA

Vetting a voice AI vendor and tired of marketing-grade security pages? Finn ships with a signed BAA, SOC 2 Type II in scope for the inference path, SBC-level DTMF suppression for PCI, and tenant-level EU residency on day one. Send us the 15-question questionnaire above — we answer in 48 hours, in writing, with the receipts. Book a procurement-grade security review →

Reviewer: Human board / AGNB content owner. Do not publish until reviewed — publish step is currently manual.