OpenAI SOC 2 vs Anthropic SOC 2 vs Azure OpenAI Compliance (2026)

SOC 2 Type 2 is a six-to-twelve-month observation report on how a vendor operationally implements the AICPA Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy — the 'TSC'). The report is the property of the audited vendor; you receive it under NDA after signing a mutual non-disclosure with the vendor's trust team. The scope section is the most important part of the report you read — it lists exactly which systems and services the auditor observed. A SOC 2 with API scope but not training-infrastructure scope is a different control story than one that covers both.

OpenAI publishes a SOC 2 Type 2 covering its Platform — the API, dashboard, billing, fine-tuning, and Assistants infrastructure. The report is annual and observation periods generally cover 12 months ending in calendar Q1 (the specific dates rotate; verify the latest report on trust.openai.com). Notable inclusions: API, fine-tuning, Assistants v2, Batch API, Stored Completions. Notable exclusions historically: research-side training infrastructure (the cluster that pre-trains base models) is a separate environment with its own controls. Most enterprises only need the Platform-scope SOC 2 because they use the API, not the training cluster.

Anthropic publishes a SOC 2 Type 2 covering the Anthropic API and Console. The report is annual. Anthropic's report is structurally similar to OpenAI's — it observes the production API serving infrastructure plus the customer-facing Console for managing API keys, billing, and workspaces. Anthropic also publishes a public-facing SOC 3 (a sanitized executive summary of the SOC 2) on trust.anthropic.com that you can pull without signing an NDA — a useful first-pass diligence artifact.

Azure OpenAI inherits Azure's enterprise-grade compliance stack. Microsoft publishes a single SOC 2 Type 2 covering Azure (and a separate one covering Azure Government). Azure OpenAI Service is in scope because it runs as a managed service inside an Azure region; the underlying compute, storage, networking, and identity controls Microsoft audits for Azure cover the Azure OpenAI deployment. This is structurally different from buying OpenAI's API directly: with Azure OpenAI you are buying Microsoft's compliance overlay on top of OpenAI's models. For regulated enterprises that have already certified Azure as a vendor, this is the path of least resistance.

A sub-processor is any third party that the primary vendor allows to process customer data on its behalf — typically infrastructure (AWS, GCP, Azure), security services (Datadog, Cloudflare), CRM/support (Zendesk), and increasingly content moderation or red-team partners. GDPR Article 28 requires the primary processor to give the controller (you) prior notice before adding or replacing a sub-processor, and the right to object. Every serious enterprise DPA includes this language.

OpenAI publishes its sub-processor list on the Trust Portal. The list includes Microsoft Azure and Oracle Cloud (for compute), CoreWeave (for accelerated compute), Snowflake (for analytics), and a small number of support/observability vendors. Notable: OpenAI's primary inference uses Azure compute under the Microsoft–OpenAI partnership, which is why some enterprises pick Azure OpenAI directly — same compute, fewer contracting hops.

Anthropic publishes a sub-processor list at trust.anthropic.com/sub-processors. Anthropic's primary inference infrastructure historically runs on Google Cloud Platform and Amazon Web Services (Anthropic was an early Bedrock partner). Buyers in regulated industries sometimes prefer to procure Claude through AWS Bedrock or Google Vertex AI because the cloud partnership flips Anthropic from a 'primary processor with cloud sub-processor' to 'sub-processor under your existing cloud DPA' — which is sometimes the only path to a clean audit.

Azure OpenAI does not expose a separate sub-processor list — the Azure Online Services Terms govern, and Microsoft's enterprise customer base means the sub-processor management is already baked into the procurement process most regulated buyers already run. This is the cleanest path for enterprises with a heavy Azure footprint.

Under the HIPAA Privacy Rule, any vendor that processes Protected Health Information (PHI) on behalf of a Covered Entity must sign a Business Associate Agreement (BAA). For LLM vendors, this is the contract that matters most for healthcare buyers. The BAA generally requires the vendor to implement administrative, physical, and technical safeguards (HIPAA Security Rule, 45 CFR Part 164 Subpart C), report breaches, and limit use of PHI to specified purposes.

OpenAI will sign a BAA covering eligible API endpoints when the customer has Zero Data Retention configured. As of June 2026, the eligible endpoint list has expanded but still excludes some surfaces (verify the current list via OpenAI Enterprise sales). Coverage typically includes the Chat Completions API, the Responses API, the Assistants API, and embeddings — confirm per-model on the latest list.

Anthropic offers a BAA under its Enterprise tier. The Anthropic BAA generally requires ZDR and explicit confirmation that the inference path does not log prompts or responses beyond the operational minimum. The cleanest healthcare-friendly path to Claude for many buyers is via AWS Bedrock — AWS's existing BAA covers Bedrock, and Anthropic's models on Bedrock fall under AWS's controls. This collapses two BAAs into one and uses the AWS contract most healthcare buyers already have.

Azure OpenAI is BAA-covered by Microsoft's standard healthcare addendum. Any Azure subscription where the BAA is signed covers Azure OpenAI Service in the same region scope. For HIPAA buyers already on Azure, this is by far the easiest path — no separate vendor relationship, no separate audit, no separate sub-processor diligence. The trade-off: Azure OpenAI is a slightly behind-the-curve model release schedule vs OpenAI direct (typically 2-6 weeks lag on new model GA).

Data residency is a separate question from compliance attestation. A vendor can be SOC 2 Type 2 audited and still process your prompts in any of its regions unless you've contractually pinned a region. For EU buyers under GDPR Schrems II concerns, US data-transfer pathways require either Standard Contractual Clauses (SCCs) plus a transfer-impact assessment, or EU-region processing.

OpenAI offers EU data residency on the Enterprise tier — the API endpoint can be configured to keep input, output, and operational logs inside the EU. Specific eligible models and SLAs are listed on the Enterprise data residency page; not every model is available in every region (verify before committing). For non-Enterprise customers, OpenAI processes globally, with the standard DPA + SCCs covering the cross-border transfer.

Anthropic offers EU-residency processing on Enterprise. The cleaner path for many EU buyers is AWS Bedrock in an EU region (e.g., eu-central-1 / eu-west-1) — the model weights are deployed regionally and inference does not leave the region. Same for Google Vertex AI in Europe — Vertex provides Anthropic models in europe-west1 and other EU regions.

Azure OpenAI has the broadest data-residency footprint of the three. As of June 2026, Azure OpenAI is available in roughly 30 regions including 6+ EU regions (West Europe, Sweden Central, France Central, Switzerland North, Germany West Central, North Europe). Pick the region during resource provisioning; inference, logs, and managed identity stay in-region. For UK buyers, UK South is available. For sovereign workloads, Azure Government regions exist with FedRAMP High.

The most-asked question in 2025-2026 enterprise diligence calls: 'will you train on my prompts?' All three providers' API contracts now state explicitly that they do not train on customer API inputs or outputs by default. The differences are in how that default is communicated and what side-channel data (telemetry, abuse-monitoring logs) is retained.

OpenAI's API terms state that data submitted via the API is not used to train OpenAI models. ChatGPT consumer is the historical exception (opt-out via settings); the API has been opt-out-by-default since 2023 and the language has tightened repeatedly since. ZDR additionally disables the 30-day abuse-monitoring retention.

Anthropic's API terms state that Anthropic does not train its models on customer-submitted API inputs or outputs. This is the default contractual posture, not an opt-out. Anthropic's commercial agreements and Enterprise terms reinforce this. For the cleanest contract language, the Anthropic Commercial Terms of Service combined with the Enterprise Order Form (signed at procurement) gives explicit no-training warranties.

Azure OpenAI's data privacy page (learn.microsoft.com/azure/ai-services/openai/concepts/data-privacy) states: 'Your prompts (inputs) and completions (outputs), your embeddings, and your training data are NOT available to other customers, NOT available to OpenAI, NOT used to improve OpenAI models, NOT used to improve any Microsoft or 3rd party products or services, NOT used for automatically improving Azure OpenAI Service models for your use in your resource.' This is the strongest no-training language of the three because it is published in primary product documentation, not just contract text.

The EU AI Act entered into force August 2024 with staged application. The general-purpose AI (GPAI) model provider obligations under Article 53 began applying August 2025, and high-risk system obligations under Annex III begin applying August 2026. Compliance posture matters for both the provider (GPAI obligations) and the deployer (high-risk system obligations).

OpenAI, Anthropic, and Google have all signed the Commission's GPAI Code of Practice (June 2025), which serves as the presumed-compliant means of meeting Article 53 transparency and copyright obligations. xAI signed the Code of Practice but not the safety chapter. Meta did not sign. This affects vendor selection for EU deployers because deployers downstream of a non-signatory face heavier evidentiary burdens proving GPAI provider compliance.

Azure OpenAI sits in an interesting position. Microsoft as the deployer-facing entity contracts with the EU deployer, but the underlying model is OpenAI's. The EU AI Act treats this as 'placing on the market' by the entity that contracts with the deployer, so Microsoft's terms and documentation are the primary surface. Microsoft publishes a Responsible AI Standard plus product-specific transparency notes — usually sufficient evidence for downstream deployer documentation.

If your use case is high-risk under Annex III (credit scoring, recruitment, education, law enforcement, etc.), the deployer obligations are extensive — risk management system, human oversight, accuracy and robustness, post-market monitoring, fundamental-rights impact assessment for public bodies. The choice of LLM vendor is a small part of that compliance stack; the larger work is yours. See /blog/eu-ai-act-checklist-for-saas-2026 for a deployer-side checklist.

All three providers operate trust portals. The access flow is similar but the artifacts differ.

OpenAI: visit trust.openai.com, create an account, request access to the document library, sign the mutual NDA, and download SOC 2 Type 2, SOC 3, ISO 27001 certificate, penetration test summary, sub-processor list, and the DPA library. Most requests are approved within 1-2 business days. Public artifacts (SOC 3, ISO certificate, sub-processors) are available without NDA.

Anthropic: visit trust.anthropic.com, follow the same NDA + download flow. Anthropic's portal includes SOC 2 Type 2, SOC 3, ISO 27001/27017/27018/27701 certificates, sub-processor list, a security overview whitepaper, and the BAA template for review prior to signing.

Azure: Azure compliance documentation is at aka.ms/stp (Service Trust Portal) and learn.microsoft.com/azure/compliance. SOC reports, ISO certificates, FedRAMP packages, HIPAA/HITECH attestations, PCI-DSS, IRAP, C5, and dozens more are downloadable for Azure customers under the Microsoft Online Services Terms. Azure OpenAI Service is in scope on the relevant reports.

Practical tip: regulated buyers should pull the SOC 2 Type 2 first and read the scope section before requesting other artifacts. If the scope does not cover the surface you intend to deploy, the rest of the diligence is moot — escalate to a sales engineer for a written confirmation of what's actually in scope for your use case.

Healthcare (HIPAA, PHI on inputs): Azure OpenAI is the cleanest path for any buyer already on Azure — single BAA, single procurement contract, region selection, no separate vendor relationship. Anthropic via AWS Bedrock is the cleanest for buyers already heavy on AWS. OpenAI direct is viable but requires the explicit BAA addendum and ZDR; verify endpoint eligibility per use case.

EU enterprise (GDPR + EU AI Act + Schrems II): Azure OpenAI in an EU region is the broadest residency footprint and the most mature DPA. Anthropic via AWS Bedrock or Vertex AI in EU regions is the next cleanest path. OpenAI direct with EU residency on Enterprise tier works but with the narrowest model availability per region.

US federal (FedRAMP Moderate or High): Azure OpenAI in Azure Government (FedRAMP High) is the only frontier-model path with a turnkey FedRAMP High inheritance today. OpenAI has limited FedRAMP Moderate coverage on specific endpoints; coordinate via OpenAI Federal sales. Anthropic FedRAMP Moderate is in progress (verify status).

Highly regulated financial services (SOC 2 + ISO + region residency + customer-managed keys): Azure OpenAI again wins on contracting surface area, but the model lineup is OpenAI's only. If your stack requires Claude (legal review use cases tend to prefer Claude for long-context document analysis), AWS Bedrock with EU/US-region deployment and AWS KMS for customer-managed keys is the standard path.

Cost-sensitive but still SOC 2 + DPA + no-training: any of the three are roughly equivalent. Pick on model quality + price for your specific workload (see /calc/gdpr-compliance-cost-for-llm-apps-2026) rather than compliance posture, which is a wash.

Customer-managed encryption keys (CMK / BYOK). Not consistently available across all three for inference inputs; Azure OpenAI offers customer-managed keys for stored fine-tuning data via Azure Key Vault. Verify per-feature.

Bring-your-own-network (private link, VPC peering). Azure OpenAI supports private endpoints via Azure Private Link. AWS Bedrock supports VPC endpoints for Anthropic models. OpenAI direct does not currently offer a VPC-peering path at general availability for the standard API.

Sub-processor change notification windows. All three publish change notifications, but timing varies. Subscribe to the trust portal notifications for the providers you've procured from.

Per-feature compliance scope drift. Fine-tuning, Batch API, Assistants v2, Code Interpreter, vector stores — each has slightly different scope on the SOC 2 reports. Read the scope appendix when you read the report; the executive summary will overstate coverage for new features.