Is an AI model provider part of my SOC 2?

Yes, if your product sends customer data to it. A model provider such as OpenAI, Anthropic or Google receives customer data on your behalf, which makes it a vendor under the SOC 2 vendor management criteria and usually a subprocessor your customers will want named.

What will a SOC 2 auditor ask about a model provider?

What data goes to it, whether you obtained and reviewed its SOC 2 report, what customer controls that report expects you to run such as protecting API keys and managing console access, and what your contracts say about data use, retention and incident notice.

Does the model provider's SOC 2 report cover my product?

No. Their report covers their systems. It says nothing about what data you send them, who on your team holds the API keys, or whether your contracts allow what you are doing.

Do fallback model providers count?

Yes. If your product falls back from one provider to another, or routes through a proxy or a cloud marketplace, every path the data can take counts, even one used rarely.

AI Companies · Vendor Risk

SOC 2 for AI startups, and what to do about the model providers

Control and Function · October 2026

If your product sends customer data to OpenAI, Anthropic, Google or anyone else’s model, that provider is part of your SOC 2. Not as a footnote. It sits in the same place your cloud host does, and the auditor will ask the same questions about it.

Most AI startups find this out late. Here’s how to get ahead of it.

The model provider is a vendor that touches customer data

SOC 2 cares about where your customers’ data goes and who can see it. When a user types into your product and you pass that text to a model, the data has left your system and entered someone else’s. That makes the model provider a vendor with access to customer data, which is exactly what the vendor management criteria are about.

It usually makes them a subprocessor too, in the privacy sense: a third party that processes your customers’ data on your behalf. Your customers’ security teams will want to know who those are, by name.

What the auditor will ask

For each model provider, expect some version of these:

What data goes to them? Not “user prompts” in general. What fields, from which features, with or without names and emails.
Do you have their SOC 2 report, and did you read it? Holding the PDF is not the same as reviewing it. The auditor wants to see who reviewed it, when, and what they concluded.
What does their report expect you to do? Every vendor report lists controls it assumes the customer runs. For model providers these are usually things like protecting your API keys, managing who can access the provider’s console, and turning on MFA. If you aren’t doing them, their report doesn’t cover as much as you think. (More on this in the CUECs guide.)
What do your contracts say? Data use, retention, whether your data trains their models, and how they notify you of an incident.

The four things to have in place

1. A written list of what goes where. One table: each model provider, what data it receives, from which feature, and whether personal identifiers are stripped first. This is the single most useful document you can write. It answers the auditor, it answers your customers’ vendor reviews, and it forces you to find the feature nobody remembered sends email addresses along.

2. A public subprocessor list. If you sell to banks, hospitals or universities, their vendor review will ask for it. A privacy policy that names your hosting provider but not the model providers your product actually calls is the gap they’ll find first.

3. A recorded review of each provider’s report. Once a year, someone reads it, checks the period covers yours, checks the opinion was clean, maps the customer controls it lists to what you actually do, and writes down the result. A short page per vendor is enough.

4. Access to the provider accounts in your access review. Teams review AWS and GitHub access every quarter and forget the model provider consoles entirely. Those consoles hold your API keys and often your usage logs. Add them to the same review.

Fallbacks and routers count too

If your product falls back from one provider to another when the first is slow, or routes through a proxy or a cloud marketplace, every path the data can take counts. A fallback provider that only sees traffic one day a month still receives customer data. List it.

What doesn’t help

Assuming the provider’s SOC 2 covers you. Their report covers their systems. It says nothing about what you send them, who on your team holds the keys, or whether your contracts allow what you’re doing.

Treating “we don’t train on your data” as the whole answer. Training is one question. Retention, access, incident notice and where the data is processed are others, and a bank’s reviewer will ask all of them.

Leaving it for the system description. The system description has to say which vendors are part of the system and how you oversee them. If the list and the reviews don’t exist yet, that section can’t be written honestly.

Where to start

Write the table in step 1 this week. It takes an afternoon and everything else builds on it. If you want a second set of eyes on it, or on how your model providers will look to an auditor, that’s the kind of thing a readiness review covers.

Anthony Proctor runs Control and Function, a SOC 2 readiness practice. He ran a SOC 2 Type I program end to end as the sole IT operator at a prior company, where a licensed CPA firm performed the attestation. Control and Function is not an audit firm and does not audit its own preparation work.

Talk through your model providers →

Complementary User Entity Controls, and why holding a vendor’s SOC 2 is not reviewing it
What every vendor report expects you to do, and how to map it before an auditor asks.

What a bank third party risk review actually asks for
If banks are your buyers, this is the review your subprocessor list goes into.