A DPA (data processing agreement) is a legally binding contract between a data controller and a data processor that sets out how the processor may handle personal data on the controller’s behalf, for what purpose, under which security measures and with which obligations. Under the GDPR, the DPA is the document a software vendor signs with each business customer whose personal data flows through the service.
The DPA became standard practice through the EU General Data Protection Regulation (GDPR), whose Article 28 requires a written contract whenever a controller uses a processor. Similar requirements exist under the UK GDPR, and comparable contract terms are expected under other privacy laws such as the California Consumer Privacy Act. For a SaaS company, a ready DPA template is a routine part of selling to businesses, and missing one can block deals during procurement.
Roles and purpose of a DPA
A DPA exists because data protection law assigns different responsibilities to controllers and processors. The customer, as controller, decides why and how personal data is processed; the SaaS vendor, as processor, acts only on the customer’s documented instructions.
The table below explains the parties that a typical SaaS DPA involves.
| Role | Who it usually is | Core responsibility |
|---|---|---|
| Controller | The business customer | Decides purposes and means of processing |
| Processor | The SaaS vendor | Processes data only on documented instructions |
| Sub-processor | Hosting, email or support providers used by the vendor | Processes data under flowed-down terms |
| Data subjects | Employees, users or end customers of the controller | Hold rights over their personal data |
| Supervisory authority | National data protection regulator | Enforces the law and receives breach reports |
The DPA allocates accountability. If a vendor processes data for its own purposes, such as training its own models or marketing, it may become a controller for that activity, which needs a separate legal basis and should be stated clearly rather than hidden in the DPA.
Mandatory clauses under GDPR Article 28
Article 28 lists minimum terms that every processor contract must contain. Most SaaS DPAs follow this list closely, adding commercial details around it.
| Required term | What it means in practice |
|---|---|
| Documented instructions | Vendor processes data only as the customer directs |
| Confidentiality | Staff with access are bound to confidentiality |
| Security measures | Technical and organizational measures under Article 32 |
| Sub-processor rules | Prior authorization, notice of changes, flowed-down terms |
| Assistance with data subject rights | Vendor helps answer access, deletion and similar requests |
| Breach and compliance assistance | Vendor notifies breaches and supports impact assessments |
| Deletion or return | Data is deleted or returned at the end of service |
| Audit and information rights | Customer can verify compliance through audits or reports |
Commercial DPAs add details the law leaves open, such as breach notification timing, audit frequency and cost, and liability caps. Because the controller must report qualifying breaches to the authority within 72 hours of becoming aware, customers typically require processors to notify them without undue delay, often within 24 to 72 hours.
International transfers and sub-processors
Many SaaS vendors host data or run support teams outside the customer’s jurisdiction, so the DPA must also cover international data transfers. Under GDPR, transfers outside the European Economic Area need a valid mechanism, most often the Standard Contractual Clauses adopted by the European Commission in 2021 or an adequacy decision for the destination country.
Sub-processors are listed in an annex or on a public page, and the vendor commits to notify customers before adding new ones, usually with a window of around 30 days to object. The table below compares common transfer mechanisms.
| Mechanism | When it applies | Additional work |
|---|---|---|
| Adequacy decision | Destination recognized as adequate | Little beyond normal DPA terms |
| Standard Contractual Clauses | Most transfers to other countries | Transfer impact assessment |
| Binding corporate rules | Transfers within one corporate group | Regulator approval, long process |
| UK transfer addendum or IDTA | Transfers subject to UK GDPR | Attach to or replace SCCs |
DPA compared with related SaaS documents
A DPA is one of several documents in a SaaS contract stack, and each governs a different risk. Confusing them leads to gaps, such as relying on a privacy policy for obligations that only a DPA can create.
| Document | Main purpose | Audience |
|---|---|---|
| DPA | Rules for processing customer personal data | Business customers |
| Terms of service or master agreement | Commercial and legal terms of the service | All customers |
| Service level agreement | Uptime commitments and service credits | Paying customers |
| Privacy policy | Notice about the vendor’s own data use | Users and the public |
| Security documentation | Description of controls and certifications | Security reviewers |
Related operational practices support the DPA. Tenant isolation limits the impact of a breach on other customers, a status page communicates incidents, and a clear product sunset process ensures data deletion when a service is retired.
Common DPA pitfalls
DPA problems typically surface during enterprise procurement or after an incident. The most frequent issues are listed below.
- Outdated sub-processor list: adding a new analytics or support tool without notice breaches the agreement.
- Promises the product cannot keep: committing to deletion within days when backups retain data for months creates contract breaches.
- Negotiating every DPA separately: custom terms for each customer make compliance hard to operate; most vendors keep one standard DPA with limited negotiable points.
- Vague security annex: generic statements fail security reviews; buyers expect concrete controls such as encryption, access control and logging.
- Uncapped liability: some customers request unlimited data protection liability, which vendors usually limit with a separate, higher cap.
Stripped to the essentials
A DPA is a rulebook for handling other people’s data. When a company uses an online service that stores its customers’ or employees’ information, both sides sign this agreement.
It says what the service provider may do with the data, how it must protect it, who else may touch it and what happens if something goes wrong. The customer stays in charge of the data, and the provider promises to follow its instructions.
Where it is applied
A SaaS company sells customer support software that stores email conversations and contact details. A hospital network in Germany wants to buy it, and its procurement team will not sign without a DPA that covers GDPR Article 28.
The vendor provides its standard DPA, which lists its cloud hosting and email delivery providers as sub-processors, commits to notify security incidents within 48 hours, describes encryption at rest and in transit, and includes the Standard Contractual Clauses for its support team located outside the European Union. The hospital requests a shorter deletion period after contract end, and the vendor agrees to delete production data within 30 days and backups within 90 days.
Because the DPA was ready and matched how the product actually operates, the review closes in weeks rather than months, and the deal is signed with clear, enforceable data protection terms.