A Data Processing Agreement — known in German as an Auftragsverarbeitungsvertrag (AVV) — is the contract the GDPR requires whenever one organisation processes personal data on behalf of another. Wherever a controller hands data to a processor, that relationship must be governed by a written agreement meeting specific legal requirements. For SaaS companies, which are almost always processors for their customers’ data, the DPA is one of the most frequently needed and most scrutinised contracts.
Why the GDPR requires a DPA
The GDPR insists on a DPA because outsourcing the handling of personal data does not outsource responsibility for it. The controller remains accountable, so the law requires a contract that binds the processor to handle the data only as instructed and to protect it appropriately. The DPA is the instrument that carries the controller’s obligations down the chain to everyone who touches the data on its behalf, creating an unbroken line of accountability.
When a DPA is needed
A DPA is required whenever a processor handles personal data for a controller. In practice this covers a vast range of relationships: a company using a cloud-hosted CRM, an online service using a payment provider, a business using an email-delivery platform. If a vendor processes personal data on your instructions, a DPA must be in place before that processing begins. The absence of one is itself a breach, regardless of whether anything goes wrong.
Mandatory contents under Article 28
The GDPR specifies what a DPA must contain. It must set out the subject matter and duration of the processing, its nature and purpose, the types of personal data and categories of individuals involved, and the obligations and rights of the controller. It must also bind the processor to a defined set of duties — the operative core of the agreement — which the regulation enumerates in detail. A DPA missing these elements does not meet the legal standard.
The processor’s core obligations
Under the DPA, the processor must process data only on documented instructions from the controller, ensure that personnel are bound by confidentiality, implement appropriate security measures, and assist the controller in meeting its own obligations — including responding to data-subject requests and handling breaches. It must also delete or return the data at the end of the engagement and make available the information needed to demonstrate compliance, submitting to audits where required.
Sub-processors
Processors frequently rely on their own vendors — sub-processors — such as cloud infrastructure providers. The DPA must address this: the processor needs the controller’s authorisation to engage sub-processors, must flow down equivalent data-protection obligations to them, and remains fully liable to the controller for their performance. Maintaining an up-to-date list of sub-processors and notifying customers of changes is now standard practice for SaaS providers.
Security measures
The DPA commits the processor to appropriate technical and organisational measures to protect the data, proportionate to the risk. These typically include encryption, access controls, logging, and tested backup and recovery. While the specifics depend on the service, the DPA is where the security commitment becomes contractually binding — transforming security from a marketing claim into an enforceable obligation the controller can rely on.
Assisting the controller
A defining feature of the DPA is the processor’s duty to assist. The controller must be able to meet its GDPR obligations, and it often depends on the processor to do so — for example, to help locate and export an individual’s data for an access request, or to provide breach details quickly. A well-drafted DPA sets out how and how quickly this assistance is provided, which matters because the controller’s deadlines are tight.
International transfers in the DPA
Where a processor or its sub-processors handle data outside the EU, the DPA must address the transfer safeguards the GDPR requires, such as standard contractual clauses. For SaaS companies using global cloud infrastructure, this is a recurring point of negotiation. Offering EU data residency simplifies the analysis considerably and is increasingly expected by privacy-conscious DACH customers.
The DPA from the SaaS provider’s side
For a SaaS company, providing a clear, GDPR-compliant DPA is both a legal necessity and a sales enabler. Enterprise customers will not sign without one, and a well-prepared, readily available DPA shortens procurement cycles. The sensible approach is a standard DPA, aligned with Article 28, that covers security, sub-processors, transfers, and assistance — ready to provide rather than negotiated from scratch each time.
Common pitfalls
Frequent mistakes include operating without a DPA at all, using a generic template that omits required elements, failing to flow obligations down to sub-processors, and neglecting to update the agreement when the processing or sub-processor list changes. Each leaves a gap in the accountability chain the GDPR is built to protect. A periodic review of DPAs — both those a company signs and those it provides — catches these issues before they become liabilities.
Conclusion
The Data Processing Agreement is the GDPR’s mechanism for carrying data-protection accountability from controller to processor and beyond. Required whenever personal data is processed on another’s behalf, it must meet the specific contents set out in Article 28 and bind the processor to security, confidentiality, sub-processor control, and assistance. For SaaS companies, a clear, ready-to-provide DPA is both a compliance requirement and a competitive advantage.