What should teams consider when using a model provider in SOC 2 scope?

What teams need to establish before relying on a model provider in scope

The key question is not just whether the provider is “SOC 2 compliant,” but whether its services, controls, and contractual terms actually support the assurance claim you are making about your own system. Teams should confirm what data the provider retains, how incidents are notified, whether training-use restrictions are explicit, and which controls sit inside the examined boundary versus outside it as a dependency.

That distinction matters because a provider can be relevant to your risk posture without being fully covered by the report. If the provider is only a dependency, your own controls and disclosures need to absorb the gap. For scoping and carve-out discipline, SOC 2 Guide is the most direct internal reference.

When the provider handles prompts, outputs, logs, or embedded customer data, the practical issue is whether those artefacts can be retained, inspected, or repurposed in ways that change confidentiality or processing integrity expectations. A report that is silent on those points leaves you to rely on assumptions that may not match the actual service terms or operational model.

How to assess the report boundary and the provider dependency

Start by separating the provider’s own control environment from the specific service you consume. In SOC 2 scope, a model provider may have strong company-wide controls while the exact product you use is covered only indirectly, or with exclusions. That is where complementary user entity controls, shared-responsibility assumptions, and report carve-outs become operationally important.

Teams should also check whether the provider’s access controls are sufficiently specific for the use case, especially where admin access, support access, or logging access could expose prompts or outputs. If the provider supports multiple tenants, training workflows, or human review paths, the report should make clear how customer data is separated and who can reach it.

Where the provider is part of a larger AI stack, it helps to evaluate whether the real risk sits with the model service itself or with adjacent systems such as gateways, orchestration layers, or downstream storage. That broader view reduces the chance of treating the report as stronger evidence than it actually is. The Third-Party AI Risk Guide is useful here because it frames provider scoping, retention clauses, and deployer duties together.

What good control evidence looks like for model providers

Good evidence answers practical questions rather than using generic compliance language. Teams should look for stated retention periods, customer-configurable data use terms, incident notification timelines, support-access restrictions, and an explicit description of whether model interactions are used for training, fine-tuning, abuse monitoring, or human review. If those details are not present, the report may still be useful, but it is not enough on its own for a confident scope decision.

Evidence should also show how the provider limits privileged access, handles support investigations, and records exceptions. For many buyers, the most useful signal is not a broad “yes” to control existence, but whether the report and contract together let you prove your own obligations, especially where the provider handles sensitive data or operational secrets. For broader access and privilege context, the Privileged Access Management Guide and the Authorisation Models Guide map well to the control decisions teams usually need to make.

Risk and Threat Considerations

Model providers can create assurance gaps when customer data is retained longer than expected, reused for training, or exposed through support processes and logs. The main risk is not only misuse by the provider, but also mis-scoped assurance, where your SOC 2 story implies stronger control coverage than the examined system actually has.

Failure mechanism: A provider dependency is treated as if it were fully in scope, while carve-outs, shared controls, or training-use terms leave unexamined exposure around stored prompts, outputs, and support access.

Impact: The organisation may misstate its control environment, miss a confidentiality or incident-notification gap, and inherit obligations that were never contractually or operationally covered.

Practitioner Guidance

What to verify: Confirm the exact wording on retention, training use, support access, incident notice, and data deletion, then compare it to the assurance claim you intend to make. If the contract is more precise than the report, the contract should drive your operating assumption.

Decision rule: If the provider’s controls are not explicitly inside the examined boundary, treat them as a dependency and add your own compensating controls, evidence collection, and customer disclosures rather than assuming the report covers the gap.

What practitioners underestimate: The hardest failure is usually not a missing control, but a boundary mismatch between the report, the contract, and the actual data path. That mismatch is what turns a “covered” provider into an unexamined risk.

Practitioner takeaway: In SOC 2 scoping, the quality of the assurance depends less on the provider’s brand and more on whether the report, contract, and operating model all describe the same control boundary.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for SOC 2 compliance?
• Why do rate limits and shared quotas create operational risk for teams using a single model provider across multiple services?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?