The Anthropic DPA Explained: Claude Data Processing Agreement Guide (2026)

Short answer: Anthropic offers a Data Processing Agreement (more precisely, a Data Processing Addendum) for its commercial products — Claude for Work Team, Claude for Work Enterprise, and the Claude API. Claude.ai Free and Pro are consumer subscriptions and have no DPA, which makes them unsuitable for processing personal data of EU data subjects on behalf of an employer. The Anthropic DPA incorporates the European Commission's 2021 Standard Contractual Clauses, and Anthropic additionally participates in the EU-US Data Privacy Framework. Training is excluded by default on every DPA-covered tier, sub-processors are disclosed with advance notice of changes, and the API offers a zero-data-retention option for eligible customers. What the DPA does not give you: EU data residency (all Claude inference currently runs on US infrastructure) or compliance itself — a DPA is one required layer of a posture the controller still has to assemble. This guide explains what the DPA is, which Claude plan gets you one, what is inside it, and what to verify before you sign.

What a DPA actually is — and why a consumer ToS is not one

Article 28(3) of the GDPR requires that whenever a processor handles personal data on behalf of a controller, the processing is "governed by a contract" that binds the processor on a specific list of points: processing only on documented instructions, confidentiality commitments, Article 32 security measures, sub-processor authorisation and flow-down, assistance with data subject rights, assistance with breach notification and DPIAs, deletion or return of data at the end of the engagement, and audit rights.

A Data Processing Agreement (Anthropic, like most US vendors, styles it a Data Processing Addendum — the terms are interchangeable and refer to the same document) is the contract that satisfies Article 28(3). Without it, there is no lawful controller-processor relationship, full stop — regardless of how good the vendor's security is or whether training is disabled.

This is why a consumer terms-of-service does not substitute. Claude.ai Free and Pro are B2C contracts between Anthropic and the individual user. When an employee pastes a customer email into a personal Claude.ai account, the employer has processed personal data through a vendor with which it has no contract at all — an Article 28 breach that no setting inside the consumer product can cure. The fact that Claude.ai Pro excludes prompts from training by default is a welcome consumer protection; it is not a DPA.

Which Claude plans include Anthropic's DPA

The tier facts, current as of this writing:

Three points worth pulling out of the table:

• "Claude Team DPA" and "Claude Enterprise DPA" are the same underlying commitment at different service levels. Both Claude for Work tiers are DPA-eligible. Enterprise adds the controls that make the DPA operable at scale — admin audit logs, SSO, and BAA availability for US healthcare contexts — but the Article 28 relationship exists on Team as well.
• The Claude API is DPA-covered too. If your internal tool sends personal data to the Claude API, you need the DPA in place for that relationship — and the API additionally offers a zero-data-retention option for eligible customers, the strongest retention posture Anthropic provides.
• There is no path to a DPA on Free or Pro. If a workflow involves personal data of EU data subjects, the tier has to change; the paperwork cannot be bolted onto a consumer account.

How the Anthropic DPA is accepted

For most customers, Anthropic's DPA is incorporated into its commercial terms of service — the agreement that governs Claude for Work and the API — rather than being a separately negotiated document. Accepting the commercial terms for a business tier brings the DPA (and the Standard Contractual Clauses it incorporates) into effect for that relationship. Anthropic makes its current commercial terms, DPA, and related compliance documentation available through its commercial terms and trust portal; larger enterprise customers may negotiate specific schedules during procurement.

Two cautions. First, "available" is not "signed": teams that provision API keys without anyone reviewing or executing the applicable terms end up with a controller-processor relationship existing in fact but no Article 28 contract on paper. Make DPA confirmation a gate in your API onboarding. Second, terms evolve — verify the current text against Anthropic's own documentation at the time you sign rather than relying on any summary, including this one.

What is inside: transfers, sub-processors, retention

SCCs and the EU-US Data Privacy Framework

Anthropic is a US company and does not currently offer EU data residency — all Claude inference runs on US-based infrastructure. That means every prompt an EU controller sends is an EEA-to-US international transfer under Chapter V of the GDPR, and the DPA has to supply the transfer mechanism.

It does so two ways:

• Standard Contractual Clauses. The Anthropic DPA incorporates the European Commission's 2021 SCCs — Module 2 (controller-to-processor) for the typical customer relationship, or Module 3 where the customer is itself a processor. The DPA also references the supplementary-measures framework of EDPB Recommendations 01/2020.
• EU-US Data Privacy Framework. Anthropic participates in the DPF, which provides an Article 45 adequacy-based mechanism as an alternative. Most professional procurement still leans on SCCs as the primary mechanism, because adequacy decisions have been struck down twice before (Schrems I ended Safe Harbor; Schrems II ended Privacy Shield) and several EU supervisory authorities retain concerns about US government access under FISA 702. A sensible structure is to rely on DPF while keeping SCCs as the contractual fallback.

Neither mechanism removes the Schrems II question entirely. The EDPB's answer is supplementary measures — and the most effective supplementary measure is technical: pseudonymise personal data in the EU, before transfer, so that what crosses the Atlantic is not personal data in identifiable form. More on that below.

Sub-processors and notice

Anthropic publishes a sub-processor list — cloud infrastructure providers (AWS primarily) and support tooling in its current disclosure — and provides DPA customers with advance notice before adding new sub-processors, consistent with Article 28(2)'s requirement that the controller have the opportunity to object. Review the list against your own vendor register when you sign, document the review, and subscribe to whatever change-notification channel Anthropic offers so that objection rights are exercisable in practice, not just on paper.

Retention and the zero-data-retention option

On DPA-covered tiers, prompts and outputs are not used to train Anthropic's models by default; they are processed to generate the response and retained under the terms of the applicable agreement. For sensitive API workloads, eligible customers can configure zero data retention. If your DPIA identifies retention as a material risk — and for special-category or client-confidential workloads it usually is — the ZDR option is the setting to pursue; verify its exact scope against Anthropic's current documentation during procurement.

The DPA also commits Anthropic to assisting with data subject rights: erasure of conversation data on enterprise tiers within agreed timelines, and conversation exports for access requests. The operational burden of finding which conversations contained a given data subject remains with you.

The Anthropic DPA for German and EU organisations

A few points that come up specifically in German and broader EU reviews:

• Transfer mechanism. The analysis is the same as for any US processor without an EU region: SCCs Module 2 (or DPF), plus supplementary measures, with the absence of EU data residency explicitly documented in the DPIA and the Article 30 record. German supervisory authorities have historically taken among the stricter lines in Europe on US transfers, so the supplementary-measures annex deserves real content, not boilerplate.
• Which authority supervises you. Anthropic's DPA posture does not change your lead supervisory authority; that follows your own establishment. A German controller answers to its competent state data protection authority, which can ask to see the DPA, the transfer impact assessment, and the DPIA for your Claude deployment.
• Works councils. In Germany, deploying Claude across a workforce typically engages co-determination rights, because an AI tool that logs usage is capable of monitoring employee behaviour and performance. The DPA does not substitute for a works-council agreement (Betriebsvereinbarung) covering the deployment. Plan for both tracks in parallel — the works-council process is often the longer one.

Anthropic vs OpenAI vs Google: DPA availability compared

If you are evaluating vendors side by side, the DPA picture across the three major providers looks like this:

The structural pattern is identical everywhere: consumer products have no DPA, business products do. The differentiators sit at the edges — OpenAI and Google contract through Irish entities and offer EU residency options that Anthropic currently does not, while Anthropic's business tiers are uniformly training-excluded by default. For the full tier-by-tier analysis of each vendor, see the dedicated guides on Claude, ChatGPT, and Gemini.

What goes wrong: the DPA failure patterns

The recurring failures we see are rarely about the DPA's text. They are about the DPA not existing where everyone assumed it did:

1. The consumer-account gap. Employees use Claude.ai Pro accounts — often signed up with work email addresses, which makes the accounts look corporate — while the organisation has no agreement with Anthropic at all. Every prompt containing personal data is an Article 28 breach.
2. API keys before paperwork. An engineering team ships a feature on the Claude API; nobody confirmed the DPA as part of provisioning. The processing relationship exists in fact; the required contract does not exist on paper.
3. DPA signed, annexes empty. The SCCs are incorporated, but the description of processing, the data categories, and the supplementary-measures annex were never completed for your actual use case. Under audit, a signed-but-generic DPA reads as a formality, not a control.
4. Sub-processor review skipped. The list was never reviewed against the vendor register, and nobody watches for change notices — so the Article 28(2) objection right exists in theory only.
5. The DPA treated as the finish line. A DPA satisfies exactly one obligation. Lawful basis (Article 6), special-category conditions (Article 9), transparency (Articles 13–14), the DPIA (Article 35), the Article 30 record, and Article 32 technical measures all remain the controller's work. "We have the Anthropic DPA" is the beginning of a defensible answer, not the whole of one.

Checklist: what to verify before signing

• Which entity is contracting, and which Claude tier the DPA covers (Team, Enterprise, or API).
• That the 2021 SCCs are incorporated with the correct module for your role (Module 2 as controller, Module 3 if you are a processor yourself).
• That the annexes — description of processing, data categories, technical and organisational measures, supplementary measures — are completed for your actual deployment, not left as templates.
• The current sub-processor list, reviewed and documented, plus the mechanism for advance notice of changes.
• Retention terms for your tier, and whether your workload qualifies for the API zero-data-retention option.
• The data subject rights assistance commitments (erasure timelines, export capability) and how your own DSAR workflow will use them.
• Breach-notification timelines and the audit or assurance mechanism (reports vs. on-site rights).
• The training-exclusion commitment as written in the operative terms — not the marketing page.
• The absence of EU data residency, recorded honestly in your DPIA and transfer impact assessment.
• All of the above against Anthropic's current commercial terms and trust documentation at signature time — vendor terms change.

Where the DPA stops — and where a local masking layer picks up

A DPA governs what Anthropic does with the personal data you send. It does nothing about what you send. Article 5(1)(c) (data minimisation) and Article 32(1)(a) — which names pseudonymisation explicitly — sit with the controller, and they are where the residual Schrems II risk actually gets reduced.

This is the layer where Locke operates. Locke 1.0 detects names, identifiers, health terms, and account numbers on-device and replaces them with one-way placeholders before the prompt leaves the browser; reversible tokenization is planned shortly after 1.0. The prompt Anthropic receives contains placeholders, not identifiable personal data — so the transfer the SCCs govern happens on pseudonymised content. That is precisely the technical supplementary measure EDPB Recommendations 01/2020 contemplates for US transfers, and it complements the DPA rather than replacing it: the contract handles the processor relationship; data minimisation at the keyboard reduces what that relationship ever touches. Neither Locke nor any DPA makes your organisation GDPR compliant on its own — compliance is the assembled posture of contract, settings, minimisation, and governance.

The bottom line

If your organisation processes EU personal data with Claude, the Anthropic DPA is non-negotiable — and available, on Team, Enterprise, and the API, via Anthropic's commercial terms. The consumer tiers cannot be papered over. What the DPA gives you is the Article 28 contract, the SCC/DPF transfer mechanisms, sub-processor transparency, training exclusion, and retention commitments up to zero data retention on the API. What it cannot give you is EU residency, your lawful basis, your DPIA, or your data-minimisation layer. Sign it, complete its annexes properly, and then do the controller-side work that makes it mean something.

Related reading

• Is Claude GDPR Compliant? A 2026 Guide for European Teams
• GDPR and AI: A 2026 Compliance Guide for European Teams
• Is ChatGPT GDPR Compliant?
• Is Gemini GDPR Compliant?
• Is Claude HIPAA Compliant?
• ChatGPT vs Claude for Confidential Work
• What is a Data Processing Agreement?