HomeEnterprise & CloudData Residency & Compliance

advanced10 min read· Module 11, Lesson 5

🏛️Data Residency & Compliance

Zero Data Retention, HIPAA, SOC2, and geographic data controls

Data Residency & Compliance

When you build production systems on top of Claude, understanding where your data lives, how long it is retained, and which compliance frameworks apply is not optional — it is a hard requirement for any regulated industry.

This lesson covers everything you need to ship a compliant integration: data retention policies, Zero Data Retention (ZDR), the inference_geo parameter, HIPAA and SOC 2 certifications, and a practical compliance checklist.

1. Default Data Retention Policy

By default, every request you send to the Anthropic API is subject to the 30-day data retention window.

What is stored	Retention period	Purpose
Prompts (inputs)	30 days	Trust & Safety review
Completions (outputs)	30 days	Trust & Safety review
Metadata (timestamps, model, token counts)	30 days	Billing & analytics

Key points:

Data retained under this policy is not used for model training.
Anthropic staff may review flagged conversations for Trust & Safety purposes only.
After the 30-day window, data is permanently deleted from active storage and purged from backups within 90 days.

Output

                  ┌──────────────────────┐
  API Request ──▶ │  Active Storage      │──▶ 30 days ──▶ Deletion
                  │  (Trust & Safety)    │
                  └──────────────────────┘
                              │
                              ▼
                  ┌──────────────────────┐
                  │  Backups (encrypted) │──▶ +90 days ──▶ Purge
                  └──────────────────────┘

2. Zero Data Retention (ZDR)

What is ZDR?

Zero Data Retention is an opt-in policy that tells Anthropic not to store any prompt or completion data at all. When ZDR is active:

No prompts are persisted after the response is sent.
No completions are persisted after the response is sent.
No human review of your traffic occurs.
Requests are processed in memory and discarded immediately.

How to enable ZDR

ZDR is not a self-serve toggle. You must:

Contact your Anthropic account team or sales representative.
Sign an updated data-processing addendum (DPA) that reflects ZDR terms.
Once approved, Anthropic enables ZDR on your organization ID.

After activation, every API call from that organization automatically receives zero-retention treatment — no code change is needed on your side.

Feature eligibility under ZDR

Not every API capability is available when ZDR is turned on. Certain features require some degree of server-side storage to function.

Feature	Available with ZDR	Notes
Messages API	Yes	Core chat completions work normally
Streaming	Yes	Tokens stream and are discarded
System prompts	Yes	Processed in memory only
Tool use / function calling	Yes	Tool definitions not stored
Vision (image inputs)	Yes	Image bytes discarded after inference
PDF support	Yes	PDF bytes discarded after inference
Prompt caching	No	Caching requires server-side storage
Message Batches API	No	Batch jobs require persistent queue
Model fine-tuning	No	Training requires stored data
Evaluations (evals)	No	Eval runs need stored outputs

Important: If you attempt to use a feature that is incompatible with ZDR, the API will return an error rather than silently storing data.

Verifying ZDR is active

You can confirm ZDR status by checking the response headers returned by the API:

Terminal
curl -s -D - https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2024-01-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-20250514",
    "max_tokens": 64,
    "messages": [{"role": "user", "content": "Hello"}]
  }' | head -30

Look for the header:

Output

x-data-retention: zero

If you see x-data-retention: default, ZDR is not enabled for your organization.

3. Geographic Data Controls — `inference_geo`

The inference_geo parameter lets you restrict where your API requests are processed geographically.

Supported values

Value	Meaning
`"global"`	Requests may be processed in any Anthropic data center (default)
`"us"`	Requests are guaranteed to be processed in the United States only

How to use it

Pass inference_geo as a top-level parameter in your request body:

Python

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    inference_geo="us",          # Force US-only processing
    messages=[
        {"role": "user", "content": "Summarize this patient record."}
    ],
)

TypeScript

const client = new Anthropic();

const message = await client.messages.create({
  model: "claude-sonnet-4-20250514",
  max_tokens: 1024,
  inference_geo: "us",           // Force US-only processing
  messages: [
    { role: "user", content: "Summarize this patient record." },
  ],
});

When to use `inference_geo`

Your organization is subject to US data sovereignty requirements.
You need to satisfy FedRAMP, ITAR, or contractual data-locality clauses.
Your compliance team requires proof that data never leaves US jurisdiction during processing.

Note: inference_geo controls where processing happens, not where data is stored. Combine it with ZDR for full control: no storage plus US-only processing.

4. HIPAA Compliance

Overview

Anthropic offers a HIPAA-eligible environment for customers who need to process Protected Health Information (PHI).

Requirements to use Claude with PHI:

Business Associate Agreement (BAA): You must sign a BAA with Anthropic before sending any PHI to the API.
Zero Data Retention: ZDR must be enabled for your organization. Anthropic will not store PHI under any circumstances.
US inference: Use inference_geo: "us" to ensure PHI is processed within the United States.
Eligible models: Confirm with your account team which models are covered under the BAA.

Data flow for HIPAA workloads

Output

  Your App (HIPAA-covered entity)
       │
       ▼
  ┌─────────────────────────────────────┐
  │  Anthropic API  (BAA in place)      │
  │  inference_geo: "us"                │
  │  ZDR: enabled                       │
  │                                     │
  │  ┌───────────────────────────────┐  │
  │  │  In-memory processing only    │  │
  │  │  No data written to disk      │  │
  │  │  No human review              │  │
  │  └───────────────────────────────┘  │
  └─────────────────────────────────────┘
       │
       ▼
  Response returned ──▶ Data discarded at API layer

What Anthropic does NOT cover

Anthropic is not responsible for how you store, log, or transmit PHI on your side.
You must still implement your own HIPAA safeguards: encryption at rest, audit logs, access controls, workforce training, etc.

5. SOC 2 Certification

Anthropic maintains a SOC 2 Type II certification, which means an independent auditor has verified that Anthropic's controls for security, availability, processing integrity, confidentiality, and privacy are operating effectively over a sustained period.

What SOC 2 covers

Trust Service Criterion	Covered
Security	Yes
Availability	Yes
Processing Integrity	Yes
Confidentiality	Yes
Privacy	Yes

How to obtain the SOC 2 report

Request it through your Anthropic account team.
SOC 2 reports are confidential and shared under NDA.
Reports are updated annually; ask for the latest audit period.

6. Compliance Checklist for Regulated Industries

Use this checklist before going live with Claude in any regulated environment:

General

Review Anthropic's Terms of Service and Acceptable Use Policy.
Identify which data classifications will be sent to the API.
Determine whether ZDR is required for your data classification.
Contact your Anthropic account team to discuss compliance needs.

Data Residency

Decide whether inference_geo: "us" is required.
Document the geographic processing guarantee for auditors.
Verify inference_geo is set in every API call (not just some).

Healthcare (HIPAA)

Sign a Business Associate Agreement (BAA) with Anthropic.
Enable Zero Data Retention.
Set inference_geo: "us" for all PHI-containing requests.
Implement your own encryption, logging, and access controls.
Train workforce members on PHI handling with AI systems.

Financial Services

Evaluate whether ZDR satisfies your data-handling requirements.
Review SOC 2 Type II report for control adequacy.
Document model risk management procedures (SR 11-7 / OCC 2011-12).
Ensure audit trails exist for all AI-assisted decisions.

Government / Public Sector

Confirm inference_geo: "us" satisfies jurisdiction requirements.
Evaluate whether FedRAMP authorization is needed (check roadmap).
Review Anthropic's security whitepaper.
Ensure data classification labels are applied to all requests.

7. Best Practices for Sensitive Data

Minimize data exposure

Send only what is needed. Do not include full records when a summary or ID reference would suffice.
Redact PII before calling the API. Use a pre-processing pipeline to strip Social Security numbers, account numbers, and other direct identifiers.

Secure your integration

Python

# Always load API keys from environment variables or a secrets manager
client = anthropic.Anthropic(
    api_key=os.environ["ANTHROPIC_API_KEY"],
)

# Pre-process: redact sensitive fields
def redact_ssn(text: str) -> str:
    import re
    return re.sub(r"\b\d{3}-\d{2}-\d{4}\b", "[SSN REDACTED]", text)

user_input = redact_ssn(raw_input)

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    inference_geo="us",
    messages=[{"role": "user", "content": user_input}],
)

Log responsibly

Do not log full prompts or completions in production if they contain sensitive data.
Use structured logging with references (request IDs) instead of raw payloads.
Ensure your logging infrastructure has the same compliance posture as your primary data stores.

Rotate keys and audit access

Rotate API keys on a regular schedule (at least quarterly).
Use separate API keys for each environment (dev, staging, production).
Audit who has access to API keys and restrict to the minimum set of team members.

Build a compliance-aware architecture

Output

  ┌──────────────┐      ┌───────────────┐      ┌───────────────────┐
  │  User Input  │─────▶│  PII Redactor │─────▶│  Anthropic API    │
  │              │      │  (pre-process)│      │  ZDR + US geo     │
  └──────────────┘      └───────────────┘      └───────────────────┘
                                                       │
                                                       ▼
  ┌──────────────┐      ┌───────────────┐      ┌───────────────────┐
  │  User sees   │◀─────│  Post-process │◀─────│  Response (plain) │
  │  final reply │      │  (audit log)  │      │                   │
  └──────────────┘      └───────────────┘      └───────────────────┘

8. Summary

Concern	Solution	How to activate
Data stored for 30 days	Zero Data Retention (ZDR)	Contact Anthropic sales
Data processed outside US	`inference_geo: "us"`	Pass parameter in every request
PHI / HIPAA	BAA + ZDR + US geo	Sign BAA, enable ZDR, set geo
Audit assurance	SOC 2 Type II report	Request via account team
PII leakage	Pre-processing redaction	Build into your pipeline

By combining ZDR, geographic controls, and proper integration hygiene, you can use Claude confidently in even the most tightly regulated environments.

Module 11

5/6

🟦 Claude on Microsoft Azure Foundry

Enterprise Security Audit Guide 🔐

5/6

🏛️Data Residency & Compliance

Data Residency & Compliance

1. Default Data Retention Policy

2. Zero Data Retention (ZDR)

What is ZDR?

How to enable ZDR

Feature eligibility under ZDR

Verifying ZDR is active

3. Geographic Data Controls — inference_geo

Supported values

How to use it

When to use inference_geo

4. HIPAA Compliance

Overview

Data flow for HIPAA workloads

What Anthropic does NOT cover

5. SOC 2 Certification

What SOC 2 covers

How to obtain the SOC 2 report

6. Compliance Checklist for Regulated Industries

General

Data Residency

Healthcare (HIPAA)

Financial Services

Government / Public Sector

7. Best Practices for Sensitive Data

Minimize data exposure

Secure your integration

Log responsibly

Rotate keys and audit access

Build a compliance-aware architecture

8. Summary

3. Geographic Data Controls — `inference_geo`

When to use `inference_geo`