How to Read a SOC 2 Report When Assessing AI Vendors

TL;DR. A SOC 2 report from an AI vendor is one input into a third-party risk assessment, not the assessment itself. Type I describes design at a point in time; Type II describes operating effectiveness over a period. The Trust Services Criteria scope, the period covered, the CUECs (Customer User Entity Controls), and any subservice organization carve-outs determine what the report actually proves. Receiving a SOC 2 is not the same as verifying it.

1. What SOC 2 is and is not

SOC 2 (Service Organization Control 2) is an attestation report under AICPA standard SSAE 18. It is not a certification. The auditor (a CPA firm) opines on whether the service organization's controls meet the Trust Services Criteria selected for the engagement.

SOC 2 reports do not certify compliance with EU AI Act, GDPR, DORA, ISO 27001, or BSI C5. They do provide evidence that may be used as input to those assessments, with caveats.

For the broader vendor-assessment framework, see the EU AI Act Third-Party Risk pillar.

What a SOC 2 report contains:

The deviations in Section V are where most assessors stop too soon. A SOC 2 with three exceptions in access-management testing is not necessarily disqualifying — but it must be read against the AI vendor's actual exposure.

2. Type I vs Type II — what each one proves

A Type I is the equivalent of a vendor showing you their security policy: it says what they intend to do. A Type II is the equivalent of an auditor checking whether they actually did it.

For an AI vendor at the start of its compliance journey, Type I may be the only available report. For an AI vendor sold into DACH-regulated buyers, Type II covering at least 6 months is the working minimum. A Type II covering only 3 months with a "transition period" caveat is a soft Type I with marketing.

3. The five Trust Services Criteria — and which apply to AI vendors

The Trust Services Criteria are organised into five categories. Security is mandatory in every SOC 2; the other four are optional and selected by the service organization.

Most AI vendor SOC 2 reports cover only Security. Some cover Security + Availability. Confidentiality and Processing Integrity coverage is rarer and more interesting.

The procurement question to ask: "Does your SOC 2 cover Confidentiality and Processing Integrity?" If only Security is covered, the report tells you nothing about whether the vendor's AI handles confidential customer data correctly or produces complete and accurate outputs.

4. CUECs — the controls you have to implement

Customer User Entity Controls (CUECs) are the controls that the SOC 2 report assumes the customer (you) will implement. The auditor's opinion on the service organization's controls depends on these complementary controls being in place at the customer side.

CUECs typically appear in a dedicated subsection within Section III or IV. Common CUECs in AI-vendor SOC 2 reports include:

• Customer is responsible for managing user access provisioning/deprovisioning to the service
• Customer is responsible for configuring data classification appropriately
• Customer is responsible for maintaining the confidentiality of API keys and credentials
• Customer is responsible for ensuring that data submitted to the service does not exceed the data-classification scope of the engagement
• Customer is responsible for the lawful basis of processing under applicable privacy laws
• Customer is responsible for monitoring the service for unintended use or abuse

For AI vendors specifically, the CUEC list often includes:

• Customer is responsible for evaluating outputs of the AI service before relying on them
• Customer is responsible for ensuring training/fine-tuning data does not contain prohibited categories
• Customer is responsible for end-user notification where required by law

If the SOC 2 includes CUECs that you have not implemented, the auditor's opinion does not extend to the gap. Documenting which CUECs apply and which you have implemented (or compensated for) is part of the deployer's Article 26(2) human-oversight evidence under the EU AI Act.

5. Reporting period freshness — when SOC 2 expires in practice

A SOC 2 Type II covers a defined audit period. There is no formal expiry, but practical freshness norms are:

A bridge letter (also called a gap letter) is an attestation from the service organization that no material changes have occurred between the report period end and the current date. The bridge letter is signed by management, not by the auditor. It is not a substitute for a fresh SOC 2 — it is a stop-gap.

For DACH financial-services procurement, the working norm is: SOC 2 Type II with period ending within the last 12 months, plus bridge letter if more than 90 days out. Anything weaker requires compensating diligence. See the DORA + EU AI Act cluster for how this fits a financial entity's TPRM register.

6. Subservice organizations — the carve-out trap

When the service organization relies on subservice organizations (e.g. cloud infrastructure, payment processors, GPAI model providers), the SOC 2 handles them via two methods:

Almost every AI vendor SOC 2 in 2026 uses carve-outs for AWS, Azure, GCP, and the underlying GPAI provider. The carve-out section will list complementary subservice organization controls (CSOCs) that the vendor expects the subservice to perform.

Procurement diligence on a carved-out vendor SOC 2 means:

1. Identify each named subservice organization
2. Obtain the subservice's own SOC 2 (or equivalent — ISO 27001, BSI C5, etc.)
3. Verify the CSOCs listed in the vendor's SOC 2 are covered in the subservice's SOC 2
4. Document the chain

A vendor SOC 2 with three carve-outs and no obtained subservice reports is one report with three holes. This is where most SOC 2 reviews silently fall short.

7. What SOC 2 cannot tell you about an AI vendor

A SOC 2 report does not assess:

• EU AI Act classification of the vendor's AI system
• Annex III applicability
• GPAI dependency or systemic-risk GPAI flagging
• Adversarial robustness of the AI (no red-teaming in scope)
• Hallucination rate, bias on protected groups, multilingual edge cases
• Copyright posture of training data
• Article 13 instructions-for-use completeness
• DORA Article 30 contract-clause sufficiency
• BaFin MaRisk AT 9 significant-outsourcing classification
• BSI C5 specific controls

A complete AI vendor assessment needs all of these on top of SOC 2. For comparison of how purely SOC 2-driven TPRM platforms handle this gap, see the PartnerScope vs Vanta comparison and the PartnerScope vs Drata comparison.

8. The SOC 2 reading checklist

A defensible SOC 2 review for an AI vendor produces documented findings on: type and period covered; auditor name and opinion; Trust Services Criteria scope; subservice organizations and treatment (inclusive / carve-out); obtained subservice attestations for each carve-out; testing exceptions and severity; bridge-letter status; CUECs list and your implementation status; AI-specific controls (model deployment, training-data handling, change management for model updates); gap to EU AI Act / DORA / BSI C5 expectations; and freshness assessment.

If any of these cannot be answered from the report on file, the report has been received but not verified.

9. Frequently asked questions

Is SOC 2 Type II equivalent to ISO 27001 certification? No. SOC 2 is an attestation by a CPA firm; ISO 27001 is a certification by an accredited certification body. SOC 2 reports describe the controls and the auditor's testing; ISO 27001 certification confirms conformance to the standard plus a Statement of Applicability. They are complementary; many DACH buyers want both. See the BSI C5 vs SOC 2 vs ISO 27001 cluster.

Does a SOC 2 satisfy GDPR Art. 28 due-diligence requirements for processors? Not on its own. GDPR Art. 28(1) requires sufficient guarantees that the processor will implement appropriate technical and organisational measures. SOC 2 Type II covering Security and Privacy is a strong input, but the controller still needs to verify Art. 28-mandated DPA clauses, sub-processor consent mechanisms, and TIA where applicable.

My AI vendor's SOC 2 covers only Security. Should I reject the vendor? Not automatically. Security-only is the common starting posture for early-stage AI vendors. Decide based on the AI's exposure: if the system processes confidential customer data, push for Confidentiality coverage in the next audit cycle. If outputs feed regulated decisions, push for Processing Integrity. Document the gap as residual risk with a remediation deadline.

How does SOC 2 differ from the Annex IV technical file under EU AI Act? SOC 2 documents controls; Annex IV documents the AI system itself (architecture, training data, intended purpose, performance, risk management). They are non-overlapping. A vendor with a strong SOC 2 and no Annex IV technical file is non-compliant with EU AI Act Art. 11 if the system is high-risk.

Where does SOC 2 fit in the 13-dimension PartnerScope scorecard? Dimension 3 (Security certifications) captures SOC 2, ISO 27001, and BSI C5 with type, scope, period, exceptions, and carve-outs analyzed. Dimension 12 (Documentation completeness) captures the related artefacts (DPA, AUP, sub-processor list, SBOM). The two dimensions together form the documentary backbone of every PartnerScope assessment.

CTA

Run a free 60-second EU AI Act Snapshot at partnerscope.eu and let our framework verify your AI vendor's SOC 2 against the gaps that matter for EU AI Act, DORA, and BSI C5. Or read the complete pillar guide.