What a security review actually asks of a voice-AI vendor.

When you sell an AI agent into a business bigger than a few dozen people, at some point the buyer stops being the person who loved the demo and starts being their security team. What arrives is a spreadsheet — sometimes a hundred rows, sometimes a formal SIG or CAIQ — asking how you handle their data. Answer it well and the deal moves. Hedge on the wrong row and it sits in procurement until it dies.

The questions are more predictable than they look. Across the reviews we've been through, they cluster into seven areas. If you're a vendor, this is the readiness checklist. If you're a partner deploying agents under your own brand, this is what your enterprise client's security team is going to ask you — so it's what you need your infrastructure to already be true of.

1. Encryption: at rest and in transit

The opening question, almost always: how is our data encrypted? The expected answer is AES-256 for data at rest and TLS 1.3 in transit — not because those specific numbers are magic, but because they're the current table stakes and anything vaguer reads as "we haven't thought about it." For a voice agent there's a second half most vendors forget: call recordings and transcripts are data too. They cannot sit in an object store in the clear. Keys have to be managed and rotated, and you should be able to say where.

2. Access control: who can touch what

Next: who inside your company can access our data, and how is that controlled? The answer they want is role-based access control — permissions scoped per team, per agent, per integration — not "all our engineers can see everything." For anything above mid-market, expect a follow-up on identity: SSO via SAML, and SCIM provisioning so that when they deprovision an employee in their directory, that access disappears on your side too. If you can't federate identity, you'll be doing manual user management for their whole org, and they know it.

3. Audit trail: can you prove who did what

Then: can you show us a record of every access and change? A complete, exportable audit log — who accessed which conversation, who changed which agent config, when — is the difference between "we think it's fine" and "here's the evidence." The mature version of this answer is that the log can be pulled on demand and streamed into their SIEM, so their own security tooling sees your events alongside everything else. Buyers with a real SOC will ask for exactly that.

4. Data residency and retention

Two questions that travel together: where does our data physically live, and how long do you keep it? Region controls matter the moment a client has EU customers or a public-sector requirement — "it's somewhere in us-east" is not an answer that clears GDPR. Retention is the other half: they want to configure how long recordings and transcripts are kept, delete on a schedule, and delete on request. A vendor that keeps everything forever by default is a liability the buyer inherits.

5. The paperwork: MSA, DPA, and BAA

This is the row that quietly kills more deals than any technical control, because it can't be fixed on a call. Enterprises need a signed Master Service Agreement, a Data Processing Agreement that names them as controller and you as processor, and — if there's any healthcare data in the conversation — a Business Associate Agreement. No BAA means no HIPAA-regulated client, full stop. If your answer to "can you sign a DPA?" is "let me check with legal," you've just added three weeks. The ready answer is "yes, here's our template, and we'll paper yours."

6. Subprocessors and the model question

A voice agent is a chain of vendors — speech-to-text, the language model, telephony — and a good security team asks about all of them: who are your subprocessors, and what data do they see? This is where the AI-specific anxiety shows up. If your agent's brain is somebody else's API, then their customer conversations are flowing to a third party, and that third party is now in scope for the review. The cleanest answer is the shortest subprocessor list you can honestly give. Running the model on your own in-house infrastructure — rather than routing every call to an external API — is the difference between "one more vendor to vet" and "an open question the buyer has to escalate."

7. Resilience: what happens at 2am

The last cluster is availability: what's your uptime commitment, and what happens when something upstream breaks? They want an SLA with a number on it (99.9%+ is expected; 99.99% is a differentiator), multi-region failover, and a real answer to the outage question. For voice specifically, "the phone line went dead during a customer call" is a worse failure than a dashboard being slow. If a model provider has an outage day and your agents go silent with it, that's a dependency the buyer is now underwriting. Redundancy at every layer — model, hosting, telephony — is what turns this row from a risk into a selling point.

The simple version

Before you chase your first enterprise logo, walk your own stack against those seven and see which ones make you hesitate. The hesitation is the gap. Encryption and access control are usually fine; it's the DPA/BAA paperwork, the subprocessor list, and the outage story that catch vendors flat-footed — and every one of those is easier to have ready in advance than to scramble for while a $200k deal cools in procurement.

This is also why "the platform plus the people" matters for security, not just delivery: passing a review isn't a one-time PDF, it's answering follow-ups, papering agreements, and standing behind an SLA at 2am. We built Callibre so that a partner closing an enterprise client isn't the one who has to become a compliance department overnight — the controls, the contracts, and the resilience are already underneath the brand they're selling.