What is a Data Processing Agreement (DPA) Under GDPR?

The contract your SaaS stack probably needs

Under GDPR, every time you share personal data with a third-party vendor who processes it on your behalf, you need a Data Processing Agreement (DPA). Most SaaS founders ignore this until they're due diligence'd by an enterprise customer — and then scramble. Here's what you actually need to know.

What is a DPA?

A Data Processing Agreement (sometimes called a Data Processing Addendum — same abbreviation, same thing) is a binding contract between:

• The Data Controller — you, the company that determines the purposes and means of processing (i.e., decides what data to collect and why)
• The Data Processor — a vendor or service provider that processes personal data on your behalf (your hosting provider, email platform, analytics tool, CRM, etc.)

GDPR Article 28 mandates that this contract exist whenever a controller uses a processor. Without it, you're in violation — regardless of whether any harm occurs.

When do you need a DPA?

You need a DPA whenever a third party processes personal data on your behalf. Common examples:

• Cloud infrastructure: AWS, Google Cloud, Azure, Vercel, Supabase
• Email/communication: Mailchimp, SendGrid, Resend, Intercom, Zendesk
• Analytics: Google Analytics, Mixpanel, Amplitude, Posthog
• CRM/marketing: HubSpot, Salesforce, ActiveCampaign
• Payment processing: Stripe (though Stripe acts as an independent controller for some data)
• Error monitoring: Sentry, Datadog
• AI providers: OpenAI, Anthropic, Google (if passing user data through their APIs)

What must a DPA include under Article 28?

GDPR Article 28(3) specifies the mandatory content. A compliant DPA must cover:

• Subject matter and duration — what data is processed and for how long
• Nature and purpose of processing — what the processor actually does with the data
• Type of personal data — categories of data involved
• Categories of data subjects — who the data relates to (customers, employees, users)
• Obligations and rights of the controller

And the processor must contractually commit to:

• Process data only on documented instructions from the controller
• Ensure confidentiality (all authorised persons are bound by it)
• Implement appropriate technical and organisational security measures (Article 32)
• Respect sub-processor rules (get controller approval, impose same obligations on sub-processors)
• Assist the controller with data subject rights requests
• Assist with Article 32/33/34/35/36 obligations (security, breach notification, DPIA)
• Delete or return all data at end of contract
• Provide all information necessary to demonstrate compliance and allow audits

The sub-processor chain

This is where it gets complex. If your processor (e.g., your CRM) uses sub-processors (e.g., their cloud hosting provider), GDPR requires:

• The processor gets your prior authorisation before adding sub-processors
• The processor imposes the same data protection obligations on sub-processors via a written contract
• The processor remains liable to you for sub-processor failures

Major SaaS vendors publish their sub-processor lists. If you don't see this list, ask for it.

How to get DPAs in practice

The good news: most serious SaaS vendors have standard DPAs available, often as a self-serve addendum to their Terms of Service:

• AWS: available in AWS Artifact (automatic if you accept their Data Processing Addendum in console)
• Google Workspace/GCP: DPA in account settings, auto-executed on acceptance
• Stripe: Data Processing Agreement in Stripe Dashboard legal section
• OpenAI: DPA available for API users (API usage defaults to no training on your data)
• Supabase: DPA available on request / self-serve for Pro plans

Smaller vendors may not have a DPA ready. In that case, you can provide your own template for them to sign, or choose a different vendor. If a vendor refuses to sign a DPA, that's a red flag for enterprise sales — and arguably a GDPR violation on your part if you continue using them.

The other kind of DPA: when you're the processor

If your SaaS processes data on behalf of your B2B customers (i.e., your customers are the controllers), they need a DPA with you. This means:

• You need a DPA template in your Terms of Service or as a standalone addendum
• Enterprise customers will often send you their own DPA to sign — review carefully
• Your DPA must cover Article 28(3) requirements from the processor side

This is one of the highest-friction parts of enterprise SaaS sales. Having a clean, well-drafted DPA that enterprise legal teams can review quickly is a competitive advantage.

Common mistakes

• No DPA at all — most common. Vendors process your users' data; you have no contract governing it.
• DPA that doesn't name sub-processors — Article 28(2) requires written authorisation for sub-processors. A blank approval is weak; try to get a list.
• No DPA for AI providers — If you're passing user data through OpenAI, Anthropic, etc., you need a DPA. Check their terms carefully — they often have one for API users.
• Treating joint controllers as processors — If both you and your vendor independently determine processing purposes, you're joint controllers, not controller-processor. The contract requirements are different.

Generate your GDPR DPA now

ComplyKit's free GDPR Data Processing Agreement generator creates a complete Article 28 DPA tailored to your SaaS — including your sub-processor list, technical and organisational measures, breach notification clause, and international transfer provisions. Generate it in under 5 minutes.