If your SaaS processes personal data on behalf of EU customers, a Data Processing Agreement is not a "nice to have", it is the contract that GDPR explicitly requires. Article 28 sets out exactly what that contract has to contain, and the cost of getting it wrong has gone up. The DLA Piper survey published in January 2026 puts cumulative GDPR fines past EUR 7.1 billion since the regulation took effect, with a meaningful share of recent enforcement traced to inadequate or missing processor agreements. This guide walks through the nine mandatory elements of a DPA, how Standard Contractual Clauses fit in, and the negotiation moves worth picking your battles on.

What a DPA actually is, and what it is not

A Data Processing Agreement is the contract between a controller (your customer, the one who decides what to do with personal data) and a processor (you, the SaaS handling the data on their behalf). It does not replace the underlying service agreement. It supplements it with GDPR-specific clauses.

A DPA is also not a privacy policy. A privacy policy is what you tell end users. A DPA is what you commit to your business customer. The two documents address different audiences and have different legal weight. A SaaS that ships only a privacy policy and never offers a DPA is, in GDPR terms, missing the contractual artifact that Article 28 demands.

The scope frame: what the contract must define before the obligations

Before you get to the eight processor obligations, Article 28(3) requires the DPA to define the perimeter of the processing relationship. This is the first clause and it is non-negotiable. The contract must set out:

  • Subject matter of the processing. "Customer support ticket management" or "marketing analytics platform" is a usable level of specificity.
  • Duration of the processing. Usually tied to the term of the underlying subscription plus a retention period for backups and logs.
  • Nature and purpose of the processing. The "why" of what you do with the data, not just the "how".
  • Type of personal data and categories of data subjects. Email addresses, IP addresses, usage telemetry; employees of the controller, end users of the controller's product, prospects in a CRM.
  • Obligations and rights of the controller. Right to instruct, right to audit, right to receive data back at termination.

Practical tip: many SaaS DPAs link out to an Exhibit A that lists this scope so the body of the contract stays stable while the exhibit evolves with the product.

The eight processor obligations under Article 28(3)

Once the scope is defined, Article 28(3) lists eight specific obligations the processor commits to. These are not abstract principles. They are clauses your DPA needs to contain, almost verbatim.

(a) Process only on documented instructions

The processor "processes the personal data only on documented instructions from the controller". This includes transfers outside the EEA, which can only happen if the controller authorizes them or law requires them. In practice, this clause is what limits a SaaS from using customer data to train shared models or do anything the customer has not explicitly approved.

(b) Confidentiality of authorized persons

Anyone on the processor's side who can access the personal data must have committed to confidentiality or be subject to a statutory confidentiality obligation. Standard employment contracts with a confidentiality clause cover this, but the DPA needs to say so explicitly.

(c) Security measures under Article 32

The processor must take all measures required by Article 32, which is the security article of the GDPR. Encryption, integrity, resilience, regular testing. The DPA does not need to list every control, but it must commit to the Article 32 standard. Most modern DPAs reference a Security Annex that itemizes the controls (SOC 2, ISO 27001, encryption at rest and in transit).

(d) Subprocessor conditions

The processor cannot engage another processor without prior specific or general written authorization. With general authorization, the processor commits to inform the controller of intended changes and to give the controller the right to object. With specific authorization, every subprocessor is named in writing before being engaged. The DPA picks one model and lives with it.

(e) Assist with data subject rights

The processor assists the controller in responding to data subject requests under Chapter III of the GDPR (access, rectification, erasure, portability, objection, restriction). "Assists" is the operative word: the controller is the one fulfilling the request to the data subject, but the processor has to make the data available, deliver it in a usable format, and act in a reasonable timeframe.

(f) Assist with security, breach notification, DPIAs

The processor assists with the broader compliance obligations under Articles 32 to 36: keeping data secure, notifying the controller of breaches without undue delay, contributing to data protection impact assessments when the controller asks. The DPA usually fixes a maximum breach notification window — 24, 48, or 72 hours from awareness on the processor side.

(g) Delete or return data at the end

At termination of the underlying service, the processor either deletes all personal data or returns it to the controller, deleting copies unless law requires retention. Most SaaS DPAs allow a brief grace period (30 to 90 days) for the customer to export, then proceed to deletion. Backups have their own retention period that the DPA must spell out.

(h) Make information available and allow audits

The processor "makes available to the controller all information necessary to demonstrate compliance" and contributes to audits, including inspections. Enterprise customers will exercise this clause. The cleanest implementation is a Trust Center with current SOC 2 reports, ISO certificates, pen test summaries, and a documented audit procedure for everything beyond what is published.

The eight obligations are not optional. A DPA that drops any of them does not satisfy Article 28, even if it adds a dozen other clauses on top. When a SaaS sends a DPA, the first check the customer's legal team will do is "are all eight obligations present?".

Where Standard Contractual Clauses fit

Article 28(7) gives the European Commission the power to publish Standard Contractual Clauses (SCCs) for processor agreements. In practice there are two relevant SCC families:

  • Module-based EU SCCs (2021) for controller-to-processor transfers outside the EEA. If your servers or your subprocessors are in the US, India, or anywhere without an adequacy decision, your DPA needs to incorporate the right SCC module.
  • The UK International Data Transfer Addendum, which sits on top of the EU SCCs for UK transfers post-Brexit.

SCCs are not optional and you do not get to rewrite them. They are incorporated by reference, with the parties' details slotted into the annexes. The DPA spells out which transfer mechanism applies (adequacy, SCCs, BCRs) for each subprocessor's location.

Negotiation patterns worth knowing

Most SaaS DPAs are presented to the customer as a take-it-or-leave-it template. For most customers, that works. Enterprise customers push back, and the pushback tends to fall in predictable places.

  • Audit rights: customers want unlimited on-site audits; processors want documentation review at most. The usual landing spot is "documentation review by default, on-site audit with reasonable notice and during business hours for cause".
  • Breach notification window: customers want 24 hours from incident; processors want 72 hours from confirmed breach. 48 hours from confirmation is a common middle ground.
  • Subprocessor objection window: customers want 30 days; processors want 7. 14 days is the typical settlement.
  • Liability cap: processors want it tied to the service fees; customers want it uncapped for data protection breaches. Carved exceptions for GDPR fines is a workable compromise.

The Spanish AEPD issued over 40 sanctions in 2024 alone where DPA insufficiency was a contributing factor. The pattern in those decisions is consistent: missing clauses, vague subprocessor language, no audit rights. Negotiating away your obligations is not the same as negotiating the implementation. The obligations stay regardless.

Where Termerly fits in your DPA workflow

Termerly is a host and editor for the legal pages your customers will read, including a DPA. It does not negotiate the contract for you and it does not redline an MSA, but it handles the parts that benefit from versioning and public hosting.

  • You can publish your standard DPA on a permanent URL, link it from the order form, and reference it by version in customer agreements.
  • Every revision creates an immutable snapshot. A customer who signed in May 2024 can prove which version of the DPA was in force at that time by opening the permalink to the version they accepted.
  • The diff viewer shows additions and removals between any two versions. When you update the subprocessor list or the breach notification window, the diff is what you send to enterprise customers on your annual change cycle.
  • If you operate several SaaS products under one company, each project keeps its own DPA. A customer of Product A is not shown the DPA of Product B.

Conclusion

Article 28 is one of the few parts of the GDPR with a clear checklist. Define the scope, commit to the eight processor obligations, attach the right SCC module for cross-border transfers, and version the document so you can show what was in force on any given day. That is the working DPA. Skip any of the nine elements and your contract is incomplete; rewrite them with carveouts and you are negotiating away enforceability.

If you do not have a published DPA yet, or yours lives in a Google Doc with no version history, open a free Termerly project and publish the first version this week. The link is what a procurement team will ask for. The audit trail is what protects you when they come back next year.