Does adding an AI feature invalidate our SOC 2 report?

It does not invalidate the report, but it can make the report irrelevant to the thing a buyer is asking about. A SOC 2 Type II opinion covers described controls over a defined system, during a defined observation period. A feature shipped after that period, running through a subprocessor not named in the system description, is simply outside what the auditor examined. The report remains accurate about what it covers; the problem is that it no longer covers your product as sold.

Is a model provider a subprocessor under our DPA?

If customer personal data is sent to it for processing on your behalf, yes — that is the ordinary definition, and it does not turn on whether the provider trains on the data. Most customer DPAs require either an up-to-date public subprocessor list with advance notice of additions, or prior written consent. Shipping an AI feature that routes customer content to a model provider you never listed is a contractual breach in many enterprise agreements even if the security posture is excellent.

What is the difference between the carve-out and inclusive methods for AI vendors?

Under the carve-out method, the subservice organization's controls are excluded from the description and the auditor's opinion, and the report instead lists complementary subservice organization controls that you assume are operating. Under the inclusive method, the subservice organization's controls are examined and covered by the same opinion. Nearly every SOC 2 that involves a large model provider uses carve-out, which means the report you hand a buyer explicitly does not opine on the AI provider's controls — a distinction sophisticated reviewers now look for.

Will a bridge letter cover an AI feature we shipped after the audit period?

No. A bridge or gap letter is management's assertion that no material changes to the control environment occurred between the report's period end and today. A new subprocessor and a new data flow is precisely a material change, so an honest bridge letter must disclose it rather than paper over it. Issuing a clean bridge letter that omits a new AI subprocessor is the kind of misstatement that damages credibility far more than the underlying gap.

Do we need ISO 42001 in addition to SOC 2?

Not usually, and not first. SOC 2 addresses security, availability, processing integrity, confidentiality, and privacy of a system. ISO 42001 addresses the governance of an AI management system — impact assessment, oversight, lifecycle management. They answer different questions, and most enterprise reviews in 2026 still gate on SOC 2 plus a completed AI-specific questionnaire. Pursue 42001 when buyers start asking for it by name or when regulated-sector deals stall on AI governance rather than on security.

SOC 2 and AI Subprocessors 2026: Why Your Report No Longer Covers Your Product

Three Separate Obligations, Routinely Confused

Teams treat "we're SOC 2" as a single fact that either holds or doesn't. Adding AI splits it into three obligations that fail independently and on different timelines.

The audit scope

What the auditor examined: a described system, over a stated observation period, against selected trust services criteria.

Fails when: The AI feature shipped after the period ended, or runs on infrastructure outside the described boundary. Nothing is wrong — it simply wasn't looked at.

The contractual commitment

What your DPA and MSA promise customers about subprocessors, data location, and change notice.

Fails when: A new model provider went live without the notice period your DPA requires. This is a breach question, not a security question, and it triggers regardless of posture.

The buyer's review

What a security reviewer asks during procurement, which increasingly exceeds both of the above.

Fails when: The questionnaire now asks about training use, retention of prompts, human review of flagged content, and model-level access controls that no SOC 2 criterion addresses directly.

What the System Description Has to Say Now

The system description is management's document, not the auditor's, and it is where AI changes show up first. If customer content reaches a model, the description needs to be honest about the following, because the auditor will test against what you wrote:

The boundary. Whether inference runs on infrastructure you control, on a cloud provider's hosted model service inside your existing boundary, or on a third-party API outside it.
The data flow. What customer content is sent, what is returned, what is persisted, and where embeddings and caches live.
The subservice organizations. Named, with the carve-out or inclusive treatment stated explicitly.
Complementary controls. What you are assuming the model provider does — and therefore what your report is not evidence of.
Change management for models. How a model version or provider swap gets reviewed, since this is the change type most likely to bypass your normal release process.

The Hosted-Model Shortcut

If your cloud provider is already a named subprocessor and you use their first-party hosted model service in the same region, you may add no new subprocessor at all — the data stays with an entity your customers already approved. That single architectural choice removes the DPA notice problem, shortens the questionnaire, and keeps the model inside a boundary your existing report already describes. It is usually cheaper than the compliance work required to add a new provider, and it is the first thing to evaluate before signing with a model vendor directly.

Reading a Vendor's SOC 2 for AI Coverage

This cuts both ways: you are being reviewed, and you are also relying on your own AI vendors' reports. Four checks separate a report that is evidence from one that is decoration.

1. Period end versus feature launch

Compare the observation period end date against the date the AI capability shipped. If the feature is newer than the report, the report says nothing about it.

2. The system description's boundary

Find the actual named systems. A report scoped to a vendor's core platform frequently excludes a newer AI product line sold under the same brand.

3. The subservice organization section

Identify which model providers are named and whether they are carved out. Carve-out is normal; the point is knowing your assurance chain stops there.

4. Exceptions and CSOCs

Read the testing exceptions in Section 4 and the complementary user entity controls. The latter is a list of things the vendor expects you to do — and unperformed CUECs are your gap, not theirs.

The Questions Enterprise Reviewers Actually Ask in 2026

Standard security questionnaires have grown an AI section, and it is not derived from trust services criteria. Have documented answers ready before the deal, because improvising them in a live call is where timelines slip.

Data Handling

Is customer content used to train or fine-tune any model, ours or a third party's?
How long are prompts and completions retained, and by whom?
Does any human review customer content, including for abuse or safety monitoring?
Can inference be routed outside the contracted region during a capacity event?
What happens to embeddings, caches, and fine-tuned artifacts on deletion request and on termination?

Isolation and Access

How is one tenant's content prevented from surfacing in another tenant's outputs?
If you use retrieval, are permissions enforced at query time or only at index time?
Who at your company can read prompts and completions, and is that access logged?
Are model API credentials scoped and rotated like other production secrets?

Change and Oversight

How do we learn about a model version change or a provider swap?
What is your notice period for adding a subprocessor, and where is the list published?
What human oversight exists for outputs that affect customers materially?
How do you evaluate and monitor output quality, and what is the rollback path?

The Retrieval Permission Failure

One gap deserves separate attention because it is common, invisible in a SOC 2, and catastrophic when a customer finds it. Retrieval systems typically index documents once and filter at query time — or, in many first implementations, do not filter at all.

The result is an assistant that will summarize a document the asking user has no right to open. No access control was bypassed in the traditional sense; the index simply became a parallel data store with weaker permissions than the system of record. Enforce authorization at query time against live permissions, and re-check on document permission changes rather than only on re-index. This is now a standard penetration test target and a standard questionnaire item.

Frequently Asked Questions

Can we just add the AI feature to next year's audit and say nothing until then?

You can delay the audit scope change, but not the contractual one. Subprocessor notice obligations in your DPA run on their own clock and are usually breached at launch, not at renewal. The workable sequence is: update the public subprocessor list and send notice, update the system description and DPA, then bring the feature into the next observation period. Disclose the gap proactively during reviews in the interim — reviewers accept a known, documented gap far more readily than one they discover.

Our AI feature is opt-in and most customers don't use it. Does that reduce scope?

It can, and saying so precisely helps. If the feature is off by default, the data flow only exists for tenants who enabled it, and you can describe it as a distinct optional component with its own controls. What does not work is treating opt-in as a reason to omit it from the description entirely, since the capability exists in the production system and an auditor who finds it undescribed will question the description's completeness overall.

Do we need to list the model provider if we access it through another vendor?

Your customers need to know where their data goes, and a nested chain does not remove that. Practice varies on whether you list the sub-subprocessor by name or list your direct vendor and point to their published list, but enterprise reviewers increasingly ask for the full chain explicitly. The safer posture is naming it, because discovering an unnamed link during diligence reads as concealment even when it was only convention.

How do we handle a model provider changing terms mid-contract?

Assume it will happen and instrument for it. Assign an owner to review each AI vendor's data processing terms on a fixed cadence rather than at renewal, subscribe to their changelog, and re-verify training opt-out settings after major releases since defaults change and features occasionally move between pricing tiers. Where your customer commitments are stricter than what a provider will contractually guarantee, that difference is a risk you are absorbing and should be recorded as such.

Is Type I enough if we just launched the AI feature?

It is a reasonable interim step and better than nothing, but understand what it buys. Type I opines on the suitability of design at a point in time; Type II opines on operating effectiveness over a period. Sophisticated buyers know the difference and will typically accept a Type I only with a committed date for the Type II covering the new scope. For a newly shipped feature on a mature platform, most companies bridge with a documented gap disclosure and fold the feature into the next Type II window instead.

Fix the Subprocessor List Before the Audit

Of the three obligations, only one is already in breach the day you ship: the contractual one. Audit scope catches up at the next observation period, and buyer questionnaires only bite when a deal is live — but a missing subprocessor notice is a promise you have already failed to keep, to every customer whose DPA required it.

Publish the updated list, send the notice, then write the data flow down honestly in the system description. Everything else — the questionnaire answers, the retrieval permission fix, the next Type II scope — is easier once that document reflects what your product actually does.