What is SOC 2?

Privacy, security and identity

SOC 2 is an assurance report for service organisations, based on AICPA trust services criteria, that examines controls relevant to security, availability, processing integrity, confidentiality or privacy. In AI procurement, buyers use SOC 2 to understand whether a supplier has independently examined controls around the systems and data used to deliver its service.

What this means

SOC 2 is a common supplier assurance term, especially in SaaS, cloud and data services. It is often described casually as "SOC 2 compliance", but the more precise idea is a report produced from an independent examination of controls at a service organisation. Those controls are assessed against trust services criteria relevant to security, availability, processing integrity, confidentiality or privacy.

The term comes from the AICPA System and Organization Controls suite of services. SOC 2 is different from SOC 1, which is focused on internal control over financial reporting, and different from SOC 3, which is a more general-use report. SOC 2 reports are usually shared with customers, prospects or auditors who have a reason to understand the service organisation's controls.

For leaders buying AI-enabled software, SOC 2 is useful because it turns vague supplier claims into evidence. It does not prove that an AI model is accurate, fair or legally compliant. It helps answer a narrower but important question: has an independent auditor examined relevant controls around the service, and what did that examination cover?

The report should therefore be read as assurance evidence, not as marketing language. A supplier that has invested in SOC 2 has gone through a recognised assurance process, but the buyer still needs to check whether the evidence matches the specific product, data and workflow being purchased.

Why it matters

AI adoption usually expands the supplier surface area. A business may connect a tool to email, documents, CRM records, call transcripts, support tickets or customer data. The buyer needs assurance that the supplier has controls for access, change management, monitoring, incident response, confidentiality, availability and privacy where those criteria are in scope.

SOC 2 matters because it is a recognised diligence artefact. Instead of relying only on a security questionnaire or a sales answer, the buyer can review an independent report. That report should describe the system, the period or point in time examined, the criteria in scope, the controls, the auditor's tests and the results.

It also matters for small and mid-sized organisations selling to larger buyers. A SOC 2 report can reduce procurement friction because it gives security and risk teams a familiar package of evidence. It will not remove every question, but it can move the conversation from "do you have controls?" to "what do your controls cover and are they sufficient for our use case?"

For AI specifically, SOC 2 should be read alongside AI governance evidence. A supplier may have strong general service controls but still need to explain model use, data retention, training-data commitments, human review, output limitations and how AI features are monitored.

This becomes more important as AI features are added to established products. A supplier may have had strong controls for its original service, then release AI functionality that changes data processing, subprocessors, logging or customer configuration. Buyers should ask whether the current SOC 2 report reflects that change or whether a bridge letter, updated report or additional explanation is needed.

How it works

A SOC 2 engagement examines controls relevant to selected trust services criteria. Security is the baseline category buyers most often expect to see. Availability, processing integrity, confidentiality and privacy may also be included depending on the service and the risks involved. The exact scope matters, because a report that covers one product, environment or criterion may not cover another.

A Type 1 report normally looks at the design of controls at a point in time. A Type 2 report normally covers both design and operating effectiveness over a period. Buyers often prefer Type 2 because it provides evidence that controls operated over time, but a Type 1 report can still be useful for a newer service or an earlier assurance stage.

When reviewing a SOC 2 report, a buyer should read more than the headline. The system description explains what service is covered. The criteria section explains which trust services categories are included. The control descriptions and testing results show what the auditor examined. Any exceptions or qualifications need careful review because they may point to control weaknesses, missing evidence or scope limits.

SOC 2 reports are not usually public marketing documents. They may be shared under non-disclosure because they contain detailed information about systems and controls. A public trust page may say that a supplier has a SOC 2 report, but the report itself is the evidence that procurement, legal, security or operations teams should examine.

Examples

A company wants to buy an AI meeting assistant that records, transcribes and summarises calls. A SOC 2 report can help the buyer understand access controls, encryption, monitoring, change management, incident response and availability controls around the service. It will not by itself answer whether meeting summaries are accurate or whether recording consent has been handled lawfully.

A team wants to connect an AI search tool to internal documents. SOC 2 evidence may support supplier assurance around infrastructure and confidentiality. The buyer still needs to check permissions, data boundaries, retention, retrieval behaviour and whether the tool respects existing access rules.

A SaaS vendor adding AI features may use SOC 2 to reassure customers that its service controls are independently examined. If those AI features rely on new subprocessors, new data flows or new environments, the vendor should be ready to explain whether the current report covers them or whether additional evidence is needed.

A small organisation buying a low-risk AI drafting tool may not need a full SOC 2 review. But if the same tool will process confidential customer data, regulated records or sensitive internal information, the assurance threshold should rise.

Common misunderstandings

  • SOC 2 is a certification. It is better described as an attestation report or assurance report, not a simple certification badge.

  • Any SOC 2 report covers everything. No. Scope, criteria, system boundaries, period covered and exceptions all matter.

  • SOC 2 proves an AI system is good. No. It examines controls relevant to selected trust services criteria. It does not prove model accuracy, business value, fairness or legal compliance.

  • SOC 2 replaces ISO 27001. No. They are different assurance routes. ISO 27001 is a management system standard. SOC 2 is an examination report against trust services criteria.

  • A trust page is enough. Not usually for higher-risk procurement. A trust page is a summary. The report and supporting answers are what matter.

Risks and boundaries

The main risk is treating SOC 2 as a yes-or-no checkbox. A supplier may have a report, but the report may not cover the product, region, hosting environment, AI feature, subprocessor or trust criteria the buyer cares about. Leaders should ask risk teams to read the scope before relying on the claim.

Another risk is ignoring exceptions. A report can include findings that matter to your use case. Some exceptions may be minor. Others may indicate a control gap that should change contract terms, launch timing, monitoring or the decision to proceed.

SOC 2 also has jurisdiction and market context. It is especially common in US-influenced SaaS procurement, but global buyers may use it alongside ISO 27001, privacy due diligence, penetration testing summaries, data processing agreements and sector-specific requirements.

For AI procurement, the boundary is important. SOC 2 can give assurance about the service organisation's controls, but it does not automatically cover AI-specific questions such as model evaluation, hallucination risk, prompt injection, output review, copyright exposure, bias, explainability or suitability for a particular workflow.

What to do next

When a supplier says it has SOC 2, ask for the report under NDA if the use case justifies it. Check whether it is Type 1 or Type 2, the period covered, the product or system in scope, the trust services criteria included, relevant subservice organisations, control exceptions and the auditor's opinion.

Then connect the report to the actual workflow. What data will the AI tool receive? Will it process personal, confidential or regulated information? Does it connect to internal systems? Does it create outputs that people may rely on? If the workflow risk is high, SOC 2 should be one part of a wider assurance pack, not the only control.

For suppliers, prepare buyer-ready answers that sit beside the report: AI feature scope, data retention, training-data commitments, subprocessors, security architecture, human oversight, incident notification and customer configuration options. That makes the SOC 2 evidence easier to interpret in an AI context.

Record the procurement decision in plain English. Note what the SOC 2 report covered, what it did not cover, which follow-up answers were received, which residual risks were accepted and who approved the use. That short record can be more useful later than a scattered email trail.

FAQs

What does SOC 2 stand for?

SOC is part of the AICPA System and Organization Controls suite. SOC 2 reports examine controls at a service organisation relevant to trust services criteria.

Is SOC 2 mandatory?

Usually no. It is often a buyer or market expectation rather than a law. Some contracts, sectors or enterprise buyers may require it as part of supplier assurance.

What is the difference between SOC 2 Type 1 and Type 2?

Type 1 usually reports on control design at a point in time. Type 2 usually reports on design and operating effectiveness over a period.

Is SOC 2 enough for AI procurement?

No. It is useful evidence for service controls, but AI procurement may also need privacy review, DPIA screening, model evaluation, output controls, data retention checks and workflow-specific risk assessment.

How does SOC 2 compare with ISO 27001?

ISO 27001 is an international information security management system standard. SOC 2 is an assurance report against trust services criteria for service organisations. Buyers may ask for either or both.

For AI-enabled services, the strongest review combines the report with workflow-specific questions about data use, customer configuration, model behaviour and human review.

Sources

‹ What is ROPA?

What is an SOP in AI-enabled work? ›