What Actually Enters SOC 2 Scope When You Automate With AI

On September 2, 2026, Anthropic announced a way to keep customer data out of its own infrastructure entirely. It requires an application. It only covers one model. The one everyone will actually use by default is still on a 30-day retention window. If your SOC 2 plan for AI vendors is "check whether they offer zero retention," you are answering a question the auditor did not ask.

This is the second piece in the AI governance series, the audit-scope surface named in the opening piece. That piece argued governance is four operating surfaces, not a policy document. This one takes apart the surface everyone gets backwards first: which vendors are in scope, how they get there, and what a retention headline actually changes about that.

Zero retention is a setting, not a scope decision

On September 2, 2026, Anthropic announced Enterprise Frontier Safeguards, a zero-retention option for its Fable 5.1 model available through Claude Code, Claude Enterprise, the Claude Platform, Amazon Bedrock, and several partner platforms. The detail that actually matters for an audit: data is stored in infrastructure the customer controls, not Anthropic's. That is a different claim than "we delete it after processing," and it changes where the boundary of your own system sits more directly than a retention promise does.

It also is not automatic. It requires an application. It does not apply to Anthropic's Mythos model, which stays on the standard 30-day API retention window. OpenAI's version requires an Enterprise Agreement or Microsoft Customer Agreement, goes through sales approval, and is granted endpoint by endpoint rather than account-wide, currently covering chat completions, the responses API, batch API, and embeddings. Google maintains a no-training default on its enterprise Gemini API but that is a training policy, not a retention architecture, and it is a separate claim from either.

None of that is a criticism of any of the three. It is the actual shape of the thing: a setting you apply for, scoped to a specific model or endpoint, that can be revoked or simply not renewed. A control that lives entirely inside a vendor's dashboard, outside your own audit evidence, is not a control you can point to during your own audit. It is a claim about your vendor, not a fact about your system.

The question underneath: carve-out or inclusive

Every AI model provider your company touches is a subservice organization under AICPA's Trust Services Criteria, the framework SOC 2 audits run against. CC9.2 requires that you assess and manage risk from vendors and business partners, and for each one you pick one of two ways to bring it into your audit.

Carve-out excludes the vendor's own controls from your report. You name the vendor as a Complementary Subservice Organization Control, a disclosure that says what you expect them to be doing on their end, and your auditor does not test their systems directly. You are still on the hook for obtaining and reviewing that vendor's own SOC 2 report annually. Inclusive brings the vendor's controls directly into your audit scope, with your auditor testing them as if they were part of your own environment.

For a foundation model provider, inclusive is rarely realistic. Getting OpenAI, Anthropic, or Google to cooperate with a detailed control review on your audit's timeline is not something most companies are big enough to demand. Carve-out ends up the default by necessity, which means the actual work is not picking a method. It is doing the part carve-out still requires: getting the vendor's SOC 2 report, reading it, and keeping a dated record that you did.

What a subprocessor list has to actually track

A Data Processing Agreement without a current subprocessor list is a document, not a control. Enterprise buyers increasingly ask for both, and for AI-specific procurement in 2026 that list now has to answer a question that did not used to be on it: which of your subprocessors are model providers, and what is their training and retention configuration.

For each subprocessor, the working version of that list tracks the vendor name, the service it provides, the categories of data it touches, DPA status, and the expiry date on its own certifications. An AI model provider belongs on that list as a subprocessor, not as part of your own system boundary. Your SOC 2 attests to your controls over how you use the provider, not to the provider's infrastructure. That distinction is the entire practitioner answer to "are we covered": you are never covered by a vendor's policy page. You are covered by your own documented decision about that vendor, dated and reviewable.

Why this is the practitioner answer, not the theoretical one

I am not writing this from a policy page. I recently took an AI platform I operate through SOC 2, and the distinctions in this piece, carve-out versus inclusive, what a retention announcement does and does not do, what actually belongs on a subprocessor list, are the ones I had to work through directly, not ones I am reciting from a compliance vendor's blog.

That is the honest version of this surface. A retention announcement from a model provider is real news and worth tracking the day it lands. It is not evidence for your own audit until you have made and documented the scoping call underneath it. As of this writing, most companies using Fable 5.1 have not applied for the zero-retention option, and the ones who have still owe their auditor the same carve-out documentation as everyone else. The setting changed. The scope decision did not make itself.

What this means for the rest of the governance series

This surface connects directly to the other three in this series. The access surface, coming next, is what actually determines whether a model provider can reach data that makes the retention question matter in the first place. The logging surface is what lets you prove, months later, which configuration was active when a specific output was generated, since a zero-retention setting applied today says nothing about what was true in March. And the review surface is where a human actually has to sign off that the carve-out documentation exists rather than assuming legal handled it, which is the same accountability gap I mapped in who should own AI: CAIO vs CTO vs CIO. A vendor scoping decision with no named owner is not a decision. It is a hope. None of the four surfaces substitute for each other, and none of them are optional because a vendor shipped a good headline.

The series

Six pieces, publishing weekly:

AI Governance for Commercial Teams: the operating system, not the policy PDF.
What Actually Enters SOC 2 Scope When You Automate With AI: the audit-scope surface. This piece.
The Human Gate That Isn't a Rubber Stamp: the review surface. September 10.
What to Connect and What to Refuse: the access surface, MCP connectors. September 15.
The AI Audit Log: the logging surface, reconstructing why the model said that. September 17.
AI Vendor Review: where your data actually goes. September 22.

The discipline underneath all six is the same one behind AI Commercialization: the complete guide. The technology proving it runs and the business proving it is under control are two different claims, and this piece is the difference written out as a compliance checklist instead of an argument.

Frequently asked questions

Does an AI vendor's zero data retention policy remove it from SOC 2 scope?

No. Zero retention changes what the vendor stores. It does not change whether the vendor is a subservice organization under AICPA's Trust Services Criteria, and it does not decide which of the two scoping methods, carve-out or inclusive, you use for it. A vendor with zero retention still has to be identified, risk-assessed under CC9.2, and documented one of those two ways. Zero retention makes that vendor easier to defend in an audit. It does not make the scoping decision for you, and it is rarely automatic: OpenAI's zero data retention requires an Enterprise Agreement and sales approval per endpoint, and Anthropic's newest option, announced September 2, 2026, requires an application and only covers specific models.

What is the difference between carve-out and inclusive method for AI subservice organizations?

Carve-out excludes the AI vendor's own controls from your SOC 2 report. You disclose the vendor as a Complementary Subservice Organization Control, meaning you name what you expect them to be doing, and your auditor does not test their systems directly. You still have to obtain and review the vendor's own SOC 2 report annually under CC9.2. Inclusive brings the vendor's controls directly into your audit, with your auditor testing them as an extension of your own environment. Most companies default to carve-out for AI model providers because getting a foundation model provider to cooperate with an inclusive audit, sharing detailed control evidence on your timeline, is rarely realistic.

What did Anthropic and OpenAI actually announce about zero data retention?

On September 2, 2026, Anthropic announced Enterprise Frontier Safeguards for its Fable 5.1 model, available through Claude Code, Claude Enterprise, the Claude Platform, Amazon Bedrock, and several partner platforms. The distinguishing detail is that data is stored in infrastructure the customer controls, not Anthropic's, which changes the audit boundary more directly than a retention promise does. It requires an application and does not apply to Anthropic's Mythos model, which stays on the standard 30-day API retention window. OpenAI's zero data retention requires an Enterprise Agreement or Microsoft Customer Agreement, sales approval, and is granted endpoint by endpoint, currently covering chat completions, the responses API, batch API, and embeddings.

What does a Data Processing Agreement need to cover for an AI vendor?

A complete DPA, a current subprocessor list showing where data is geographically processed, evidence of a SOC 2 Type II report or equivalent, and a completed security questionnaire, commonly the CAIQ framework. For each subprocessor on that list, track the vendor name, the service it provides, the categories of data it touches, DPA status, and the expiry date on its own security certifications. An AI model provider is a subprocessor, not part of your own system boundary. Your SOC 2 attests to your controls over how you use that provider, not to the provider's infrastructure.

Has the author actually taken a company through SOC 2?

Yes. An AI platform I operate completed SOC 2. This piece is written from that experience rather than from a compliance vendor's checklist. The distinctions covered here, carve-out versus inclusive, what a zero-retention announcement does and does not do, what a subprocessor list has to track, are the same ones that had to be resolved in that process.

Sources

AICPA Trust Services Criteria and CC9.2 vendor risk requirements: Katz, Sapper & Miller, "What's New With SOC 2: Updated AICPA Guidance" (2017 Trust Services Criteria with points-of-focus revised September 2023; no new criteria issued for 2025 or 2026). Carve-out versus inclusive method for subservice organizations: Linford & Company, "Carve-Out vs Inclusive Method: SOC 2 Subservice Audits" (Linford is a CPA firm performing SOC 2 audits; checked September 2026). Anthropic's Enterprise Frontier Safeguards announcement: The Register (published September 2, 2026). OpenAI's zero data retention eligibility and endpoint scope: OpenAI, "Offering Zero Data Retention for Frontier Models" (OpenAI's own page; checked September 2026). DPA and subprocessor list requirements for AI vendors: Coworker AI, "Enterprise AI Platforms with SOC 2 Compliance" (checked September 2026).

About the author

Jeff Brokaw is a sitting CMO and Certified Chief AI Officer who ships AI in production, not slideware. He has been building AI systems commercially since 2016. He built the commercial engine behind $185M in new-business revenue for a defense manufacturer, and authored the go-to-market behind a $114M institutional raise that came together in under 30 days.