Blog

DPAs Explained: The GDPR Contract Your AI Vendor Already Has Ready

5 0 0
How it works
Vendor processes data
You need a DPA
Sign & execute
On file

The GDPR contract that isn't a BAA

If you read our piece on BAAs, you might assume every vendor agreement in this space works the same way — a gated, sales-reviewed process before you can send anything sensitive. That's true for HIPAA. It's mostly not true for GDPR. The Data Processing Addendum (DPA) is the contract Article 28 of GDPR requires between a data controller (you) and a data processor (your vendor) whenever the vendor handles personal data on your behalf — and unlike a BAA, most AI providers already have theirs in force the moment you sign up for a paid plan.

Who actually needs one

A BAA only matters if you're a HIPAA business associate — healthcare, insurance, or a vendor to one. A DPA is much broader: any company processing the personal data of an EU, UK, or Swiss individual through a processor needs one, regardless of industry. That covers a fintech scoring transactions, a govtech vendor onboarding EU citizens, an enterprise SaaS with European customers, and a two-person startup with one EU beta user — not just healthcare. If GDPR applies to you at all (and that turns on whose data you process, not what sector you're in), a DPA with every processor touching that data isn't optional.

What a DPA actually obligates

Article 28(3) spells out what the contract has to cover. The processor must:

  • Process personal data only on your documented instructions — no repurposing it for their own training or products without a separate legal basis.
  • Keep it confidential — anyone processing the data under their authority is bound to confidentiality.
  • Implement appropriate technical and organizational security measures (Article 32) — encryption, access control, resilience, and a way to test them.
  • Get your authorization before adding a sub-processor, and flow the same obligations down to them — the same subcontractor-chain problem as a BAA.
  • Assist you in responding to data subject requests — access, deletion, portability — since the individual's rights run against you as the controller, not the processor.
  • Notify you of a personal data breach without undue delay.
  • Delete or return the data at the end of the engagement, and make available the information you need to demonstrate compliance.

If the vendor processes data outside the EU/UK/Switzerland — nearly every US-based AI provider does — the DPA also needs a valid transfer mechanism. Standard Contractual Clauses (SCCs) are the common one, and you'll see them referenced inside most of the DPAs below.

Getting a DPA from your AI/LLM provider

Here's the contrast with BAAs worth internalizing: most of these are already in place, not something you have to request and wait on. As always, verify current terms directly with the provider before relying on any of this.

OpenAI. Not automatic — you complete an online form ("Execute Data Processing Agreement") with your legal entity name, signatory name/title/email, and billing entity if different. You need a company account; a personal email on the org won't work. OpenAI has reported returning a countersigned PDF by email within minutes of submission.

Anthropic (Claude). Automatic. The DPA and its SCCs are incorporated by reference into Anthropic's Commercial Terms of Service — accepting those terms on a paid plan means you've accepted the DPA too, no separate signature. You can view it through the Anthropic customer portal.

Google (Cloud / Vertex AI). Self-serve, in the same place as the HIPAA BAA: Cloud Console → IAM & Admin → Privacy → review and accept the Cloud Data Processing Addendum. One acceptance covers your whole Google Cloud account, not per project.

Microsoft Azure. Automatic. The Data Protection Addendum is part of the standard Microsoft Products and Services terms and applies the moment you're on an eligible agreement — nothing extra to sign.

xAI. Published at x.ai/legal/data-processing-addendum and structured around GDPR's Module Two/Three SCCs. Unlike the BAA questionnaire, xAI's public documentation doesn't describe a separate approval gate for the DPA — but confirm directly whether it applies automatically under your commercial terms or needs explicit execution, since this is the newest and least-documented of the five processes here.

Tracking these too

The same discipline that applies to BAAs applies here: a DPA on file — or incorporated by reference — with each processor touching EU/UK/Swiss personal data belongs in the same agreement inventory as your BAAs, MSAs, and vendor contracts, reviewed on a schedule. Better to find a gap there than discover it during a regulator inquiry or a customer's security questionnaire.

Share

Get new posts by email

SOC 2, HIPAA, post-quantum readiness, and the engineering behind continuous compliance. No spam, unsubscribe anytime.

Comments

Leave a comment

Signed in as — only visible to moderators, never shown publicly.

Shown publicly next to your comment — your account isn't otherwise revealed. Clear it for a random pseudonym instead.