The CX Platform Security Review: What Procurement Will Ask (and How to Answer)

TL;DR#

The CX platform security review is where late-stage customer experience purchases die, because the questionnaire arrives after the demo, the pricing negotiation, and the internal business case — and it asks questions no one on the CX team can answer. A SOC 2 Type II report and an ISO/IEC 27001:2022 certificate are the two artifacts every reviewer requests, but neither is a pass/fail badge: the vendor defines its own SOC 2 scope, and only the Security category is mandatory out of the five Trust Services Criteria the AICPA publishes. Most SOC 2 reports also use the carve-out method for subservice organizations, which means a vendor's AI model provider sits explicitly outside the auditor's testing. The questionnaire you get handed is usually a derivative of the Cloud Security Alliance's CAIQ (197 control objectives across 17 domains) or the Shared Assessments SIG. For AI-native CX platforms — including Perspective AI — the decisive questions are narrower than generic infosec: is customer data used to train models, is the model provider a named subprocessor, in which region does inference run, and does deleting a transcript also purge its embeddings? Under GDPR Article 28, a processor cannot engage a new subprocessor without the controller's authorisation, which makes the subprocessor list a live contract term rather than a page in a PDF. Assemble the packet — questionnaire, DPA, subprocessor list, data flow diagram, penetration test summary, retention matrix — before you shortlist, and the review costs days instead of weeks.

Why the CX Platform Security Review Kills Deals Late#

The CX platform security review kills deals late because it is the first stage of the purchase where the CX team is not the decision-maker. Everything before it — the demo, the scoring model, the ROI math — runs on CX's home turf. Then the questionnaire lands, and the people who can answer it (security, privacy, legal, IT) have no stake in your timeline and no context on why you picked this vendor.

Three structural problems make it worse for customer experience purchases specifically.

The data is conversational, not columnar. A survey suite stores Likert scores and a few open-text fields. An AI interview platform stores transcripts of customers talking in their own words — which is unstructured, unpredictable, and far more likely to contain incidental personal data, account details, health mentions, or complaints naming individual employees. Reviewers who waved through a rating widget will not wave through a transcript store, and they shouldn't. This is the same reason the data retention and privacy rules for customer feedback deserve their own decision, not a copy-paste from the last SaaS contract.

The AI layer adds a subprocessor nobody planned for. The moment a platform sends customer text or audio to a model provider, that provider is a data processor in the chain. If the vendor's paperwork doesn't name it, the review stops until it does.

Nobody owns the packet. In most organizations, security review is triggered by procurement, answered by the vendor, assessed by security, and chased by whoever wants the tool. That's four handoffs with no single owner. Naming the owner is part of mapping who sits on the CX buying committee — and it should happen in week one, not week six.

The fix is unglamorous: treat the security review as a workstream that starts when you write requirements, not a gate you hit at the end. If you are still drafting evaluation criteria, fold the security asks into the requirements checklist you write before shortlisting and into the vendor-neutral scoring framework you use to compare finalists.

What a CX Vendor Security Questionnaire Actually Asks#

A CX vendor security questionnaire asks for evidence across seven repeating sections, and the specific questionnaire format matters less than knowing which artifact closes each one. Most enterprise questionnaires are derivatives of two industry templates: the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire, which maps to the Cloud Controls Matrix and its 197 control objectives across 17 domains, and the Shared Assessments SIG. Higher education adds HECVAT, US federal adds FedRAMP, and state agencies add StateRAMP or TX-RAMP.

Two practical notes. First, ask each finalist for the whole packet in a single request rather than trickling questions — vendors with a mature program will send a prepared bundle within two business days, and response speed is itself a signal worth scoring. Second, keep these asks separate from your functional criteria. Security answers tell you whether you can buy a platform; the twelve capabilities that separate a CX platform from a survey tool tell you whether you should.

Certifications: What SOC 2 Type II and ISO 27001 Do and Don't Tell You#

SOC 2 Type II and ISO/IEC 27001 tell you that a vendor has a security program a third party has examined — they do not tell you that the vendor is secure, that your specific product is in scope, or that no problems were found. Both are frequently misread as badges. They are documents, and the value is entirely in reading them.

What a SOC 2 Type II report actually proves#

A SOC 2 Type II report is a CPA firm's attestation on whether a service organization's controls were suitably designed and operated effectively over a defined observation period, typically three to twelve months. It is built on the AICPA's Trust Services Criteria, and the AICPA's own framing of the engagement is an examination of controls relevant to security, availability, processing integrity, confidentiality, or privacy — five categories, of which only Security (the common criteria) is mandatory. Availability, Confidentiality, Processing Integrity, and Privacy are each optional, and the vendor chooses.

That design has five consequences your reviewer will check, and you should check first:

1. The observation period and the gap. A report covering January to December is stale by March. Ask for a bridge letter (also called a gap letter) covering the interval from period end to today.
2. The scope. The vendor writes the system description. A SOC 2 can legitimately cover the core platform and exclude a newer AI feature, a mobile SDK, or an acquired product line. Read the description and confirm the thing you're buying is named.
3. The categories. If your purchase involves personal data and the report covers Security only, the Privacy and Confidentiality criteria were never tested.
4. The exceptions and the opinion. SOC 2 reports contain a test-results section listing exceptions, and the opinion can be unqualified, qualified, adverse, or a disclaimer. A report with exceptions is normal and often more credible than a spotless one; a qualified opinion is a conversation.
5. Complementary user entity controls. Every report lists CUECs — controls the auditor assumed you operate, such as managing your own SSO, provisioning, and role assignments. These are your obligations, and they belong in your rollout plan alongside the rest of the 90-day AI-for-CX rollout sequence.

One more distinction that saves time: SOC 3 is the general-use summary version, publicly shareable but stripped of test detail, and SOC 1 covers controls relevant to financial reporting, not security. If a vendor answers a security request with a SOC 3 or a SOC 1, you have not received what you asked for.

What ISO/IEC 27001 certification actually proves#

An ISO/IEC 27001 certificate proves that an accredited certification body audited the vendor's information security management system against the standard's requirements and found it conforming — a statement about management process, not a report of control test results. The current edition is ISO/IEC 27001:2022, whose Annex A reorganized the control set into 93 controls across four themes (organizational, people, physical, technological), replacing the 114 controls in 14 clauses of the 2013 edition. Certification runs on a three-year cycle with annual surveillance audits.

Two documents matter more than the certificate image on the vendor's trust page. The scope statement on the certificate defines which entities, sites, and services were certified — a certificate scoped to "corporate IT services" is not a certificate for the SaaS platform. The Statement of Applicability records which Annex A controls the vendor applied and its justification for any exclusions. Buyers almost never ask for the SoA. Ask.

Neither standard was written for AI systems, which is why ISO/IEC 42001:2023 — the AI management system standard published in December 2023 — is starting to show up in questionnaires, alongside voluntary frameworks like the NIST AI Risk Management Framework and its Govern, Map, Measure, and Manage functions. Neither is yet a common requirement. Both are useful shorthand when your internal policy needs to describe how an AI vendor is governed, which is the ground covered by the CX AI governance decisions to make in 2026.

Subprocessors and the AI Model Question#

Subprocessors are the section where AI-native CX platforms get held up, because the model provider is a subprocessor and generic infosec questionnaires have no field for it. Under Article 28 of the GDPR, a processor may not engage another processor without the controller's prior specific or general written authorisation; where authorisation is general, the processor must inform the controller of intended changes so the controller can object. The same article binds the new subprocessor to equivalent obligations and leaves the original processor fully liable. In plain terms: the subprocessor list is a contract term you get to police, and "we may change providers at any time" is not an acceptable answer.

Here is the part most buyers miss. A vendor's SOC 2 report almost always uses the carve-out method for subservice organizations, which excludes those organizations' controls from the description and from the auditor's testing. So a SOC 2 Type II from your CX vendor tells you nothing about the model provider's controls. You need the provider named, and you need the terms.

That last row is the single most valuable question in a CX security review and the one almost nobody asks. Transcript deletion is easy. Purging the vector embeddings, the generated summary, the theme model, the analytics aggregate, and the search index built from that transcript is an engineering problem, and vendors differ enormously in whether they've solved it. Ask for the cascade in writing, then verify it during the pilot.

If your review has to survive a regulator as well as a security team, the vertical questionnaires get more specific: HIPAA requires a business associate agreement and extends it down the subcontractor chain; financial services reviewers will want the SIG plus evidence of vendor oversight, which is the context behind Qualtrics alternatives for financial services and banking; public sector adds FedRAMP or StateRAMP plus a VPAT documenting WCAG conformance, the pattern covered in Qualtrics alternatives for government and public sector buyers.

Data Flow Diagrams and Residency#

A data flow diagram for a CX platform shows every point where customer data is collected, transmitted, stored, processed, and accessed — including by humans — and reviewers use it to find the hop the questionnaire didn't disclose. Vendors who can produce one on request are usually the ones who pass; vendors who offer an architecture marketing slide instead are usually the ones who don't.

A reviewable diagram covers: collection surfaces (embedded widget, link, email, voice); transport encryption (TLS 1.2 or higher, ideally 1.3); primary storage and encryption at rest (AES-256 is the expected answer); each processing hop including the model provider; the analytics and logging path; backup destinations; and every human access route, including vendor support engineers and the tooling they use. Then it names the region for each box.

Data residency and data sovereignty are different questions, and CX vendors conflate them. Residency asks where data is stored. Sovereignty asks who can access it and under which jurisdiction's law. A platform can store EU data in Frankfurt and still route a support engineer in a third country into that data at 2am, or send a model call to a US inference endpoint. Both break the promise your privacy team thinks it bought. Ask for three things separately: storage region, processing region, and support access region.

For transfers out of the EEA, the mechanisms are the ones GDPR Chapter V provides — adequacy decisions such as the EU–U.S. Data Privacy Framework adopted in July 2023, or standard contractual clauses with a transfer impact assessment. What you want in the DPA is the mechanism named, not a vague reference to "appropriate safeguards." The same diagram doubles as input to your integration design, since every downstream connector is another data flow — worth reconciling against how you plan on connecting CX data to the rest of the stack.

Retention, Deletion, and the DPA#

Retention and deletion are contract questions, not feature questions, and they belong in the DPA where they are enforceable. GDPR's storage limitation principle requires personal data be kept no longer than necessary, the right to erasure gives individuals a route to demand removal, and California's CPRA requires businesses to disclose retention periods rather than hold data indefinitely. None of that is satisfied by a settings toggle a vendor can change.

Get these terms in writing before signature:

• Default and configurable retention periods, stated in days, per data type — transcripts, audio, derived summaries, logs, and analytics aggregates often differ.
• Deletion SLA for a customer-initiated delete and for end-of-contract deletion, with the derived-artifact cascade named explicitly.
• Backup expiry, stated honestly. Backups roll off on a cycle, commonly 30 to 35 days; a vendor claiming instant deletion from backups is either wrong or running something unusual, and either answer needs explaining.
• Breach notification window. GDPR requires a controller to notify its supervisory authority within 72 hours of becoming aware of a breach, and a processor to notify the controller without undue delay. "Without undue delay" is not a number — negotiate 24 or 48 hours so your own clock is achievable.
• Export before deletion. You want your data out in a usable format, which is the same capability that matters when leaving an incumbent. Anyone who has worked through getting your data out of Qualtrics knows an export right on paper and a working export are different things.
• Liability. The general limitation-of-liability cap and the data-breach super-cap are where legal review actually spends its time, along with cyber liability insurance limits. Budget for the negotiation the way you budget the rest of the total cost of ownership of a CX platform.
• Audit and assistance rights, including cooperation on data subject requests and DPIAs.

If your organization has never written a retention position for open-ended feedback, do that before the questionnaire, not during it. Conversational data forces a real decision: transcripts are more useful over years and riskier over years, and the tradeoff is yours, not the vendor's.

How to Prepare the Security Packet Before You Shortlist#

Preparing the packet before you shortlist turns the security review from a multi-week discovery exercise into a document exchange. Run these seven steps in parallel with evaluation, not after it.

Step 1: Classify the data first. Write down what the platform will actually hold — personal data categories, special categories, regulated data, geographies of the data subjects. Everything downstream follows from this one page.

Step 2: Pull your own template. Get the exact questionnaire your security team will use, in its current version, and read it yourself. Half the questions are answerable by you, not the vendor.

Step 3: Pre-brief security and privacy. A 30-minute session explaining what AI interviews are, what a transcript contains, and why this is not a survey tool prevents the review from starting with a misconception. Bring the AI readiness assessment to run before you buy anything if you have one.

Step 4: Ask every finalist for the same bundle, at the same time. SOC 2 Type II report plus bridge letter, ISO certificate and scope statement, penetration test summary, subprocessor list, data flow diagram, DPA with AI addendum, retention matrix, insurance certificate. Compare response times and completeness — put both into your weighted CX vendor scorecard as a scored criterion rather than a footnote.

Step 5: Read the reports before your reviewer does. You are looking for scope mismatches, expired periods, missing categories, and carve-outs. Finding them yourself lets you raise them as questions rather than having them raised as objections.

Step 6: Verify claims in the pilot. A pilot is the only place to test whether deletion actually cascades, whether SSO and role-based access work as described, and whether the audit log shows what you need. Add three security acceptance tests to the exit criteria when you run a CX platform pilot.

Step 7: Carry the answers into implementation. CUECs, retention settings, access reviews, and DPA obligations are launch tasks. They travel with the 60-day CX platform migration checklist, not with the contract file.

Two adjacent decisions get easier once the packet exists. Each additional CX tool multiplies the review surface, which is a real argument in deciding which CX tools to cut. And if security review is pushing you toward building internally, price the compliance work honestly — that is precisely what the build-versus-buy decision framework for a CX platform is for.

Common Pitfalls in CX Vendor Security Review#

The pitfalls in CX vendor security reviews are predictable, which means they are avoidable.

• Accepting the badge instead of the report. A trust page listing SOC 2 and ISO 27001 logos is marketing. The report and the scope statement are evidence.
• Letting the vendor scope the review. If the vendor's questionnaire answers define the boundary, the boundary will exclude whatever is inconvenient.
• Treating the AI layer as an implementation detail. It is a subprocessor relationship with its own retention, region, and training terms.
• Running security review after price negotiation. You lose the leverage you need for DPA and liability terms. Sequence it alongside the pricing model comparison instead.
• Forgetting the human path. Most realistic exposure is a person with support access, not an exotic exploit.
• Skipping the pilot verification. Written answers and shipped behavior diverge, and only a pilot catches it.
• Not reusing the work. The packet you build for one purchase answers 80% of the next one. Keep it, and keep the security criteria in your standing RFP questions for CX vendors.

Frequently Asked Questions#

What is a CX platform security review?#

A CX platform security review is the assessment your security, privacy, and legal teams run on a customer experience vendor before contract signature, covering certifications, application security, subprocessors, data flows, residency, retention, and contract terms. For AI-native platforms it also covers model processing — whether customer data trains models, which providers see it, and where inference runs.

Is a SOC 2 Type II report enough to approve a CX vendor?#

No, a SOC 2 Type II report alone is not enough, because the vendor defines its own scope and only the Security category is mandatory among the five Trust Services Criteria. You also need the observation period and a bridge letter, confirmation that the product you're buying is in the system description, the exceptions section, the complementary user entity controls, and a separate answer on subprocessors that the report's carve-out method excludes.

Does a CX vendor's SOC 2 report cover its AI model provider?#

Usually no. Most SOC 2 reports use the carve-out method for subservice organizations, which excludes those providers' controls from the system description and from the auditor's testing. Ask for the model provider to be named in the subprocessor list, and ask for its retention and no-training terms in writing — the vendor's own report does not speak to them.

What should we ask about data privacy for customer feedback and AI processing?#

Ask six specific questions: is our data used to train or fine-tune models, which model providers are named subprocessors, how long does the provider retain inputs, in which region does inference run, who at the vendor can read transcripts, and does deleting a record also purge its embeddings and summaries. The last question is the one most buyers skip and the one that most often exposes an immature platform.

Do we need a DPA if the CX platform only collects open-ended feedback?#

Yes. Open-ended feedback is more likely to contain personal data than structured survey responses, because customers mention names, accounts, locations, and circumstances unprompted. If any of your customers are in the EEA or UK, GDPR requires a written processor contract, and the DPA is where retention, deletion, subprocessor notification, transfer mechanism, and breach notification timing become enforceable.

How long does a CX vendor security review take?#

It depends on preparation more than vendor size. Reviews where the buyer has already classified the data, pre-briefed the security team, and requested a complete artifact bundle often close in one to two weeks. Reviews that start with a blank questionnaire sent to a vendor mid-negotiation routinely run four to eight weeks, mostly waiting on subprocessor and AI-processing clarifications.

Running the CX Platform Security Review Without Losing the Quarter#

The CX platform security review is not a formality and it is not a bureaucratic tax — it is the stage where you find out whether the vendor you liked in the demo has actually built the controls their marketing implies. The work is front-loadable. Classify the data, pull your own questionnaire, pre-brief security, request one complete bundle from every finalist, read the SOC 2 Type II and ISO/IEC 27001 documents yourself for scope and exceptions, insist that AI model providers appear by name on the subprocessor list, and make deletion cascade to derived data a written term. Do that before you shortlist and the review confirms a decision instead of relitigating it.

Conversational feedback raises the stakes because transcripts hold more than scores do — which is exactly why any AI interview platform, Perspective AI included, should be able to hand you its subprocessor list, its data flow diagram, its retention matrix, and its model-processing terms without a scramble. Hold every vendor to that bar, then verify it in a pilot rather than a PDF.

If you want to test how conversational research holds up under your own security constraints, start a research study on a low-sensitivity segment, read the platform documentation with your security team in the room, and check the commitments against the plans and pricing before you scale. Teams that run this sequence — CX teams and operations teams most often — get through review once and reuse the packet forever.