What SOC 2 actually tells you about a sales-AI vendor — and what it doesn't

A sales-AI vendor sends a one-page summary with a SOC 2 badge on it. Procurement ticks the security box and the evaluation moves on to pricing.

That sequence is extremely common and it skips the part where the report tells you something. A SOC 2 report is genuinely useful evidence — but about a narrower question than most buyers think, and only if someone reads past the badge.

What SOC 2 actually is

SOC 2 is an attestation, not a certification. An independent CPA firm examines a service organization’s controls against the AICPA’s Trust Services Criteria — security, and optionally availability, processing integrity, confidentiality and privacy — and issues an opinion.

Three consequences follow, and each one is regularly misread.

The vendor chose the scope. Which systems, which criteria, which time period — all defined by the vendor in consultation with the auditor. A report can legitimately cover the core platform and exclude the newer AI feature you are buying. Nothing on the badge tells you this. The scope section does.

Type I and Type II are different claims. Type I says the controls were suitably designed on one date. Type II says they operated effectively across a period. A vendor can obtain Type I in weeks. Type II requires surviving an observation window with the controls actually running. For anything touching your CRM or ERP, Type II is the meaningful one.

There is no pass mark. The report contains the auditor’s opinion and a list of exceptions where testing found controls not operating as described. A report with a handful of documented, remediated exceptions and a candid management response is often a better signal than one with none, because it suggests the testing had teeth.

The three sections worth your time

Scope. What is in and, more informatively, what is out. If the AI capability, the sub-processors running inference, or the region your data sits in are excluded, you have learned something important that the summary page will not mention.

Exceptions. Where controls failed during the period, and what management said about it. Read the response as well as the finding — a specific remediation with a date reads very differently from a paragraph of reassurance.

Complementary user entity controls. The most skipped section and often the most consequential. This is the list of things the report assumes you are doing: managing your own access reviews, configuring permissions correctly, protecting credentials. The vendor’s clean opinion is partly conditional on these. If your organization is not doing them, the assurance is thinner than it appears.

What SOC 2 does not tell you about AI

This is where the standard is being asked to carry weight it was never built for.

Training-data use. Whether the vendor trains on your data is a contractual question. The Trust Services Criteria do not address it. A vendor can hold an unblemished Type II report and reserve the right to train on customer content in its terms — the two documents simply speak to different things. Get a written zero-training clause if you want one; do not infer it.

Model behavior. Accuracy, hallucination rate, and whether the assistant will assert a lead time that does not exist are outside the scope entirely. No security attestation covers whether the output is right.

Sub-processors and model providers. If the vendor routes your prompts to a third-party model API, the relevant question is what that provider retains and for how long. This may appear in the report if scoped in. It frequently is not.

Change management for models. A vendor can swap the underlying model, materially changing behavior, without anything in a SOC 2 report registering the event.

What to ask alongside it

Treat the security report as one input and cover the AI-specific ground contractually:

• Zero-training on customer data, stated in the agreement rather than in a FAQ.
• Retention and deletion periods for prompts, outputs and logs, with a number.
• The sub-processor list, and notice before it changes.
• Data residency, which matters for Indian enterprises under the DPDP Act and for European ones under the GDPR.
• Write permissions — precisely which fields the tool can change in your systems, and whether those changes are attributable in the audit log.

Frameworks help here where SOC 2 stops. The NIST AI Risk Management Framework gives a common vocabulary for AI-specific risk, and ISO/IEC 42001 addresses AI management systems as ISO 27001 does information security. Neither is a certification you can demand as a gate today, but both give a security review a structure for questions the attestation does not answer.

The India and US split

In US enterprise procurement, SOC 2 Type II has become the default expectation, and its absence usually stops a deal. In India, ISO 27001 is more commonly the familiar artifact, and many vendors selling into both markets hold both.

Either way, obligations under India’s Digital Personal Data Protection Act attach to your organization as the data fiduciary. A vendor’s report is evidence supporting your diligence; it does not transfer your accountability.

A five-question script for the security review

Most security reviews of sales-AI vendors run long because they work from a generic questionnaire. These five questions, asked in this order, separate vendors faster than a hundred-row spreadsheet does — because each one has a specific answer that cannot be given in marketing language.

1. Is the AI capability we are buying inside the SOC 2 scope, or outside it? Ask for the scope section, not the summary page. A vendor whose newer AI feature sits outside the audited boundary is not disqualified, but you now know which part of the product has been independently examined and which has not.

2. Which identity does the integration use against our CRM and ERP? The signed-in user, or a service account with its own rights? This single question determines whether your existing permissions still hold once the assistant is deployed, and it is almost never covered by an attestation.

3. What is the retention period for prompts, outputs and logs — as a number? “We retain data only as long as necessary” is not an answer. Ninety days is an answer. So is thirty. The willingness to state a figure tells you whether anyone has actually decided.

4. Who are the sub-processors, and what notice do we get before that list changes? If inference runs on a third-party model API, that provider’s retention terms are now part of your risk surface, and a model swap can change behavior without any contractual event firing.

5. What can it write, field by field, and is the write attributable in the audit log? The question that determines your blast radius. A vendor who answers with a field-level list has thought about it. A vendor who answers “it writes to the CRM” has not.

What about a vendor with no SOC 2 at all?

Not automatically a rejection, and treating it as one will cost you access to genuinely good smaller products — particularly Indian vendors selling into their home market, where ISO 27001 is the more familiar artifact and a US attestation is an expensive thing to obtain for buyers who never ask for it.

The proportionate response is to substitute evidence rather than demand the specific document. A completed CAIQ from the Cloud Security Alliance’s STAR registry covers similar ground at lower cost to the vendor. A penetration test report with remediation notes tells you something real. So does a written architecture description of where data flows and where it rests.

What should give you pause is not the absence of a report but the absence of an answer — a vendor who cannot describe their sub-processors, cannot state a retention period, and cannot say which identity the integration uses. That vendor is not too small to be audited. They have not thought about it yet, and your CRM is not the right place for them to start.

The one-line version

SOC 2 tells you a company has operational discipline and that someone independent checked. It does not tell you the AI is safe, accurate, or contractually prevented from learning from your pipeline.

Read the scope, read the exceptions, read the user entity controls — and put everything AI-specific in the contract.