Enterprise Governance & Risk

Vendor Risk Assessment for AI Providers

Adding Claude through a cloud platform is still a vendor decision — sometimes two vendor decisions at once. Here is what to verify, with whom, before the security questionnaire goes out.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Vendor risk teams have a well-worn playbook for SaaS: certifications, data-processing terms, subprocessors, breach notification, exit rights. AI providers fit that playbook — the trap is aiming it at the wrong party. Depending on which door you use to reach Claude, the party operating the service, processing your data, and holding your contract changes. Sort that out first and the rest of the assessment falls into place.

Step one: identify who you are actually assessing

On the first-party Claude API and on Claude Platform on AWS (Anthropic-operated, running on AWS), Anthropic is the operator, and for commercial customers Anthropic describes itself as a data processor acting on the customer's instructions. On Amazon Bedrock and Google Cloud, Anthropic's own documentation is explicit that the cloud provider is the data processor, and directs customers to those platforms' data retention and compliance policies for equivalent controls; Microsoft Foundry deployments likewise sit inside your Microsoft relationship. So a Bedrock deployment is primarily an AWS vendor assessment — likely already largely done if AWS is your incumbent cloud — with Anthropic as the model developer behind the service. A first-party deployment is an Anthropic assessment. Aim your questionnaire accordingly.

What Anthropic publicly documents

When Anthropic is the party under review, several answers are on the public record rather than questionnaire-only:

Do not silently extend these to the cloud platforms: a certification held by Anthropic for its API is not evidence about Bedrock, Vertex AI, or Foundry. Those deployments inherit your cloud provider's compliance posture — verify certifications, BAAs, and data-handling terms directly with that provider.

The checklist to run with your provider

AreaWhat to verify
Data processingWho is the processor for this deployment path; where retained data resides; retention periods and deletion mechanics
CertificationsWhich attestations cover the specific service you will use, at what scope; obtain the reports, not the badge list
SubprocessorsThe provider's current subprocessor list and change-notification mechanism (provider-published; review with counsel)
Breach notificationContractual notification commitments and channels — set by your agreement with the provider; confirm timelines in the contract itself
Training useWritten confirmation that your inputs/outputs are not used for model training under your terms
Regulated dataIf PHI or similar is in scope: the specific arrangement (e.g., BAA) covering the specific platform — not an adjacent one
ExitWhat you can export, what gets deleted on termination, and how model access ends

Two hedges worth keeping verbatim in your report: breach-notification timelines and subprocessor terms are contractual matters that vary by agreement — this guide cannot state them for you — and no certification is a regulatory conclusion about your use case. Your counsel maps attestations to obligations.

Reassess on change, not just on calendar

Annual reviews are table stakes; AI services also change mid-cycle in ways that matter — new models with different retention requirements (Claude Fable 5, for example, requires 30-day retention and is not ZDR-eligible), new stateful features that sit outside a ZDR arrangement, new platform capabilities. Add "material service change" triggers to the reassessment policy, and assign an owner to watch the platform's release documentation.

Where to go next

If the vendor is a SaaS product with Claude inside rather than a platform, use the companion checklist. For the compliance-inheritance logic, see compliance inheritance and legal and procurement basics.

Sources