Data Processing Agreement (DPA)
Also known as: DPA, data processing contract, processor agreement, GDPR Article 28 agreement
A Data Processing Agreement (DPA) is a legally binding contract between a data controller (the organization that determines the purposes of data processing) and a data processor (an organization that processes data on the controller's behalf).
Under GDPR Article 28, controllers must only use processors that provide sufficient guarantees about data security and must put a DPA in place before any processing begins. The DPA specifies the subject matter, duration, nature, and purpose of the processing; the type of personal data and categories of data subjects; and the obligations and rights of the controller.
Data Processing Agreement (DPA), explained at three levels
At home
When a company hires another company to handle personal data on its behalf -- like hiring a payroll service to process employee salaries or a cloud provider to store customer records -- the law requires a written agreement spelling out exactly what the second company can and cannot do with that data. That agreement is the data processing agreement. Without it, the company sharing the data is potentially in violation of GDPR, even if the processor is trustworthy. The DPA is not optional -- it is a legal requirement under EU privacy law.
At work
A DPA is required any time your organization shares personal data with a third-party vendor that will process it on your behalf. Common examples: a cloud hosting provider storing your customer database, a marketing platform sending emails to your customers, a payroll bureau processing your employees' salaries, a customer support tool managing your support tickets. The DPA makes clear that the processor can only use the data for the purposes you specify, must implement appropriate security, must delete or return the data at the end of the contract, and must notify you of any data breaches.
At home
GDPR Article 28(3) specifies the mandatory contents of a DPA: the processing takes place only on documented instructions from the controller; processors must ensure confidentiality obligations; processors must implement appropriate technical and organizational security measures; processors must respect conditions for engaging sub-processors; processors must assist the controller with data subject rights requests, security obligations, breach notifications, DPIAs, and audits; processors must delete or return all personal data at the end of the relationship; and processors must provide the controller with all information necessary to demonstrate compliance.
At work
Sub-processors are third parties that a processor uses to perform part of the processing on the controller's behalf -- for example, a SaaS vendor using Amazon Web Services as infrastructure. GDPR requires controllers to authorize sub-processors either generally or specifically, and the DPA must impose the same data protection obligations on sub-processors as apply to the main processor. When processors engage new sub-processors, they must notify the controller, who has the right to object. This creates a chain of contractual data protection obligations flowing from controller to processor to sub-processor.
At home
International data transfers require additional protections beyond a standard DPA. When personal data flows from the EU to a country without an EU adequacy decision (such as the US), an additional transfer mechanism must be in place -- typically the EU Standard Contractual Clauses (SCCs), which include processor obligations that mirror a DPA. The UK GDPR has its own set of International Data Transfer Agreements (IDTAs) and Addenda for transfers outside the UK. Canada's PIPEDA requires equivalent protection for data transferred to service providers.
At work
From a practitioner standpoint, the most common DPA failure is treating it as a one-time paper exercise rather than an active contract management obligation. DPAs must be updated when processing activities change materially -- if you start sharing a new data category with a vendor, or if the vendor starts using a new sub-processor in a new country, the DPA must be reviewed. Controllers should maintain a processor register listing all DPAs, the personal data involved, the processing purpose, and the last review date. A vendor that cannot or will not sign a DPA should not receive personal data -- the DPA requirement is non-negotiable under GDPR.
Real-world examples
At home
Priya set up a small e-commerce shop and used Mailchimp to send marketing emails to her subscribers. Before importing her subscriber list, Mailchimp's setup process walked her through agreeing to a DPA as part of their terms of service -- automatically putting the required legal agreement in place before any personal data was transferred.
At work
The legal team at Clearwater Analytics reviewed all vendor contracts after a GDPR audit found that three data processors -- including their CRM provider -- did not have signed DPAs in place. The team engaged each vendor to execute a DPA before any further processing occurred, and established a new vendor onboarding checklist requiring a DPA review as a mandatory step before any personal data could be shared with a new vendor.
Common confusions
- A DPA is not a privacy policy. A privacy policy is a public-facing notice telling individuals how the organization processes their data. A DPA is a B2B contract between the organization and its vendors that defines how vendors may handle personal data they receive. They serve different audiences and different legal purposes.
- Not every vendor agreement involving personal data requires a DPA -- only those where the vendor acts as a processor (processing data on the controller's behalf for the controller's purposes). If a vendor receives personal data but uses it for its own purposes (such as a bank receiving your money and using your financial data to make credit decisions), the vendor is a joint controller, not a processor, and the relationship requires a different type of agreement.
- A DPA signed once is not sufficient for the lifetime of a vendor relationship. DPAs must be revisited when the scope of processing changes, when the vendor changes sub-processors in relevant ways, when data transfer mechanisms change (for example, when EU SCCs are updated), and when regulatory requirements change. A DPA that was compliant in 2018 may not satisfy all requirements of current guidance from data protection authorities.
For analysts
In BA artefacts, DPA requirements appear as procurement prerequisites for any system that will share personal data with third-party vendors. When documenting requirements for a new system integration, include a constraint: 'No personal data may be transferred to [Vendor X] until a GDPR-compliant DPA is in place, reviewed and signed by the Data Protection Officer.' BAs documenting data flows in process models should flag each external data flow involving personal data for DPA review. A common gap is discovering during testing that a system integration shares personal data with a vendor for whom no DPA exists -- catching this in requirements is far less costly than discovering it in a regulatory audit.
History & origin
Data processing agreements were formalized in EU law with the original EU Data Protection Directive (1995), which required written contracts between controllers and processors. GDPR (2018) significantly strengthened these requirements: Article 28 specifies mandatory contractual clauses that must appear in every controller-processor agreement, removes discretion about whether to have a DPA (it is always required), and imposes direct legal obligations on processors (not just controllers) for the first time. The EU Standard Contractual Clauses (SCCs) for international data transfers also function as a type of DPA when data flows from the EU to third countries without an adequacy decision.