What Happens When Your AI Call Vendor Fails a Compliance Audit (And How to Protect Yourself First)

Introduction

It’s a Tuesday. You receive an e-mail from the AI call vendor’s account team. Phrasing is carefully done. They returned their last SOC 2 Type II with a qualified opinion. Or: they are making the required notification, as per the law, about a security incident that impacted customer data processed by them. Or: An attorney for a plaintiff firm has named them and a list of their customers in a TCPA class action involving calls placed on their behalf.

In the next hour, it’s not a question of whether the vendor is in trouble. It’s “what fell on me.

This is the principle that this whole page is based on and most compliance content doesn’t really say it outright: the calling can be outsourced. No liability can be passed on. A covered entity is still responsible following a business associate’s HIPAA violation. It’s not just the dialer that has TCPA exposure, it’s the company calling on their behalf. Under GDPR, the data controller remains liable in the event of the processor’s failure. Your acquirer relationship is included in scope if your payment touching vendor fails PCI.

This guide is for the owners of that exposure: the CISO that is putting the controls in place, the Compliance Officer that is being asked by the other regulator’s Compliance Officer, the Procurement individual who is signing the contract, the General Counsel who is reading the indemnity clause, the IT Director who is owning continuity, and the Business Owner / CEO who is making the risk adjusted call.

What you’ll get by the end: A clear understanding of what an audit failure means to you, and the due-diligence and contract checklist you can do ahead of the audit that will make the Tuesday email a less threatening experience or a life-threatening one.

The Principle That Changes Everything: Liability Doesn’t Transfer

If you hire someone to do or answer calls, you outsource them to that person. You are not delegated the responsibility by regulators.

In the eyes of the law, the customer relationship and the duty that entails was always yours – and so was the regulator’s first call after the collapse of your vendor.

This is no excuse not to patronize vendors. That’s why this page exists: because pre-failure work determines how this will play out.

PRO TIP

When a supplier tells you that they are “fully compliant,” make sure that they can demonstrate compliance according to YOUR specific regulatory requirements and not just a certification badge.

What an AI Call Vendor “Failing an Audit” Actually Means

There is no such thing as “failed an audit. The mechanics are different and so are the things you need to do.

1. SOC 2; Qualified vs adverse opinion (and the exceptions section nobody reads)

A SOC 2 Type II opinion is a CPA firm’s opinion. In an unqualified opinion, controls were effective during the period. According to a qualified opinion, they largely did, but there were some exceptions. If they didn’t, an adverse opinion is issued. The most important part, which is often overlooked by buyers, is the testing-exceptions detail. If there are exceptions that are directly related to your risk, a “clean” cover letter can be placed on top of that. Ignore the exceptions rather than the opinion paragraph.

2. HIPAA; A business associate breach and the timeline it triggers for YOU

If your vendor is an AI vendor, and they have a breach of PHI, the clock and obligations for breach notification start with you. Your duties for providing notification to individuals, HHS, and possibly the media for a covered entity are covered by the Breach Notification Rule. The regulatory duty is not eliminated by the BAA’s indemnity.

3. TCPA; The class-action mechanics and the per-call math

Statutory damages are per call/text for TCPA violations. That’s what class actions do – they combine that on a large enough number of calls to make it into the news. The doctrine of liability is usually imposed on the party who made the calls. Quotes actual settlement ranges from a credible enforcement tracking source (don’t quote a number out of your head).

4. PCI DSS; What a vendor’s failed assessment does to your scope

Your PCI scope and acquirer relationship are impacted if a payment touching vendor’s Attestation/Report on Compliance lapses or fails. You might be required to re-scope, re-attest or remediate at a time you can’t control.

5. GDPR; A processor’s failure and your controller obligations

Your Article 33 controller assessment and obligatory 72-hour notification to your supervisory authority are triggered by a processor breach. Under Article 82, joint and several liability is permitted. If the processor fails, the controller clock doesn’t stop.

6. The vendor goes dark: suspended, sanctioned, insolvent

The situation that no one wants to have: The vendor gets sanctioned, falls out of a crucial certification, or goes bankrupt, and your calling operation and data are still in their environment. This is not just a compliance issue, it’s a continuity issue.

NOTE

A “qualified” SOC 2 opinion does not mean immediate doomsday. It’s what’s actually behind the qualified opinion that matters.

What Lands on You, and When

The pattern: each row carries a clock, most of them are shorter than the time it takes to deal with a vendor who just hung up. The pre-failure work is important because of the clocks.

PRO TIP

TCPA Reality Check: An affordable vendor agreement may expose your organization to seven figures if outgoing consent management is not set up correctly.

The Shared-Responsibility Reality; What’s Theirs vs What’s Yours

The costliest miscommunication with a vendor is when you think it’s your problem if it doesn’t comply.

The unassigned-gap row is where buyers get hurt: integration and subprocessor failures are not always in buyers’ clear column; they only show up when something goes wrong. Assign them prior to go-live in the contract.

The Contractual Protections That Actually Matter (and the One That Doesn’t)

The one that seems like a good idea but is rarely a good one: the standard indemnity with a cap on trailing fees. But that can be a rounding error against an aggregated TCPA or breach exposure. If the contract is not to be considered “protected,” counsel should establish the actual exposure at a cost, prior to the contract’s consideration.

Pre-Failure Due Diligence; The Evidence to Demand Before You Sign

The Tuesday email is OK to survive, depending on the amount collected prior to signing.

The 10 question vendor due diligence checklist:

1. Share your latest SOC 2 Type II and is it within a year (with the exception section intact)?
2. Fill in the letter to bridge the gap between the end of the reporting period and today.
3. Submit a summary and remediation evidence from the latest penetration test.
4. Jurisdictional your current, named subprocessor inventory (LLM, transcription, telephony, cloud).
5. Submit your Cyber Insurance certificate and limits.
6. Include your breach notification SLA (in hours) in the contract.
7. Give your BAA (if PHI is in scope) and your DPA (if personal data is in scope).
8. Demonstrate data export format and exit assistance.
9. Demonstrate financial viability supporting evidence (a vendor unable to withstand a fine is a continuity risk).
10. Agree to check public enforcement records (such as the HHS Breach Portal) and discuss any that may be found.

If a vendor doesn’t buy into items 1 4 and 9, the Tuesday email is going the way it will.

A word about Botphonic: this page makes the request that you ask any vendor, including us, for the above. If a vendor, such as Botphonic, doesn’t provide its own SOC 2, subprocessor list and insurance, this page’s logic says don’t sign. We would prefer you held us to the standard outlined in the page.

The AI Vendor Risks Most Support Teams Never Audit

• AI model governance: What is the basis of the product’s foundation model? How are updates to the models communicated? How do you update your call behavior given the retraining of the underlying model? These questions are not included in most security questionnaires but they should be.
• Subprocessor depth: Your vendor’s LLM provider could be able to have their own subprocessors. Request the entire chain, not just the first level of the chain. The NIST SP 800-161 supply-chain risk mapping and evaluation methodology offers a framework for modeling and assessing multiple tiered vendor relationships.
• Regulatory change monitoring: Compliance is always a moving target – the consent rules under the TCPA continue to evolve, state privacy laws are evolving, the CFPB’s guidance on AI continues to evolve, and the sector-specific AI regulations are evolving. Inquire if the vendor has a formal mechanism for monitoring changes in regulatory requirements and providing information on the product impact to the customers.
• Incident response testing: Ask if the vendor has performed some sort of tabletop exercise in which they simulate a data breach. When a real event happens, a vendor who has never gone through a rehearsal will take longer and be more chaotic to get to your notification deadlines.

Your Role in the Vendor Failure: A Section for Each Stakeholder

We will create a section in the Vendor Failure for each stakeholder to outline their roles.A section of the Vendor Failure will be created for each stakeholder, detailing their roles.

1. CISO

When the e-mail is received, your task is not to identify blame, but rather to conduct a control-gap assessment. Identify the real impact of the vendor’s SOC 2 exception on your control environment: is a compensating control in your environment impacted by the vendor’s exception? Do you have logs being ingested into your SIEM? Have a means to monitor unauthorized access to data stored in their environment? The answer to “are we affected” must be from your own telemetry and not their reassurances.

Pre-failure: These are all things to have in place before failure; Keep a cadence to provide evidence, put the status of the vendor in your risk register and have a vendor failure scenario in your IR playbook.

2. Compliance Officer

After Tuesday’s email you’ll get the first call from the business. The questions that are on your mind: Do we need to inform anyone? How quickly? Who? In order to determine the answers, it is necessary to identify which regulation applies as we have done. Pre-failure: Make sure that all vendors are connected to the regulatory requirements that affect them and that your notification process is exercised before it’s needed.

3. General Counsel

Use the realistic exposure, not the premium paid, to read the indemnification cap. Show the math used per call. Consider the subprocessor clause — if it doesn’t exist, then there is a gap. Ensure that breach-notification SLAs in the contract are specific to being compliant with your regulatory deadlines. Pre-failure: remove regulatory fines and willful misconduct from any cap on aggregate.

4. Procurement / Vendor Management

The best time to use leverage is prior to signing the contract. Any vendor that fails to provide a bridge letter and exceptions, or a named subprocessor list is not compliant by default, it is unverified. Keep a written record of due diligence. Your paper trail is important if you have a problem later on.

5. IT Director

The column is you, Continuity. The vendor goes dark scenario is an IT problem, rather than a compliance problem. Pre-failure: make sure data export is not only promised, but actually tested; create the failover playbook; ensure SLAs for data return in case of vendor insolvency; don’t rely on the vendor’s configuration interface to document call configuration.

6. Business Owner / CEO

You have the right idea and are taking a calculated risk. A vendor relationship incurs significant compliance costs, and a failed vendor creates ongoing liability costs. This math typically favors rigorous vendor selection processes and strict contract terms over quicker deals. See our real-world case study on AI call performance for the business case, and our AI receptionist implementation guide for how a compliant deployment is actually structured.

Implementing a Compliant AI Call Deployment: The Operational Checklist

It’s not a contract provision: it’s an operational stance. Follow these steps from contract signing through go-live and into the ongoing process.

Pre-deployment:

• Conduct due diligence on vendors.
• Implement BAA (HIPAA) and/or DPA (GDPR) prior to data transfer.
• Identify regulatory requirements for given use case (inbound, outbound, healthcare, financial, etc.)
• Confirm that you set up the system to capture consent and suppress the list.
• Don’t take a word for word commitment for portability, as it is part of the test data export process.

Deployment:

• Record all the call script settings and keep track of version control.
• Log all subprocessor connections and data flows
• Set up call recordings, transcripts and access events audit logging.
• Develop internal escalation plan for incidents (who to call when)

Ongoing:

• Quarterly: check vendor’s compliance status, request new bridge letter when it is close to the annual renewal date for SOC 2
• Annual: Redo all DD questions; Reconfirm subprocessor list; Reconfirm insurance policy
• On regulatory change: Evaluate if vendor’s product continues to meet new rule requirements
• Start your own checklist as soon as you receive a vendor incident notice, rather than waiting for their post-incident report.

Our step-by-step AI receptionist implementation guide maps this operational checklist to a deployment timeline, with documentation templates for each stage.

Sector-Specific Risk Profiles

Healthcare

In healthcare, AI voice agents interact with PHI in numerous ways: Scheduling appointments, taking patient information, verifying insurance coverage, and following up. All of those touchpoints should include a BAA, encryption at rest and in transit, and audit logging. The minimum necessary rule also extends to the amount of PHI your AI vendor handles — and the amount of PHI that your AI vendor’s subprocessor handles.

The HHS OCR has increasingly pursued covered entities for inadequate business associate oversight, not just for direct violations. If you sign a BAA with a vendor and never audit their controls, that’s not a defense it’s a gap.

More on healthcare-specific AI call compliance: HIPAA-Compliant AI Voice Assistant for Healthcare.

Financial Services

Regulated investment advisers and brokers also have to comply with the full FINRA/SEC rules around records in addition to state privacy laws. The system also applies supervisory controls to all AI calls. In cases where the voice is not a person’s but belongs to AI, nothing changes about the suitability requirement and disclosures.

Moreover, the CFPB has been emphasizing the usage of AI in consumer financial services like debt collection, lending, and servicing call centers. Ensure that your vendor provides something testable. Do not rely solely on assumptions regarding unacceptable language like debt collection disclosures, Reg Z language, etc.

More on financial services AI compliance : AI Receptionist Software for Financial Advisors.

Agencies and High-Volume Outbound Callers

Call centers handling multi-customer communications face a two-fold TCPA risk: they must obtain proper consent and defend against joint TCPA lawsuits with their customers. The script is important. The consent method is important. The frequency of the DNC list scrubbing is important. None of the above is a feature provided out-of-the-box by the vendor; it’s a configuration by the agency.

See: TCPA-focused script examples and agency call frameworks.

What “Vendor Risk Management” Actually Looks Like in Practice

Vendors’ risk program frameworks are built on procurement – a questionnaire at sign-up, a certificate request at renewal, and some hope in between. That’s not vendor risk management. That’s vendor risk theater.

Real vendor risk management (VRM) comprises three tiers:

1. Intake diligence:The best time to make your move is pre-contract. Use an evaluated matrix to score. Keep a record of your rationale and proof points.

2. Monitoring: Compliance posture is constantly evolving since companies publish reports on a yearly basis. Bridge letters, interim certification, public enforcement actions, news media reporting, and customer community forums offer valuable cues for tracking performance over time. Establish a timeline: quarterly check-in with compliance teams of your vendors. Repeat annual questionnaire.

3. Readiness plans for vendor failure incidents: It is impossible to prepare the response plan once the fire is burning. Plan ahead for vendor failure scenarios including designation of incident manager, activation of legal and public relations response plans, customer notification, et cetera. Test the playbooks via a regular table top exercise.

The NIST AI Risk Management Framework provides the governance backbone for all three layers. Its Govern, Map, Measure, and Manage functions map cleanly to intake, monitoring, assessment, and response.

Performance vs. Compliance: A False Trade-Off

In procurement conversations, critics argue that rigorous compliance delays vendor selection and limits vendor choices. In some cases, this may indeed happen. But not in most, and certainly not in any instance where it makes sense.

The case study from Botphonic on using AI to increase call performance saw a 40 percent improvement in response rates via AI-powered outreach, but this came in the context of a project where compliance measures were applied to every single step. Compliance and performance need not be mutually exclusive; a vendor that cannot provide proof of their compliance efforts is likely one with poor process maturity and low performance.

The vendors who are good at compliance will generally excel at documentation, log management, incident response, and continuity management as well.

PRO TIP

Companies that maintain well-disciplined compliance programs typically have better reliability and maturity in handling incidents.

A Note on Applying This Framework to Any Vendor, Including Botphonic

This page asks you to apply this standard to every AI call vendor you evaluate, including us.

If Botphonic can’t produce our current SOC 2 with exceptions intact, a bridge letter, a named subprocessor list, and a cyber insurance certificate, then by the logic of this page, you shouldn’t sign. We’d rather you held us to that standard than extended us a trust we hadn’t earned in documentation.

Want to see how we measure up?

• View our pricing – what compliance-grade infrastructure actually costs

Key Regulatory References

The Work Was Done Before Tuesday

The problem isn’t on Tuesday, when you receive the qualified audit report, get breached, and end up facing a class action lawsuit. It happened in the contract you did not stress-test, the exceptions to the SOC 2 report you didn’t take time to read, and the list of subprocessors you never bothered to ask for.

The fundamental concept that underlies all sections of this guide is quite straightforward. The responsibility for the phone call can be outsourced; the liability cannot. Breach notification period, per-call TCPA calculation, GDPR 72-hour limit none of them cares which company actually messed up. It follows you.

And the best news: any worthwhile vendor should be able to answer every question from the checklist without breaking a sweat. That is the kind of company who will provide their SOC 2 in its entirety, including exceptions, provide you with the list of subprocessors, and assign an exact hour to their breach SLA.