On this page
TLDR
Compliance is a match-the-surface-to-the-regime exercise: an architect picks the deployment surface (API direct, AWS Bedrock, GCP Vertex, Microsoft Foundry, Claude for Government) and account tier the workload requires, then explicitly turns on the controls that are not on by default. HIPAA BAA coverage is opt-in, not automatic, and has three distinct paths (Enterprise Primary Owner self-activation, mostly-self-serve API activation in Console, or the cloud provider's own BAA on Bedrock/Vertex), and FedRAMP High/DoD IL4-5 is tied to specific US-only surfaces that are not simultaneously combinable with an EU-resident deployment on the same workload.
What it is
An architect's compliance job is to match the deployment surface an organization uses, API direct, AWS Bedrock, GCP Vertex, Azure/Microsoft Foundry, or Claude for Government, and the account tier, to the regulatory regime the workload requires, then explicitly enable the controls that are not on by default. Anthropic's compliance posture is real but conditional: several protections require administrator action rather than automatic inclusion, and the exact certification set differs for consumer versus commercial products.
This is a verify the current tier's paperwork discipline, not a one-time checkbox. GDPR, HIPAA, and FedRAMP are three different kinds of regime, a legal framework, a US healthcare law with a contractual mechanism (the BAA), and a federal authorization program, and each maps to a different artifact or deployment path rather than one universal "Anthropic is compliant" answer.
How it works
Commercial certification baseline. Anthropic's commercial products, Claude for Work and the Anthropic API, maintain HIPAA-ready configuration (BAA available), ISO 27001:2022, ISO/IEC 42001:2023 (AI Management Systems), and SOC 2 Type I & II. These are explicitly scoped to commercial products, not consumer plans, a team prototyping on a free or consumer account cannot point to this certification set at all, regardless of what it builds.
HIPAA BAA coverage is opt-in, and it has three genuinely different paths, not one workflow with two names. (1) On Claude Enterprise, specifically the organization's Primary Owner self-activates HIPAA compliance under "Data & Privacy" settings and signs Anthropic's BAA directly — other Owners or Admins cannot complete this on the org's behalf; standard Enterprise plans do not include this automatically. (2) On the direct 1P API, BAA eligibility is a *separate* path from Enterprise's — but for most organizations it's ALSO self-service: eligible orgs review and execute Anthropic's standard BAA directly in Claude Console (Settings > Privacy), no sales contact required. Only organizations needing a negotiated/custom BAA, or where self-serve isn't available, work through Anthropic's sales team instead. Critically, HIPAA readiness on the API does NOT cover every feature — the Batch API is explicitly NOT HIPAA-eligible, so PHI cannot be sent through Batch even with an active BAA; the API enforces this with a 400 error on non-eligible features. (3) Via a cloud-provider surface (AWS Bedrock, GCP Vertex), coverage runs under that provider's own BAA (the AWS or Google Cloud Business Associate Addendum), not Anthropic's BAA at all, the model provider never sees the raw prompts/completions in that path. Conflating the Enterprise activation workflow with API BAA eligibility, or assuming either one covers a Bedrock/Vertex deployment, is a live compliance gap: a healthcare workload touching PHI before the *specific* path's activation step is complete is uncovered, independent of which model or feature is in use.
FedRAMP High and DoD IL4/5 live on a different surface, not a policy toggle, and that surface is not freely combinable with an EU-resident deployment for the same workload. Claude models are approved for FedRAMP High and DoD Impact Level 4/5 workloads via Amazon Bedrock in AWS GovCloud (US) regions, and Anthropic separately offers Claude Gov models for classified environments plus a dedicated Claude for Government application at FedRAMP High, all US-only, isolated surfaces. EU data/inference residency is a *different* regional deployment (available across AWS Bedrock, GCP Vertex, and Microsoft Foundry EU regions). A single workload runs in one geographic surface at a time, so "FedRAMP High AND EU-resident" isn't a combinable pair of controls on one deployment, it describes two separate workloads on two separate surfaces. Reaching the federal regime means routing through a GovCloud/Government surface, not requesting paperwork against the standard commercial API.
Regional residency and GDPR run on a DPA plus a data-location choice. GDPR itself is not an Anthropic certification but a legal regime; the load-bearing artifact for an EU deployment is typically the Data Processing Addendum governing Anthropic's role as processor, combined with a regional data-residency choice available across AWS Bedrock, GCP Vertex, and Microsoft Foundry. Architects should verify current DPA terms against the live document rather than assume blanket "GDPR compliant" status.
The Trust Center is the canonical, living source. trust.anthropic.com hosts the current SOC 2 Type 2 and CSA STAR L2 reports, the DPA, and security-control documentation, request-gated rather than fully public. Because certifications and terms change, the compliance check is per-deployment verification against that live source, not a fact memorized once.
The trap is assuming "Anthropic is HIPAA compliant" or "FedRAMP authorized" as a blanket, always-on property of Claude, or that these regimes freely stack. Three specific errors: (1) treating HIPAA BAA activation as one workflow, it's three separate paths (Enterprise Primary Owner self-activation, mostly-self-serve direct API activation in Console, or the cloud provider's own BAA on Bedrock/Vertex) with different eligibility mechanisms — and even an active API BAA doesn't cover every feature (Batch API is explicitly excluded); (2) assuming FedRAMP High/IL4-5 authorization applies to the standard API or a consumer product rather than a specific US-only surface (Bedrock GovCloud, Claude for Government); (3) assuming FedRAMP High and EU data residency can both apply to one deployment, they're different, non-overlapping geographic surfaces, not independently combinable controls.
Where you'll see it
Healthcare clinical-notes summarizer
Use Claude for Work/Enterprise or the API, never a consumer plan; on Enterprise, have the org's Primary Owner specifically enable HIPAA compliance and execute the BAA before any PHI touches the system (other Owners/Admins can't do this step); choose a regional deployment matching data-residency requirements.
Federal internal research assistant
Route through Bedrock GovCloud or Claude for Government to land inside the FedRAMP High / IL4-5 boundary, a fundamentally different deployment path than the healthcare case, not just a policy toggle on the same one.
Side-by-side
| Surface | Geography | HIPAA path if PHI involved | FedRAMP High / IL4-5? | Combinable with EU residency on the same workload? |
|---|---|---|---|---|
| Claude for Work / Enterprise (Primary Owner BAA) | Anthropic-hosted, region per Anthropic's offering | Path 1 - Primary Owner specifically self-activates under Data & Privacy, signs Anthropic BAA | No | N/A - not the FedRAMP surface |
| Direct 1P API (Console self-serve BAA) | Anthropic-hosted | Path 2 - eligible orgs self-enable in Console; sales only for negotiated/custom BAAs. Batch API is NOT covered even with an active BAA. | No | N/A - not the FedRAMP surface |
| AWS Bedrock / GCP Vertex (regional) | Region-selectable, incl. EU | Path 3 - covered under the cloud provider's own BAA, not Anthropic's | No (this is the commercial regional path, not GovCloud) | Yes - this IS the EU-residency surface |
| AWS Bedrock in AWS GovCloud (US) | US-only, isolated | Covered under AWS's GovCloud BAA where applicable | Yes | No - GovCloud (US) and EU-resident Bedrock are different, non-overlapping regions |
| Claude for Government / Claude Gov models | US-only, isolated | Government-contract terms, not the standard BAA paths above | Yes | No - a separate, US-only surface |
Decision tree
Does the workload process Protected Health Information (PHI)?
Does the workload need to sit inside a FedRAMP High or DoD IL4/5 boundary?
Does the same workload ALSO need FedRAMP High/IL4-5 AND EU-resident data/inference at once?
Does the workload require EU or cross-border data-residency guarantees?
Is the workload currently running on a consumer Claude plan rather than Claude for Work/Enterprise/API?
How each cert tests this
CCA-P
CCARP-D5-O4 (Governance, Safety & Risk, 14%): tests matching deployment surface, API direct, Bedrock GovCloud, Enterprise plus admin-activated BAA, or a regional choice, to the specific regulatory regime a workload requires, and knowing which controls need explicit activation versus which are automatic.
CCA-A
CCAOF-D6-O2 (Governance, Risk & Responsible Use, 15%): tests applying data-sensitivity, regulatory, and privacy considerations at the business-user level, recognizing when a task touches PHI, regulated data, or cross-border residency before routing it to Claude, without necessarily architecting the deployment surface.
Question patterns
6 V2 questions wired to this concept. Tap an answer to check it instantly - you'll see whether it's right and why - then expand the full breakdown for the mental model and all four rationales.
A healthcare provider wants to route patient clinical notes through a Claude-based summarization tool hosted via a cloud provider's managed API. Which compliance question must be resolved before this is deployed, specific to handling protected health information (PHI)?
Frequently asked
Showing 5 of 5 questions