AI Vendors in Your SOC 2 Scope: 2026 Auditor View
Quick Answer
Yes. If you send customer data to an AI API such as OpenAI, Anthropic, or a third-party AI feature embedded in a SaaS tool, that provider is a subservice organisation and falls inside your SOC 2 scope. Auditors expect you to identify every AI vendor touching in-scope data, document the nature of that processing, and produce evidence of vendor risk assessment, data handling agreements, and ongoing monitoring, the same way they would for any other subprocessor.
AI vendors SOC 2 scope is a question we are being asked in nearly every audit readiness call in 2026. Companies quietly wired an AI API into a support tool, a coding assistant, or a customer facing feature over the past two years, often without routing that decision through procurement or security review. Now the SOC 2 auditor is asking for the vendor list, and the AI provider is not on it.
Having supported SOC 2 compliance engagements where AI vendors were flagged mid-audit as an undisclosed subservice organisation, CyberSapiens has seen how much time this costs when it is caught late. The fix is not complicated, but it does need to happen before the audit starts, not during it. This guide sets out exactly how auditors classify AI APIs, what a proper vendor review checklist looks like, the evidence you will be asked to produce, and how to structure an AI vendor policy your auditor will accept on first read.
Review Checklist for AI Vendors
Treating an AI API the same way you treat any other subservice organisation is the fastest way to close this gap. The checklist below is what we walk clients through before an AI vendor is allowed anywhere near in-scope data.
Before an AI Vendor Enters Your SOC 2 Scope
- Identify exactly what customer or company data the AI vendor’s API receives or processes.
- Confirm whether the vendor uses submitted data to train its own models, and get this in writing.
- Review the vendor’s own compliance posture, including any SOC 2 report, ISO 27001, or ISO 42001 certification.
- Confirm a signed Data Processing Agreement or equivalent contractual data protection terms is in place.
- Document data residency and any cross-border transfer arrangements the vendor relies on.
- Assess whether the vendor has sub-processors of its own that also need to be disclosed.
- Set a review cadence, annually at minimum, to reassess the vendor as terms or usage change.
The NIST AI Risk Management Framework takes the same view, treating third-party AI systems as a distinct risk category that needs its own governance rather than being folded into generic vendor management. In our engagements, step three above, checking whether the vendor trains on submitted data, is the one item companies skip most often, and it is almost always the first question a SOC 2 auditor raises once an AI vendor is disclosed.
Evidence Auditors Ask For
The AICPA treats any third party that supports your in-scope services as a subservice organisation, and an AI vendor is no exception once it touches customer or company data. Once an auditor confirms an AI vendor is in scope, they will typically request the same categories of evidence, laid out below.
| Evidence Category | What Auditors Want to See |
|---|---|
| Vendor inventory | A documented list of every AI vendor with access to in-scope data, including embedded AI features inside third-party SaaS tools |
| Risk assessment records | A completed risk assessment for each AI vendor, dated and tied to onboarding or contract renewal |
| Contractual agreements | Signed Data Processing Agreements or equivalent clauses covering data use, retention, and model training restrictions |
| Vendor’s own attestations | Copies of the AI vendor’s SOC 2 report, ISO 27001 certificate, or ISO 42001 certificate where available |
| Ongoing monitoring log | Evidence of periodic re-review, such as an annual reassessment or a record of a vendor’s terms-of-service change being flagged and evaluated |
According to the AICPA, a service organisation can address subservice organisations through either the carve-out or inclusive method, and most companies use the carve-out method for AI vendors, meaning the vendor’s own controls sit outside your report but you must still evidence the complementary controls you rely on. In our GRC engagements, the vendor inventory is almost always the first artifact missing, simply because AI tools were adopted faster than the procurement process could track them.
Policy Template Outline
Auditors do not just want to see that you reviewed your AI vendors once. They want a documented policy showing the review is a repeatable, governed process. Below is the structure we use when building an AI Vendor Governance Policy for a SOC 2 audit.
Purpose and Scope
Defines what counts as an AI vendor for this policy, including standalone AI platforms, embedded AI features in existing SaaS tools, and internally built tools calling a third-party AI API.
Approval and Onboarding Process
Sets out who must approve a new AI vendor before it touches company or customer data, and requires the checklist from the previous section to be completed and filed before onboarding is signed off.
Data Handling and Training Restrictions
States your organisation’s position on whether vendor data may be used for model training, what data classifications are permitted to be sent to any AI vendor, and how exceptions must be requested and logged.
Ongoing Monitoring and Reassessment
Assigns an owner and a minimum annual cadence for reassessing each AI vendor, and requires a trigger-based review whenever a vendor materially changes its terms of service or data handling practices.
Incident and Offboarding Procedure
Describes how a data incident involving an AI vendor is escalated and reported, and the steps required to fully offboard a vendor, including confirming deletion of any data previously shared.
A policy with these five sections, backed by the vendor inventory and evidence log from the previous sections, is what we have found satisfies auditors reviewing AI vendor governance for the first time in a SOC 2 cycle.
Content Reviewed By
Ketki Tidke
Cyber Security and GRC Lead Auditor — ISO 27001 Lead Auditor
Ketki is a certified ISO 27001 Lead Auditor specialised in Governance, Risk and Compliance, with experience consulting public, private, and government clients. She evaluates threats, risk impacts, and regulatory requirements across multiple industry frameworks.
Frequently Asked Questions
Are AI vendors like OpenAI or Anthropic considered subservice organisations under SOC 2?
Yes, if the AI vendor’s API processes data that supports your in-scope services, it meets the AICPA’s definition of a subservice organisation, the same way a cloud host or payment processor would. This applies whether you call the API directly or use it through an embedded feature in another SaaS product.
What happens if we do not disclose an AI vendor and the auditor finds it later?
An undisclosed vendor discovered mid-audit typically causes a scope expansion, additional evidence requests, and delays to your report delivery date, and in some cases can result in a qualified opinion if the risk cannot be adequately addressed before the audit period closes. Identifying AI vendors early through a GRC review avoids this entirely.
Do we need a Data Processing Agreement with every AI vendor?
Yes, any AI vendor processing customer or company data should have a signed Data Processing Agreement or equivalent contractual terms in place before go-live, covering data use, retention, and whether the vendor may use your data for model training.
Should we use the carve-out or inclusive method for AI vendors in our SOC 2 report?
Most organisations use the carve-out method for AI vendors, since it excludes the vendor’s own controls from your report while still requiring you to document and evidence the complementary controls you rely on, such as reviewing the vendor’s own SOC 2 or ISO certification.
How often should we reassess our AI vendors once they pass the initial review?
At minimum, annually, aligned to your SOC 2 audit cycle. AI vendors change their terms of service, data handling practices, and sub-processor relationships more frequently than traditional vendors, so a trigger-based review whenever a vendor announces a material change is also recommended.
Scope Review
Not sure which of your AI vendors belong in your SOC 2 scope, or whether your current documentation would hold up under an auditor’s questions? Our team will review your AI vendor list, flag gaps against the evidence auditors ask for, and help you build a policy that passes on first read.
Get a Scope Review