The Vendor Security Questionnaire: 45 Questions Regulated Buyers Should Ask Any CCaaS Provider

Most security questionnaires arriving at a contact center vendor were written for generic software. They ask about encryption at rest and password policies, then stop. Fine as far as it goes, and it misses nearly everything that makes this category risky.

What follows is built for the specific thing you’re buying.

Why Generic Questionnaires Miss CCaaS Risk

A standard vendor assessment assumes a system that stores structured records behind a login. Contact center platforms do considerably more than that, and each additional capability introduces exposure a general template never asks about.

What These Platforms Touch That Other Software Doesn’t

• Voice recordings, which frequently contain payment details, identity documents read aloud, and health information disclosed in passing
• Live audio streams routed through carriers you have no contract with
• Transcripts and derived analytics, often stored separately from the recordings themselves and retained under different rules
• Telephone numbers registered to your business, carrying regulatory obligations that follow the number
• Agent desktops with access to your CRM, billing systems and customer records
• Third-party AI models, which may process conversation content outside the platform boundary

Notice how many of those sit outside the primary database. That’s the pattern: risk in this category clusters in peripheral systems, and peripheral systems are exactly what a generic template fails to name.

There’s a second structural difference worth holding onto. Most software processes data your organization already collected deliberately. A contact center platform captures information customers volunteer in the moment, unprompted and unpredictably, which means you cannot fully control what ends up in a recording. Somebody reads out a card number before the agent can stop them, or mentions a medical condition to explain a complaint. Your controls have to assume that sensitive content will arrive without warning, and that assumption shapes almost every question below.

How to Use These Questions

Evidence Beats Assertion

Any competent sales team answers yes to a yes-or-no question. The useful version asks for the artifact: the report, the certificate, the policy document, the test result with a date on it.

Rewrite each question below as a request for evidence wherever the answer matters. “Are you SOC 2 compliant?” invites a yes. “Please provide your most recent SOC 2 Type II report, including the observation period and any exceptions noted” invites a document, and the absence of that document is itself informative.

Worth understanding the distinction before you ask: a Type I report describes whether controls were suitably designed at a point in time, while a Type II examines whether they operated effectively across a period. Vendors sometimes present the first when a buyer assumed the second.

Scale the Depth to the Data

Forty-five questions is proportionate for a bank, an insurer, a healthcare provider or a government-adjacent operation. It is disproportionate for a small retail deployment handling order queries.

Segment by what the platform will actually touch. Where payment details never enter a conversation, the cardholder questions matter less. Where recordings capture identity documents being read aloud, the retention questions matter enormously.

Who Should Own the Assessment

Procurement usually runs it, which is reasonable, though the answers need reading by somebody who understands both security and telephony. Those two skill sets rarely sit in one person.

TabaTalk recommends having your security team own sections C through F below, while procurement handles commercial and governance items. Splitting it that way produces better follow-up questions than routing everything through one reviewer who is guessing at half of it.

Section A: Company, Governance and Certification

1. What is your company’s legal name, headquarters location, and corporate structure including parent entities?
2. Which certifications do you currently hold, and can you provide the full reports rather than summary letters?
3. What is the observation period of your most recent SOC 2 Type II report, and what exceptions were noted?
4. Is your ISO 27001 certification scoped to the specific service we would use, or to a subset of your operations?
5. Who is accountable for your security program, and to whom do they report?
6. How often is your risk assessment refreshed, and what triggers an off-cycle review?
7. Which subprocessors handle our data, and how are we notified when that list changes?
8. What is your policy on background checks for staff with production access?

Question four catches more vendors than any other in this section. Certification scope is frequently narrower than the marketing implies, covering a data center, a legacy product line, or a corporate function rather than the platform being sold to you.

Question seven deserves a follow-up too. A subprocessor list is only useful if it comes with a notification mechanism, and “we will update our website” is not a notification mechanism. Ask for written notice with a defined period before a new subprocessor begins processing, and the right to object. Vendors serving regulated buyers already have this clause drafted; those who don’t will tell you it’s unusual, which it isn’t.

Section B: Data Handling, Residency and Retention

1. Where is customer data physically stored, by data type?
2. Do backups, archives and analytics stores follow the same residency commitment as the primary environment?
3. Can residency be specified per account, or only at platform level?
4. Under what circumstances would data leave the specified region, including for support access?
5. What is the default retention period for recordings, transcripts and metadata, and can each be configured separately?
6. How is data encrypted in transit and at rest, and who holds the keys?
7. Can we supply our own encryption keys, and what happens operationally if we revoke them?
8. What is your documented process for deletion requests, and how is completion evidenced?
9. How do you handle data subject access requests that involve voice recordings?

Question ten is the one I’d most want answered in writing. Residency commitments are frequently made against the primary database while backups, recording archives and analytics warehouses sit elsewhere by default, and nobody discovers this until an audit.

The UAE has its own considerations here, since regulated sectors increasingly specify residency in contract. Confirm the commitment covers every store rather than the one somebody thought of first.

Question twelve is the companion nobody asks. Support access routinely crosses borders even where storage does not: an engineer in another region opens a session to investigate a fault and views data that has technically never left the country while being read by somebody who has. Whether that constitutes a transfer under your obligations is a question for your legal team, but you cannot ask it until you know the support model.

Section C: Access Control and Tenant Isolation

1. Describe the logical separation between your customers’ environments.
2. Can your staff access our environment, under what conditions, and is that access logged and visible to us?
3. How is administrative access to production controlled, and is multi-factor authentication enforced without exception?
4. Can permissions be scoped so that supervisors see multiple teams while agents see only their own?
5. How quickly can access be revoked when an employee leaves, on your side and on ours?
6. Do you support single sign-on and directory integration, and at what cost?
7. Can we receive audit logs of access to our data in a format our SIEM can consume?
8. How is separation tested, by whom, and how often?

Questions eighteen and twenty-five have an authoritative reference point where payment data is involved. The PCI Security Standards Council applies Appendix A1, its additional requirements for multi-tenant service providers, to providers offering shared services to merchants and other service providers (PCI Security Standards Council).

Summarizing the version 4.0 requirements, law firm Davis Wright Tremaine notes that multi-tenant providers must implement logical separation preventing unauthorized access in both directions, ensure each customer can reach only its own cardholder data and allocated resources, confirm the effectiveness of those separation controls every six months through penetration testing, supply audit logging to customers, and maintain processes for customer-reported incidents (Davis Wright Tremaine).

That gives you a specific, checkable question: ask for the date and scope of the most recent separation penetration test. Note the useful asymmetry as well, since the same guidance states these particular requirements do not apply where servers are dedicated to a single customer, while everything else in the standard still does. Our comparison of multi-tenant and single-tenant architecture covers why the answer differs by deployment model.

Section D: Voice, Recording and Telephony Risk

1. How are recordings stored, encrypted and access-controlled, and who can download them?
2. Can recording be paused automatically during payment capture, and how is that triggered?
3. Are dual-tone signals suppressed so card digits never enter the recording or the transcript?
4. Which carriers route our traffic, and what contractual security obligations do they carry?
5. Do you support bringing our own carrier, and does that change your security responsibilities?
6. How are telephone numbers provisioned, and whose regulatory registration do they sit under?
7. What controls prevent recordings being exported in bulk?
8. How is call quality monitoring performed, and does it involve staff listening to recordings?

Twenty-eight is the question that separates vendors built for regulated buyers from those that aren’t. Suppressing keypad tones during payment entry is a specific engineering capability rather than a policy commitment, and the answer is usually either a clear technical description or a visible evasion.

Twenty-nine and thirty pair usefully. Where a provider routes through carriers you have no relationship with, their security obligations reach you only through the vendor’s own contracts, which you will not see. Bringing your own carrier moves part of that exposure back under arrangements you control, at the cost of taking on responsibility for it.

Thirty-one carries regional weight. UAE Cabinet Resolution No. 56 of 2024 requires prior regulatory approval for telemarketing activity, restricts calling hours, and obliges businesses to disclose the source of their customer database on request (UAE Legislation portal; Morgan Lewis). Where numbers must sit under the licence of the business conducting the activity, provisioning arrangements matter for compliance rather than only for convenience. TabaTalk’s guide to outbound compliance covers the obligations.

Section E: AI, Analytics and Model Handling

1. Which AI capabilities process our conversation content, and are any of them third-party services?
2. Is our data used to train models, ours or anybody else’s, and can we opt out contractually?
3. Where does inference happen, and does conversation content leave the residency region for processing?
4. How long are transcripts and derived analytics retained, and does deletion of a recording delete them too?
5. What human review of AI output occurs, by whom, and under what access controls?

This section barely existed three years ago and is now where I’d focus most attention, partly because vendor answers here are the least standardized and partly because the capabilities change faster than the contracts covering them.

Question thirty-five needs care in how it’s asked. A vendor may honestly answer that they do not train on your data while a third-party model they call does something different under its own terms. Ask about the whole processing chain rather than about the vendor’s own practices, and get the answer written into the agreement rather than confirmed in an email.

Question thirty-seven is quietly important. Deleting a recording does not automatically delete its transcript, the sentiment scores derived from it, or the summary generated afterward, and those derivatives frequently live in different systems with their own retention rules. Ask specifically. TabaTalk’s overview of speech analytics sets out what gets produced.

Section F: Incident Response, Continuity and Exit

1. What is your incident notification commitment, in hours, and what triggers it?
2. Have you experienced a security incident affecting customer data in the past three years, and what was the outcome?
3. Can we report a suspected incident to you directly, and what is the response process?
4. What are your recovery time and recovery point objectives, and when were they last tested?
5. How is service continuity maintained during a regional outage?
6. On termination, in what format is our data returned, over what period, and at what cost?
7. How is deletion confirmed after exit, and is that confirmation contractually binding?

Forty and forty-four both tend to produce revealing answers.

A vendor reporting no incidents across three years has either been fortunate, is defining the term narrowly, or is not telling you. None of those is disqualifying by itself. What matters is whether the response sounds rehearsed or honest, and a candid account of something handled well is a considerably better signal than a flat denial.

Forty-four hides real cost. Data return at exit sounds procedural until you ask about format, and discover that recordings arrive as a bulk archive with metadata in a proprietary structure that maps to nothing you own. Specify the format in the contract, not the intention to provide one, and establish whether extraction carries a charge before you need it rather than during a termination nobody is enjoying.

Reading the Answers

Responses That Should Stop the Process

• Refusal to supply the underlying report while claiming a certification
• Inability to say where backups and analytics stores physically sit
• No documented deletion process at exit
• Unlogged staff access to your environment
• Conversation content going to a third-party model with no contractual opt-out

Responses That Sound Bad but Usually Aren’t

• Holding a Type I rather than Type II report, where the vendor is genuinely new and says so plainly
• Some capabilities delivered through named subprocessors, which is normal and better than pretending otherwise
• A candid incident history with clear remediation and dates
• Residency available only in certain regions, stated upfront rather than discovered later

The Follow-Up That Reveals Most

Ask who else has asked these questions. A vendor serving regulated buyers has an assembled evidence pack and will send it within a day. A vendor assembling one for the first time will take three weeks and produce something inconsistent.

That timing difference tells you more about operational maturity than any individual response does, and observing it costs nothing.

One further habit worth building: record the answers somewhere durable rather than in an email thread. Assessments get repeated annually, staff move on, and the value of this exercise compounds only if next year’s reviewer can see what was claimed last year and check whether it held. Teams that keep a simple register of vendor answers, dated, catch drift that no single assessment would reveal. TabaTalk’s guide to contact centre security practices covers the surrounding controls.

Frequently Asked Questions

How long should a CCaaS security assessment take?

Allow four to six weeks for a regulated deployment, running in parallel with commercial evaluation rather than afterward. Vendors with prepared evidence packs respond within days; those assembling documentation for the first time take considerably longer, which is itself a finding worth recording. Starting the assessment early also leaves room for remediation commitments to be negotiated into the contract rather than raised after signature, when leverage has largely disappeared.

Can a vendor be secure without formal certification?

Yes, though it raises your evidence burden considerably. Certification is a proxy for independently tested controls, and its absence means you verify directly through architecture review, penetration test results and reference calls with comparable customers. Newer vendors sometimes have strong controls and no completed audit cycle. Where a regulator expects certification from your suppliers, however, that expectation applies regardless of how well the vendor performs technically.

Who is responsible when a subprocessor causes a breach?

Contractually, usually your direct vendor, though liability caps often limit what you recover. Practically, regulatory exposure frequently remains with you as the data controller. Require a named subprocessor list with change notification, flow-down security obligations written into the contract, and clarity on breach notification timelines through the chain. Assuming your vendor’s contract with their supplier protects you is a common and expensive error.

Should the questionnaire be sent before or after shortlisting?

Send an abbreviated version early and the full set to your shortlist. Screening questions covering certification scope, residency, subprocessors and tenant isolation eliminate poor fits before anyone invests in demonstrations. Reserving the detailed list for two or three finalists respects everybody’s time and produces better answers, since vendors respond more thoroughly when they believe the opportunity is genuine rather than one of fifteen.

How often should assessments be repeated for existing vendors?

Annually for regulated deployments, with an interim review triggered by specific events: a certification lapse, a reported incident, an acquisition, a material change to AI capabilities, or a change to your own regulatory position. Contract clauses should reserve the right to reassess on those triggers rather than only at renewal, otherwise you spend the intervening period without a mechanism to require answers.

Does a trust center replace the questionnaire?

Not entirely, though it shortens it considerably. A published trust center supplying current reports, subprocessor lists, certification scopes and architecture documentation answers perhaps half of these questions before anyone asks. What remains are the deployment-specific items: your residency, your retention, your isolation arrangement. Vendors without any published security documentation should expect the full list, and their absence of one is worth noting.

What if a vendor refuses to answer certain questions?

Distinguish between refusal and constraint. Declining to share another customer’s incident details is appropriate; declining to state where your own backups reside is not. Ask why, and record the answer. Where a vendor cites confidentiality for something that concerns only your data, that is usually a capability gap wearing a policy justification, and it will not improve after signature.

How do these questions apply to AI voice agents?

They apply with additional weight, since automated systems process conversation content directly and often through third-party models. Section E becomes the priority: where inference occurs, whether content leaves the residency region, whether interactions train models, and what human review exists. Add questions about failure handling, since a system that transfers to a human without context creates its own operational and compliance exposure around what was already disclosed.

Should procurement or security own the final decision?

Neither alone. Security assesses whether controls meet your requirements; procurement weighs that against commercial terms and business need. A structure I’d suggest: security holds a veto over specific unacceptable findings, defined in advance, while procurement decides among vendors that clear that bar. Leaving the whole judgment with either function tends to produce decisions that ignore half of what matters.

Preparing an assessment, or answering one?

Buyers get better results from these questions when the vendor has been asked them before. Sellers get better results from having the evidence assembled before anyone asks.

TabaTalk provides cloud contact center software built for Gulf operations, with client-level account separation, per-account numbering, configurable retention and residency options, and reporting your security team can inspect. Contact our sales team to work through your requirements, or review our financial services setup if you operate in a regulated sector.