Anthropic DPA Explained

What's actually in Anthropic's Data Processing Addendum, the 7-day default vs the 30-day opt-in retention, and how to obtain it for your business.

If you're rolling out Claude inside a regulated business, your privacy team is going to ask one question first: "Where's the DPA?" The DPA is the contract that turns Anthropic's marketing copy about privacy into something legally enforceable. It's also the document that determines whether your deployment can pass a SOC 2, GDPR, or HIPAA audit.

Here's what's in it, in plain English. No legalese, no marketing.

What a DPA is

DPA stands for either "Data Processing Addendum" or "Data Protection Addendum," depending on the vendor. Same document, slightly different naming convention. It's a contract that hangs off a vendor's main commercial terms and addresses one specific topic: how the vendor handles personal data on behalf of its customer.

Under GDPR and similar privacy regimes (CCPA, UK GDPR, Brazil's LGPD), there's a specific role split:

• Controller. The party that decides what to do with personal data. That's you, the business using Claude.
• Processor. The party that handles personal data on the controller's instructions. That's Anthropic, processing prompts that contain personal data on your behalf.
• Sub-processor. A third party the processor uses to deliver the service. AWS, for instance, hosts Anthropic's infrastructure.

The DPA codifies that relationship. It defines what the processor can and can't do with the data, how long it keeps it, who it shares it with, what happens when something goes wrong, and how a controller can audit or terminate the arrangement. Every serious vendor that touches personal data has one. It's table stakes for B2B, not a premium feature.

What's in Anthropic's DPA at a high level

Anthropic's DPA covers the standard ground you'd expect from any mature processor. It references the commercial terms as the parent contract and layers data-protection-specific obligations on top.

If you've signed DPAs with AWS, Snowflake, or any major SaaS vendor, the structure will look familiar. Anthropic's isn't unusual. The interesting parts are the retention and training clauses, which we'll dig into below.

The 7-day default retention

Every API call generates an operational log on Anthropic's side. That log includes the request, the response, and metadata used for billing and abuse detection. By default, those logs auto-delete after 7 days.

This applies to every API customer, automatically. You don't have to opt in. You don't have to ask for it. You don't need a custom DPA. Sign up, hit the API, and you've got 7-day retention by default.

That number isn't arbitrary. Seven days is long enough for Anthropic's trust and safety team to investigate flagged requests and short enough that the data exposure window stays narrow. After day 7, the log is gone. There's no archive, no cold storage, no recovery process.

The 30-day opt-in extension

Some teams want longer log retention, not shorter. Sounds counterintuitive until you've sat through a security incident review.

If a regulated customer detects suspicious activity (an internal user exfiltrating data, a compromised credential, a prompt injection attempt) they need a window to investigate. If the logs are already gone, the trail is cold. Seven days isn't always enough to detect, escalate, and get forensic eyes on the data.

For teams in that bucket, Anthropic offers a 30-day retention extension. It's documented in a DPA amendment, signed once, and applies going forward. The mechanics are the same: operational logs, abuse detection only, no training, no marketing analytics. Just a longer window to look back.

The opposite request also exists. Zero retention is available for qualifying Enterprise customers whose threat model can't tolerate even 7 days of vendor-side logs. That's a different conversation, with stricter eligibility, and it lives outside the standard DPA.

The training clause

This is the clause every privacy-aware buyer wants to see, and Anthropic's version is unambiguous. The commercial terms state that Anthropic will not use API inputs or outputs to train its models.

Two things worth noting:

• It's contractual, not a toggle. Some vendors give you an opt-out switch in a settings panel. Anthropic doesn't. The non-training commitment lives in the contract, applies to every API customer by default, and can't be inadvertently flipped on by an admin who wandered into the wrong settings page.
• It applies to the API only. Consumer Claude.ai (Free, Pro, Team) operates on different rules where training is on by default and users opt out manually. The API and Enterprise tiers are the path that actually keeps your data out of training data.

If you're evaluating Claude for any workflow involving customer data, employee data, or trade secrets, this clause is the load-bearing one. It's the difference between "your prompts could end up training a future model" and "your prompts categorically can't."

Sub-processor list

Anthropic doesn't run on bare metal. It runs on cloud infrastructure, like every modern AI provider, and that means there's a chain of vendors behind the scenes who also touch your data. The DPA requires Anthropic to disclose them, and the public list lives at anthropic.com/legal/sub-processors.

The headline name is AWS, which provides the primary infrastructure (compute, storage, networking) that Claude runs on. AWS has its own DPA, its own SOC 2, its own GDPR posture, and Anthropic's contract with them flows down those obligations to your customer data. Other sub-processors handle specific functions: customer support tooling, billing, analytics, log aggregation. The list is the authoritative reference and gets updated when the vendor stack changes.

Under GDPR, you have the right to be notified before a new sub-processor is added so you can object. Anthropic's DPA includes that notification mechanism. For most customers, sub-processor changes are routine. For regulated buyers, the notification window is what lets you re-evaluate the chain before new vendors get access.

How to actually get the DPA signed

There are three paths, depending on your tier.

Standard API customers

If you're a developer or small team using the API on the standard commercial terms, the DPA is incorporated by reference into Anthropic's commercial terms. You don't sign a separate document. Creating an API account and accepting the terms binds Anthropic to the DPA. The 7-day retention, the no-training clause, the SCCs, all of it applies automatically.

For most B2B procurement processes, this is sufficient. Your privacy team will want to read the DPA text, confirm it covers their requirements, and file it alongside your other vendor DPAs. Done.

Enterprise customers

On the Enterprise tier, you get a dedicated DPA negotiated through account management. This is where you'd amend the retention window (to 30 days, or to zero), add specific data residency requirements, negotiate audit rights, or layer on industry-specific compliance terms. The base text is similar, but the customizations live here.

Enterprise is also where you get human contacts. A named account team, a security questionnaire response process, and the ability to pull SOC 2 reports under NDA. If you're going through a vendor security review with a procurement department, this tier is what lets you pass it.

HIPAA-covered teams

HIPAA needs a Business Associate Agreement (BAA), which is a separate document from the DPA. Anthropic offers a combined BAA plus DPA on the Enterprise tier. The BAA covers the HIPAA-specific obligations (PHI handling, breach notification timelines, the 60-day rule), and the DPA covers everything else.

You can't get a BAA on the standard API tier. That's a structural limitation. If you're processing PHI and you need it covered, Enterprise is the path.

What changes if you use Private Claude

Private Claude is a chat interface that uses the Anthropic API on your behalf. When you bring your own connection password, your usage flows through Anthropic on the API tier, which means Anthropic's DPA already applies to the underlying calls. That part is unchanged.

What's added is a second layer: Private Claude itself processes your data when you use the chat. We have our own DPA at privateclaude.ai/dpa that covers what we do with messages, account metadata, and any logs we generate.

The chain looks like this:

• Your business. Controller. Decides what to put into a Claude prompt.
• Private Claude. Processor. Receives your message, forwards it to Anthropic, returns the response. Our DPA governs this.
• Anthropic. Sub-processor (from your perspective). Runs the model, holds operational logs for 7 days, doesn't train on the data. Anthropic's DPA flows down.
• AWS. Sub-sub-processor. Hosts Anthropic's infrastructure.

Practically, this means a regulated customer evaluating Private Claude needs to review two DPAs: ours and Anthropic's. Both are publicly available. Both incorporate SCCs for cross-border transfers. The combined posture (7-day API retention plus our zero-server-side-history architecture) usually ends up tighter than running directly against the API with default settings, because we don't store chat history at all on our side.

If you need a BAA on top of all of this, that's available on our business tier and bridges to Anthropic's Enterprise BAA underneath. Talk to us.