SOC 2 for AI customer support: what the report covers and what to ask

A SOC 2 report shows up in a lot of vendor security questionnaires as a checkbox: does the vendor have one, yes or no. That framing treats the report as a certificate, and it is not one. It is an attestation, an auditor's written opinion, built on the AICPA's trust services criteria, and reading it correctly changes what you ask a support AI vendor next.

This matters more for a support AI than for most software, because a support agent reads customer messages, sometimes account numbers and order details, and can retrieve that content back out in a later conversation. A generic security review misses that retrieval path entirely. If you are evaluating a vendor for AI agents on your support channel, the SOC 2 report is one input among several, not the whole answer, and this guide covers what the report leaves out.

What SOC 2 actually is

SOC 2 stands for System and Organization Controls 2, a reporting framework the AICPA publishes for service organizations. An independent CPA firm examines a vendor's controls against a defined criteria set and issues a written opinion on whether those controls were suitably designed and, for a Type II report, operating effectively over a review period, typically three to twelve months.

The AICPA promulgates the professional standards that govern SOC engagements, which makes SOC 2 an attestation product, not a certification scheme. There is no SOC 2 seal that a government body issues after a pass or fail test. There is a report, written by an auditor, that states an opinion about specific controls the vendor chose to put in scope.

That distinction is not pedantic. A certification implies a fixed bar every holder cleared the same way. An attestation is a professional opinion tied to a specific scope, a specific period, and specific criteria the vendor selected.

Two SOC 2 reports from two vendors can describe entirely different sets of controls, which is exactly why reading the report matters more than seeing the logo, a distinction Vanta's compliance documentation echoes for teams new to the framework.

Type I and Type II are the two report flavors, and they answer different questions. A Type I report evaluates whether controls were designed appropriately at a single point in time, essentially a snapshot. A Type II report evaluates whether those same controls actually operated effectively across a review window, which is the far stronger signal because it covers sustained behavior rather than a moment.

When a vendor says they have SOC 2, ask which type and for what period. A Type I report from a single day tells you almost nothing about whether the controls held up under real operational load, while a Type II report spanning six or twelve months tells you the controls were tested against actual, ongoing practice, a nuance security teams at firms like Drata walk through in their compliance guidance.

The five trust services criteria, and which ones are optional

Communicate.so

Security is the only mandatory category in every SOC 2 report. The AICPA's 2017 Trust Services Criteria, with points of focus revised in 2022, defines five categories: security, availability, processing integrity, confidentiality, and privacy. A vendor chooses which of the four optional categories to include, and most SOC 2 reports in the wild cover security alone.

Security, sometimes called the common criteria, covers protection against unauthorized access, both physical and logical, and forms the baseline every SOC 2 report must address regardless of scope. It includes access controls, network security, change management, and incident response, the operational backbone most vendors put in front of an auditor first.

Availability addresses whether systems are accessible for operation and use as agreed, which matters if your support AI is the thing customers reach when something else has already broken. Processing integrity addresses whether system processing is complete, accurate, and authorized, relevant if the AI is taking scoped actions like issuing a refund or updating an order, not just answering questions.

Confidentiality addresses whether information designated as confidential is protected as agreed, which is the category closest to how a vendor handles the customer messages, account details, and internal documents that flow through a support AI's retrieval layer. Privacy addresses the collection, use, retention, and disposal of personal information consistent with a stated privacy notice.

A vendor's SOC 2 report that covers security alone says nothing certified about confidentiality or privacy, even though those are the categories that matter most for a system reading customer conversations. Ask which criteria are in scope before you assume the report covers how your customers' data is handled, not just whether the vendor's servers are locked down, a gap the Cherry Bekaert guide to trust services criteria calls out for buyers evaluating vendors on paper alone.

What a SOC 2 report tells you, and what it does not

A SOC 2 report is evidence about the vendor's operational controls, not about the AI's behavior. It tells you whether access to production systems is restricted, whether changes go through review, whether incidents get logged and escalated, and whether the controls the vendor put in scope held up during the audit period. It does not tell you what the model does with your customers' words.

A SOC 2 report will not tell you whether the AI hallucinates policy details it was never trained on. It will not tell you whether a customer's account number, typed into a chat window, gets embedded into a vector index and later resurfaces in an unrelated conversation. It will not tell you whether the vendor's retention window matches what your own privacy notice promises your customers.

It also will not tell you how the vendor prompts the underlying model, what happens when the model is unsure, or whether an escalation to a human actually preserves context instead of dropping it. Those are product and architecture questions, and a security audit was never designed to answer them, a gap that shows up across the industry: 44% of organizations using generative AI reported at least one negative consequence from it in 2024, rising to 51% in 2025 (CMSWire), and none of that risk shows up in a controls audit scoped to infrastructure.

Treat a SOC 2 report the way you would treat a building inspection. It tells you the wiring is up to code and the fire exits work. It does not tell you what the tenant does inside the building, and for a support AI, what happens inside the building is the retrieval pipeline, the prompt, and the guardrails around an uncertain answer.

Why AI vendors add a layer of risk a standard audit misses

Communicate.so

A traditional SaaS vendor stores structured data in a database with a known schema. A support AI vendor ingests unstructured customer conversations, often including personal details volunteered mid-conversation, and turns some of that content into embeddings for retrieval. That pipeline is new enough that most audit scopes were not written with it in mind.

The risk surface an AI support vendor introduces includes what gets embedded and indexed, how long conversation history persists, whether a redaction step runs before content reaches a vector store, and whether a customer's sensitive detail in one conversation can influence or leak into another. None of that is guaranteed by a security-only SOC 2 report.

This is also where the industry's own incidents are instructive. A cloud storage provider's support chatbot cited a downgrade policy that did not exist, an incident reported in February 2026 (SocialIntents), and a coding tool's cofounder had to acknowledge an incorrect response from a front-line AI support bot that had invented a policy on the spot (Fortune). Both vendors could plausibly have held a clean SOC 2 report and still shipped that failure, because hallucination is a product behavior, not an access control.

None of this means SOC 2 is worthless for an AI vendor. It means the report answers infrastructure questions well and product-behavior questions not at all, and a buyer who conflates the two is evaluating half the risk.

Four questions a SOC 2 report will not answer

Ask these four questions directly, because the report will not surface the answers on its own. Each targets a gap between what SOC 2 examines and what actually determines whether an AI support vendor is safe to hand customer conversations to.

First, what happens to a customer's personal data once it enters a conversation. Ask specifically whether messages are embedded into a retrieval index, whether that index is scoped per customer or shared across a training corpus, and whether any redaction step runs before storage. A vendor that cannot answer this in plain language has not designed for it.

Second, how does the AI behave when it does not know an answer. Ask whether the system is grounded in your own content and instructed to refuse or escalate rather than guess, since reducing hallucinations is an architecture choice, not a side effect of good infrastructure. A vendor with a spotless SOC 2 report and no answer here is still a hallucination risk on your channel.

Third, what is the retention window for conversation content, and does it match a written policy you can show your own customers and regulators. Ask for the number in days or months, not a vague answer about deleting data when no longer needed, because storage limitation obligations under frameworks like the GDPR require a defined, enforced period, not an aspiration.

Fourth, what happens at the human handoff. Ask whether an uncertain or escalated conversation passes to a person with full context intact, or whether it resets and forces the customer to repeat themselves, since that failure is one of the most common complaints about AI support tools: hallucinated answers, no clear escalation path, a robotic tone, and no context awareness are the top four issues customers cite (Twig). A working AI to human handoff is a design decision a SOC 2 audit does not test.

Communicate.so

Write the four questions down and send them in the same email as the SOC 2 request. A vendor that answers all four in plain language, with specifics rather than reassurance, has clearly built for this. A vendor that deflects into general security language has likely not thought through the AI-specific risk at all, regardless of what the audit report says.

SOC 2 scope versus AI-specific risk, side by side

The table below separates what a security-only SOC 2 report typically covers from what an AI support vendor needs separately. Use it as a checklist when a vendor hands you a report and calls the security conversation finished.

Read the rows honestly. The left column is real and worth verifying, but it stops at infrastructure. The right column is where an AI support vendor's actual product risk lives, and no auditor tests it unless the vendor specifically put confidentiality or privacy in scope and structured the audit around the retrieval pipeline, which is rare in practice today.

Reading the report itself, not just the badge

If a vendor shares an actual SOC 2 report rather than a marketing badge, three sections are worth reading directly. The system description tells you what is actually in scope, which can be narrower than the vendor's marketing implies. The trust services criteria section tells you which of the five categories the audit covered, security alone or something broader.

The auditor's opinion section states whether the opinion is unqualified, meaning the controls met the criteria without exception, or qualified, meaning the auditor found exceptions worth flagging. A qualified opinion is not automatically disqualifying, but it deserves a direct question about what the exception was and how it was remediated.

Ask for the report under a mutual non-disclosure agreement if the vendor will not share it openly, since a legitimate SOC 2 report is a real document with a named audit firm attached, not a claim you take on faith. If a vendor cannot produce the actual report on request, treat the SOC 2 mention on their site as marketing copy until they can, a caution the AICPA's own materials frame as the whole point of the attestation model: the report exists to be read, not just referenced.

Communicate.so

This applies just as much when a vendor claims a report is in progress. A SOC 2 audit underway is not a completed audit, and a target completion date is not the same as an unqualified opinion in hand. If the timeline matters for your procurement decision, get it in writing with a date, not a general assurance that it is coming soon.

Where communicate.so stands, honestly

Communicate.so does not currently hold a SOC 2 report, HIPAA attestation, or ISO 27001 certification. Data handling practices are described on the security page, including encryption at rest, workspace isolation, and two-factor authentication support, but none of that is the same as an independent auditor's opinion, and this guide is not going to imply otherwise.

If your procurement process requires a completed SOC 2 report as a gate, communicate.so is not the right fit today, and that is a plain limit worth stating rather than working around. If your process weighs architecture and product behavior alongside a compliance document, the questions in this guide apply to any vendor you are evaluating, including this one, and are worth asking directly rather than inferring from a badge.

Key takeaways

• SOC 2 is an attestation, an auditor's written opinion built on AICPA criteria, not a government certification or a pass or fail badge.
• Security is the only mandatory trust services criterion; confidentiality and privacy, the categories closest to customer data handling, are optional and often absent.
• A SOC 2 report examines infrastructure controls, not model behavior, so it says nothing about hallucination risk, retrieval scope, or handoff quality.
• Ask four direct questions: what happens to personal data in the retrieval pipeline, how the AI behaves when uncertain, the exact retention window, and whether human handoff preserves context.
• Request the actual report and read the system description, criteria scope, and auditor opinion before treating SOC 2 as a completed checkbox.

Evaluating a support AI vendor on more than a badge means reading the security posture directly and asking the four questions above before you connect a single customer conversation. If compliance documentation is a hard gate for your team, confirm the current state with the vendor in writing rather than assuming from a logo on a pricing page.

Frequently asked questions

Is SOC 2 a certification or a legal requirement?

Neither. SOC 2 is an attestation, an independent auditor's written opinion on whether a vendor's controls met defined criteria over a period of time, issued under standards the AICPA publishes. No law requires it, and no government body issues it as a pass or fail credential.

Enterprise buyers often require it contractually, which is different from a legal mandate.

What is the difference between SOC 2 Type I and Type II?

A Type I report evaluates whether controls were designed appropriately at a single point in time. A Type II report evaluates whether those same controls operated effectively across a review period, typically three to twelve months. Type II is the stronger signal because it tests sustained behavior rather than a snapshot.

Does SOC 2 cover privacy and data handling automatically?

No. Security is the only mandatory trust services criterion. Confidentiality and privacy are two of four optional categories a vendor can choose to include, and many SOC 2 reports cover security alone.

Always ask which criteria are in scope rather than assuming the report covers customer data handling.

Can an AI support vendor have SOC 2 and still hallucinate answers?

Yes. SOC 2 examines infrastructure and operational controls, not model output. A vendor can have a clean audit and still ship a support bot that invents a policy or a refund window, which is why reducing hallucinations requires architecture choices a security audit does not test.

What should I ask a vendor if they do not have SOC 2 yet?

Ask what compensating evidence they can offer: encryption practices, access control policies, incident response process, and a clear answer on data retention and retrieval scope. A vendor without SOC 2 is not automatically unsafe, and a vendor with SOC 2 is not automatically safe for an AI-specific risk like hallucination or retrieval leakage.

How long does a SOC 2 audit period usually cover?

A Type II audit period is commonly three to twelve months, chosen by the vendor and disclosed in the report. A longer period is generally a stronger signal, since it means the controls were tested against more operational variation, not just a quiet stretch.

Who actually writes and issues a SOC 2 report?

An independent CPA firm licensed to perform attestation engagements writes and signs the report, following professional standards the AICPA promulgates. The AICPA does not itself audit vendors or issue reports; it sets the criteria and standards that the licensed auditor applies.

Is a SOC 2 report public?

No. SOC 2 reports are confidential documents typically shared under a non-disclosure agreement, unlike a SOC 3 report, which is a public-facing summary intended for general distribution. If a vendor cites SOC 2 on a marketing page without offering the underlying report on request, ask for it directly.

Does SOC 2 apply only to United States companies?

SOC 2 originates from United States attestation standards, but vendors anywhere can pursue it, and many international buyers request it as a baseline regardless of the vendor's home country. It sits alongside, not instead of, region-specific frameworks like the EU AI Act or GDPR for European operations.

What is the relationship between SOC 2 and ISO 27001?

Both are independent evaluations of an organization's security practices, but they differ in structure. SOC 2 is an attestation against AICPA trust services criteria, typically renewed annually. ISO 27001 is a certification against an international standard for an information security management system, with a formal certificate issued by an accredited body.

Vendors sometimes hold both, and the AICPA publishes mappings between the two frameworks.

Should a small support team require SOC 2 from every vendor?

Requiring SOC 2 from every vendor, including small tools with limited data exposure, adds procurement friction without matching the actual risk. A better filter weighs what data the vendor touches: a support AI reading customer conversations is a higher bar than a scheduling tool, so calibrate the requirement to exposure, and pair it with the security questions this guide covers rather than treating the badge alone as sufficient.

Can a vendor lose SOC 2 status?

A SOC 2 report is not a permanent status. It covers a fixed audit period and must be renewed through a new audit, typically annually, to remain current. A vendor citing an old report without a recent renewal date is effectively citing an expired attestation.

What does a qualified opinion in a SOC 2 report mean?

A qualified opinion means the auditor found one or more exceptions where a control did not operate as designed during the review period. It is not automatically disqualifying, but it warrants a direct question about what the exception was, its scope, and how the vendor remediated it before the next audit cycle.

Does SOC 2 cover subprocessors an AI vendor relies on, like the model provider?

Only if the vendor's system description explicitly includes those subprocessors in scope. Many AI support vendors route requests through a third-party model provider such as OpenRouter, and whether that dependency sits inside or outside the audited boundary is a system description detail worth checking rather than assuming.

What is the difference between SOC 2 and a penetration test?

A penetration test is a point-in-time technical exercise where testers actively try to break into systems and report vulnerabilities found. SOC 2 is a broader, longer-duration review of whether documented controls and processes, not just technical defenses, were designed and operated correctly. Mature vendors typically run both, and neither substitutes for the other.

Why do some AI support vendors avoid SOC 2 entirely?

Cost, audit overhead, and stage of the company are common reasons. A SOC 2 Type II audit requires months of evidence collection and a paid engagement with an audit firm, which is a real investment for an early-stage vendor. Absence of SOC 2 is a data point to weigh, not an automatic disqualifier, especially against the more AI-specific questions in this guide.

Does a SOC 2 report guarantee GDPR compliance?

No. SOC 2 and GDPR are separate frameworks with different scopes. A vendor can hold a clean SOC 2 report covering security and still fall short of GDPR obligations like lawful basis, data subject rights, and storage limitation, covered in more depth in the GDPR and AI customer support guide.

Ask about each separately.

What is the fastest way to verify a SOC 2 claim is real?

Ask the vendor to share the actual report, or at minimum the audit firm's name and the report period, under a mutual non-disclosure agreement if needed. A real SOC 2 report names a specific licensed audit firm and a specific date range. A vendor that cannot produce either detail on request is likely citing SOC 2 as marketing language rather than a completed audit.

How does SOC 2 relate to the questions I should ask about an AI agent specifically?

SOC 2 answers infrastructure questions: access control, change management, incident response. It does not answer whether the AI agent is grounded in your content, refuses to guess when uncertain, or hands off cleanly to a human. Treat the two as separate evaluations, run in parallel, not one substituting for the other.

What is the difference between SOC 1 and SOC 2?

SOC 1 examines controls relevant to a customer's financial reporting, the kind a payroll or billing processor would need for its clients' auditors. SOC 2 examines controls relevant to security, availability, processing integrity, confidentiality, and privacy, the framework relevant to a support AI vendor. A vendor citing SOC 1 alone has not addressed the security and data handling questions this guide covers.