Data Processing Agreements (DPA) Under GDPR

Every time your SaaS company shares personal data with a third-party service — your cloud hosting provider, your email platform, your analytics tool, your CRM — GDPR requires a Data Processing Agreement between you and that provider. No DPA, no lawful basis for the data transfer. It’s that straightforward.

Article 28 of the GDPR sets out the rules. When a controller (the organization that decides why and how data is processed) engages a processor (the organization that processes data on the controller’s behalf), the relationship must be governed by a contract that includes specific mandatory provisions.

For SaaS companies, this cuts both ways. You’re almost certainly a controller engaging processors — every vendor in your stack that touches personal data needs a DPA. And if your customers entrust their data to your platform, you’re also a processor, which means your customers need a DPA from you.

This guide covers both sides: what to look for in the DPAs you sign with vendors, and what to include in the DPA you offer to your customers.

What Is a DPA?

A Data Processing Agreement is a legally binding contract between a controller and a processor that governs how personal data is processed. It’s not a standalone privacy policy or a vague data protection addendum — it’s a specific contract required by Article 28(3) of the GDPR.

The DPA must:

• Be in writing (including electronic form)
• Be binding on the processor
• Set out the subject matter, duration, nature, and purpose of processing
• Define the types of personal data and categories of data subjects
• Specify the controller’s obligations and rights

Think of the DPA as the operating manual for a data processing relationship. It tells the processor exactly what they can and cannot do with the data, and it gives the controller the assurance and control that GDPR demands.

What Must a DPA Include?

Article 28(3) specifies eight mandatory obligations that the DPA must impose on the processor. Here’s what each one means in practice:

1. Process Only on Documented Instructions

Article 28(3)(a)

The processor must only process personal data on the controller’s documented instructions. This prevents processors from using your data for their own purposes — training AI models, building aggregate analytics products, or targeting ads.

In practice: The DPA should specify exactly what the processor is authorized to do with the data. “Store and process customer data to provide the contracted service” is a reasonable instruction. If the processor wants to use data for product improvement or benchmarking, that should require separate, explicit authorization.

2. Confidentiality Obligations

Article 28(3)(b)

Anyone authorized to process the data (the processor’s employees, contractors) must be subject to confidentiality obligations, either by contract or by statutory obligation.

In practice: The DPA should require that the processor ensures all personnel with access to personal data have signed confidentiality agreements and have received appropriate data protection training.

3. Security Measures

Article 28(3)(c)

The processor must implement appropriate technical and organizational security measures as required by Article 32.

In practice: The DPA should reference specific security standards or certifications (SOC 2, ISO 27001) or list concrete measures: encryption at rest and in transit, access controls, regular security testing, incident response procedures. Vague language like “appropriate security” without specifics is a red flag.

4. Sub-Processor Requirements

Article 28(3)(d)

The processor must not engage another processor (a sub-processor) without the controller’s prior written authorization. The DPA can provide either:

• Specific authorization: The controller approves each sub-processor individually
• General authorization: The controller pre-approves the use of sub-processors, but the processor must notify the controller of any changes, giving the controller the opportunity to object

In practice: Most large SaaS vendors use general authorization with a published sub-processor list and a notification mechanism for changes. You should receive advance notice (typically 30 days) of any new sub-processor, with the right to object. If the vendor adds a sub-processor you’re uncomfortable with and won’t accommodate your objection, you should have the right to terminate.

5. Assist with Data Subject Rights

Article 28(3)(e)

The processor must assist the controller in responding to data subject requests — access, rectification, erasure, portability, restriction, and objection.

In practice: The DPA should specify how the processor will help you fulfill data subject access requests and other rights requests. This includes providing data exports, enabling data deletion, and responding to requests within reasonable timeframes.

6. Assist with Security and Breach Obligations

Article 28(3)(f)

The processor must assist the controller with security obligations under Articles 32–36, including breach notification, DPIAs, and prior consultation with supervisory authorities.

In practice: The DPA should require the processor to notify you of any personal data breach without undue delay (and ideally within a specific timeframe — 24 or 48 hours is common). This gives you time to assess the situation and meet your own 72-hour notification obligation to the supervisory authority.

7. Data Deletion or Return

Article 28(3)(g)

At the end of the processing relationship, the processor must either delete or return all personal data, and delete any existing copies unless EU or member state law requires continued storage.

In practice: The DPA should specify the deletion timeline (e.g., within 30 days of contract termination), provide for data export/return before deletion, and confirm that deletion extends to all backups and copies.

8. Audits and Inspections

Article 28(3)(h)

The processor must make available all information necessary to demonstrate compliance and allow for audits and inspections by the controller or an appointed auditor.

In practice: This doesn’t mean you need to physically audit every vendor. Many processors satisfy this through third-party audit reports (SOC 2 Type II, ISO 27001 certificates), supplementary questionnaires, and the right to request additional audits if needed. The DPA should specify the audit mechanism.

DPAs for SaaS Companies: Both Sides

As a Controller: DPAs with Your Vendors

Most SaaS companies have dozens of vendors that process personal data. Common categories:

Infrastructure: AWS, Google Cloud, Azure, Cloudflare, Vercel

• These vendors typically offer comprehensive DPAs as part of their service agreements. Review them — don’t just click “Accept.”

Communication & Marketing: Mailchimp, Customer.io, Sendgrid, HubSpot, Intercom

• Marketing platforms often process significant amounts of personal data. Pay attention to their data usage policies and sub-processor lists.

Analytics: Amplitude, Mixpanel, Google Analytics, Hotjar

• Analytics vendors may operate in a gray area between processor and independent controller. Clarify their role in the DPA.

Payments: Stripe, Braintree, Adyen

• Payment processors often act as independent controllers for certain processing activities (fraud prevention, compliance with financial regulations). Understand which data they control vs. process.

Support: Zendesk, Freshdesk, Intercom

• Support platforms store rich personal data including unstructured text in ticket conversations. Ensure the DPA covers all data types.

HR & Internal: BambooHR, Gusto, Slack, Google Workspace

• Employee data is personal data too. DPAs with HR platforms are just as important as customer-facing ones.

As a Processor: Your Customer-Facing DPA

If your SaaS product processes data on behalf of your customers, you need to offer a DPA. This is typically:

• A standalone document linked from your website
• An addendum to your Terms of Service
• Part of your enterprise contract package

Your customer-facing DPA should address all eight Article 28(3) requirements from the processor’s perspective. It should be clear about your sub-processors, your security measures, your breach notification commitments, and your data deletion procedures.

Publishing your DPA publicly (as companies like Notion, Linear, and Vercel do) signals maturity and accelerates enterprise sales cycles. Prospects can review it before engaging procurement.

Managing DPAs at Scale

At a 50-person SaaS company, you might have 30–50 vendors processing personal data. Managing their DPAs manually creates predictable problems:

Tracking status. Which vendors have signed DPAs? Which are using outdated versions? Which new vendors were onboarded without a DPA at all?

Monitoring sub-processor changes. Vendors update their sub-processor lists regularly. Are you reviewing these notifications? Do you have a process for objecting if a new sub-processor is problematic?

Renewal and review cycles. DPAs should be reviewed periodically, especially when vendors update their terms, when you change how you use a vendor, or when regulatory guidance evolves.

Connecting to your ROPA. Each DPA should correspond to entries in your Record of Processing Activities. When a vendor relationship changes, both documents need updating.

DPA Red Flags to Watch For

When reviewing a vendor’s DPA, watch for these warning signs:

Unlimited sub-processing without meaningful notification. If a vendor can add sub-processors without notifying you, or with notification but no right to object, you’ve lost a significant control mechanism. You should know who’s handling your data.

Liability caps that shift all risk to you. Some DPAs limit the processor’s liability for data breaches to a nominal amount while the controller bears all regulatory and civil liability. The DPA should reflect a reasonable allocation of responsibility.

No specific deletion timeline. “We will delete data within a reasonable period after termination” is too vague. Push for a defined timeline — 30 days is standard.

Vague security commitments. If the security section says nothing more than “we implement appropriate technical and organizational measures,” there’s no substance to enforce. Look for specific measures, certifications, or standards.

Missing international transfer safeguards. If the processor transfers data outside the EEA, the DPA must specify the legal mechanism. If it’s silent on international transfers, either transfers don’t occur (verify this) or the DPA is incomplete. See our international data transfers guide for what’s required.

Data usage for the processor’s own purposes. Watch for language that allows the processor to use your data for “service improvement,” “analytics,” or “machine learning.” This is the processor acting as an independent controller — and it changes the legal picture significantly.

How GRCTrail Manages Your DPAs

GRCTrail provides a centralized vendor and DPA management system:

Vendor registry with DPA status tracking. Every third-party processor is catalogued with their DPA status, version, signing date, and next review date. See at a glance which vendors need attention.

Sub-processor change alerts. When vendors update their sub-processor lists, GRCTrail flags the changes for your review. No more missed notification emails buried in a shared inbox.

Automated review reminders. Set review cadences for each DPA and receive notifications when reviews are due. Never let a DPA go stale because no one remembered to check it.

Connected to your ROPA. Each vendor’s DPA links directly to the relevant processing activities in your Record of Processing Activities. Change one, and you’ll see where the other needs updating.

Track every vendor DPA in one place →

Related Guides

• Records of Processing Activities (ROPA) — Document your processing activities
• International Data Transfers — Transfer mechanisms for cross-border data flows
• GDPR Compliance Checklist — The full compliance framework
• Privacy Notice Requirements — What you must tell data subjects

Get started with GRCTrail →