GDPR, FedRAMP and data residency controls for Claude

1.GDPR: covered by contract, not a Console setting

HIPAA readiness is something you switch on in the Console. The sources describe no equivalent switch for GDPR. Anthropic's GDPR position is set out in documents: its Privacy Policy, its Data Processing Addendum (DPA) and Help Center articles. Together they explain how Anthropic handles personal data, both when it collects it from consumers and when it acts as a processor for business customers.

For commercial products such as Claude for Work and the Claude API, the DPA includes Standard Contractual Clauses (SCCs). It is built into the Commercial Terms of Service, so you accept the DPA when you accept those terms. There is nothing separate to sign. If you use Claude through a third-party platform or service provider, that platform's terms govern your use, not Anthropic's.

Auditors often ask for supporting evidence. Anthropic's listed compliance credentials are a HIPAA-ready configuration (BAA available), ISO 27001:2022, ISO/IEC 42001:2023 for AI management systems, and SOC 2 Type I and Type II. Copies of the compliance documentation can be requested through the Trust Portal.

The sources draw a limit you should not cross. They do not document any EU location for processing or storage. In the residency controls described next, workspace geo can only be "us" and inference geo can only be "us" or "global". Do not treat those controls as a way to keep data in the EU.

Sources123

2.Data residency: inference geo and workspace geo

Data residency rules are about where data is processed and stored, and the Claude API splits those into two independent settings. Inference geo decides where model inference runs. You can set it per request with the inference_geo parameter or as a workspace default. Workspace geo decides where data is stored at rest and where endpoint processing, such as image transcoding and code execution, takes place. Workspace geo is chosen when the workspace is created and cannot be changed afterwards.

Workspace settings turn a per-request option into a policy that covers every key in the workspace. allowed_inference_geos limits which geos the workspace may use, and a request for any other geo returns an error. default_inference_geo is used when a request leaves the parameter out. You can configure both in the Console or through the Admin API under the data_residency field.

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
     ? ="us",
    messages=[
        {"role": "user", "content": "Summarize the key points of this document."}
    ],
)

For evidence, the response itself records where inference ran. Note also that the parameter only works on Claude 4.6 and later models. Sending it to Claude Opus 4.5, Sonnet 4.5, Haiku 4.5 or older models returns a 400 error.

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 150,
    "inference_geo": "us"
  }
}

Sources4

3.FedRAMP: authorize the environment, not the model

FedRAMP gives federal cloud services a standard approach to security assessment. The point people most often get wrong is what receives the authorization. FedRAMP and DoD Impact Levels certify cloud services. A Claude model is a software component that runs inside an authorized environment, and the customer's compliance posture comes from the hosting platform.

To meet FedRAMP High, you choose an authorized path:

- Claude for Government (C4G) is Anthropic's FedRAMP High authorized product. It sends all inference through Google Cloud Vertex AI's FedRAMP High environment. No separate FedRAMP audit happens for each model, so new models take on the authorization when they ship. - Amazon Bedrock in AWS GovCloud is FedRAMP High and also supports IL5+. ITAR data can be processed in Claude only through AWS Bedrock. - Google Vertex AI with Assured Workloads is FedRAMP High and IL2.

Claude Enterprise sold on AWS Marketplace is not FedRAMP authorized. For controlled unclassified information (CUI), Claude Enterprise does hold a third-party NIST 800-171r3 attestation.

Authorization of the environment does not cover where every integration sends data. In C4G, some MCP connectors call external APIs outside the FedRAMP boundary, and each connector's catalog description says so. Deciding whether that data flow is acceptable is the agency's responsibility.

Sources5678

4.Retention periods and audit records a reviewer will ask about

Every regime discussed here eventually asks what is retained, for how long, and what the audit trail shows. Several retention models apply separately from the ZDR and HIPAA arrangements:

- The Activity Feed keeps data for 6 years. - The Compliance API has its own retention model. It does not capture local sessions that run under ZDR. For organizations with HIPAA readiness, it captures only Cowork and Claude Code local sessions and stores those transcripts for 30 days. - claude.ai chat, file and project content follows the organization's retention policy, set in Organization settings > Data and privacy, unless a user deletes it sooner. - Local session transcripts from Cowork and Claude Code are kept for 6 years by default, or for the organization's custom retention period if a finite one is set. Remote Cowork transcripts are kept for 6 years unless a user deletes the session.

The data handling docs also list flagged content and legal holds under a separate "retention regardless of arrangement" rule. ZDR alone therefore does not mean nothing is ever kept.

Audit trails differ by product. In Claude Code cloud sessions, every operation is logged for compliance and audit. In Claude for Government, every administrative action is written to a hash-chained audit log that organization administrators can read in the product. Its usage exports contain only metering data, so agencies can answer ATO and Inspector General requests without moving sensitive material.

Sources91011

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Each Claude model has to be FedRAMP authorized before a federal agency can use it.Why is that wrong?

   FedRAMP certifies cloud services, not models. Claude runs inside an authorized environment, and in Claude for Government new models take on the existing authorization.

   Covered in FedRAMP: authorize the environment, not the model

2. 2.Setting inference_geo to "us" also makes sure data is stored at rest in the US.Why is that wrong?

   inference_geo controls only where inference runs, per request. Storage at rest and endpoint processing are set by workspace geo, which is chosen when the workspace is created.

   Covered in Data residency: inference geo and workspace geo

Practise it for real

Pin a Claude API request to US inference and confirm it from the response

1. 1.Send a Messages API request to a Claude 4.6-or-later model with inference_geo set to "us", then print response.usage.inference_geo.

   Why: The usage object records where inference actually ran, which you can keep as evidence.

   You should see: The usage object reports inference_geo as "us".

2. 2.In the Console, set the workspace's allowed_inference_geos to ["us"], then send a request with inference_geo set to "global".

   Why: Workspace restrictions enforce the policy for every key, whatever individual callers send.

   You should see: The API returns an error because "global" is not in the allowed list.

3. 3.Send the same request with inference_geo to Claude Haiku 4.5.

   Why: Older models do not support the parameter, so a residency policy cannot be enforced on them this way.

   You should see: A 400 error.