What is a Data Processing Agreement (DPA)?

A Data Processing Agreement is a legally binding contract between a data controller and a data processor. It regulates the specific terms under which the processor is allowed to handle personal data on behalf of the controller, ensuring GDPR compliance.

Is a DPA legally required by the GDPR?

Yes. Article 28 of the GDPR explicitly mandates that whenever a data controller engages a data processor to process personal data on its behalf, the relationship must be governed by a binding written contract or legal act (the DPA).

Who needs to sign a DPA?

Any organization acting as a data controller must sign a DPA with every third-party service provider (the processor) that touches the personal data of its users. This includes cloud providers like AWS, analytics tools, and email marketing platforms.

What must be included in a Data Processing Agreement?

A valid DPA must include the subject matter, duration, nature, and purpose of the processing. It must also detail the type of personal data, the categories of data subjects, and the specific obligations and rights of the data controller.

Can a processor hire another processor?

Yes, but only with the prior written authorization of the data controller. The initial processor must sign a separate DPA with this sub-processor, ensuring the sub-processor is held to the exact same data protection obligations as the primary processor.

What happens if we don't have a DPA in place?

Failing to have a valid DPA in place when sharing personal data with a third party is a direct violation of GDPR Article 28. This can result in significant regulatory fines, reputational damage, and loss of user trust.

What Is a Data Processing Agreement

Introduction

Imagine you run a successful online retail business. You collect names, addresses, and credit card details from thousands of customers. To handle this massive volume of emails, you hire a third-party marketing platform like Mailchimp or SendGrid. To host your website, you use Amazon Web Services (AWS). To track your website traffic, you embed Google Analytics. In the eyes of the law, you have just handed over sensitive personal information belonging to your customers to several outside corporations. Who is legally responsible if AWS suffers a data breach? What prevents your email marketing provider from secretly selling your customer list to a data broker? The mechanism that answers these questions and binds these third parties to strict privacy standards is a specialized contract known as a Data Processing Agreement (DPA).

In the modern digital economy, almost no company operates in a vacuum. Businesses rely on a vast supply chain of Software-as-a-Service (SaaS) providers, cloud infrastructure, and third-party APIs. Every time personal data crosses the boundary from your company to one of these service providers, legal risk is generated. A Data Processing Agreement mitigates this risk. It is the contractual backbone of data privacy, transforming abstract regulatory requirements into enforceable legal obligations between businesses. Understanding how DPAs work is not just a job for the legal department; it is a critical requirement for software engineers integrating APIs, procurement teams buying SaaS tools, and founders building compliant businesses.

What Is a Data Processing Agreement?

A Data Processing Agreement (DPA) is a legally binding contract established between a data controller (the organization that determines the purpose and means of processing personal data) and a data processor (the third-party service provider that processes data on the controller’s behalf). The core function of a DPA is to legally bind the processor to handle the personal data exclusively according to the documented instructions of the controller.

The requirement for DPAs is heavily driven by the European Union’s General Data Protection Regulation (GDPR), specifically Article 28. However, similar contractual requirements are now mandated by other major privacy frameworks worldwide, including the California Privacy Rights Act (CPRA). A DPA is not a voluntary best-practice; it is a strict statutory requirement.

A well-drafted DPA provides clarity and protection for both parties. For the data controller, it provides legal assurance that the vendor will not misuse the data, will implement adequate security measures, and will assist in the event of a breach. For the data processor, it clearly defines the boundaries of what they are allowed to do with the data, limiting their liability as long as they adhere strictly to the controller’s instructions. A DPA acts as a specialized extension of a Master Services Agreement (MSA), focusing entirely on the handling and security of personal information.

How a Data Processing Agreement Works

The mechanics of a DPA are straightforward but highly detailed. The agreement must explicitly define the scope of the relationship and impose specific operational requirements on the data processor. Here are the core mechanisms of how a DPA functions in practice:

Defining the Scope of Processing: The DPA must clearly state the subject matter of the processing (e.g., email marketing), the duration (e.g., the length of the software subscription), the nature and purpose of the processing, the types of personal data involved (e.g., names, email addresses), and the categories of data subjects (e.g., the controller’s customers).
Mandating Documented Instructions: The core mechanism of the DPA is the stipulation that the processor may only process the data on the documented instructions of the controller. If the processor uses the data for its own purposes, it violates the agreement and immediately assumes the legal liabilities of a controller.
Enforcing Confidentiality: The DPA requires the processor to ensure that all personnel (employees, contractors) authorized to process the personal data have committed themselves to strict confidentiality agreements.
Requiring Security Measures: The DPA obligates the processor to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. This often includes requirements for encryption at rest vs in transit, regular security testing, and access controls.
Managing Sub-processors: If the processor wants to hire another company (a sub-processor) to help with the service, the DPA dictates that they must first obtain written authorization from the controller. The processor must also sign a contract with the sub-processor that mirrors the data protection obligations of the primary DPA.
Assisting with Data Subject Rights: The processor must assist the controller in responding to requests from individuals exercising their privacy rights, such as requests for data deletion or data access.
Handling Data Breaches: If the processor experiences a security incident, the DPA requires them to notify the controller without undue delay, providing all necessary information for the controller to meet its own regulatory reporting deadlines.
Audits and Deletion: The DPA must give the controller the right to conduct audits or inspections of the processor’s facilities. Finally, it must require the processor to securely delete or return all personal data at the end of the contract.

Watch this overview of why Data Processing Agreements are crucial for GDPR compliance.

DPA vs Standard Contractual Clauses (SCCs)

While DPAs and Standard Contractual Clauses (SCCs) are both contracts used in data privacy, they serve different primary functions and are often used together.

Feature	Data Processing Agreement (DPA)	Standard Contractual Clauses (SCCs)
Primary Purpose	Governs the relationship between a controller and a processor.	Provides a legal mechanism for transferring data outside the EU/EEA.
Legal Basis	GDPR Article 28	GDPR Article 46
Authorship	Drafted and negotiated by the parties involved (or standard vendor templates).	Pre-approved, standardized templates published by the European Commission.
Modifiability	Can be heavily negotiated and customized, provided Article 28 minimums are met.	Cannot be modified; they must be signed exactly as drafted by the EC.
Scope of Use	Required for all controller-processor relationships, regardless of location.	Required only when data crosses international borders to countries lacking an adequacy decision.

Comparing a DPA with Standard Contractual Clauses (SCCs).

As the table illustrates, a DPA is the fundamental contract required anytime you hire a vendor to process data, even if both of you are located in the same city. SCCs are a specialized tool used specifically for international data transfers. In practice, if an EU-based company hires a US-based SaaS provider, the two parties will sign a single comprehensive document that serves as the DPA (satisfying Article 28) and incorporates the SCCs as an addendum (satisfying Article 46 for the trans-Atlantic transfer).

Real-World Use Cases

The necessity of DPAs spans across almost every modern business function. Here are typical scenarios where a DPA is a strict legal requirement.

Cloud Infrastructure Providers: When a startup builds its application backend on Google Cloud Platform (GCP) or Microsoft Azure, they are using these providers to store and process their users’ data. The startup is the controller, and GCP/Azure is the processor. Before any production data is moved to the cloud, the startup must execute the provider’s standard Data Processing Agreement. This DPA ensures that the cloud provider cannot peek at the startup’s databases or mine the data for advertising.

Customer Relationship Management (CRM): A sales team uses Salesforce to track leads, customer communications, and deal pipelines. Because Salesforce hosts this database of names, emails, and phone numbers, they act as a data processor. The company employing the sales team must have a DPA in place with Salesforce. The DPA guarantees that Salesforce will only use the data to provide the CRM service, will secure it adequately, and will delete it if the company terminates its subscription.

Third-Party Analytics and Marketing: A media website embeds Google Analytics to track visitor behavior and uses Mailchimp to send weekly newsletters. Both of these tools process the IP addresses or email addresses of the website’s visitors. The media website must sign DPAs with both Google and Mailchimp. If the media website fails to do this, they are illegally sharing personal data with third parties, exposing themselves to significant regulatory fines.

Common Mistakes to Avoid

A frequent error is treating the DPA as a mere formality or a “clickwrap” annoyance. Procurement teams sometimes sign vendor DPAs without reading them, failing to realize that the vendor has inserted clauses allowing them to use aggregated customer data for their own machine learning models. Controllers must review DPAs to ensure the vendor is strictly limited to processing data for the contracted service and nothing else.

Another major mistake is ignoring the sub-processor list. Many vendors include language in their DPA stating that by signing, you pre-approve their entire list of sub-processors, and you agree to monitor a specific webpage for updates. If the vendor adds a new sub-processor located in a country with weak privacy laws, and you fail to object within the specified timeframe, you are legally responsible for that risky data transfer. Controllers must actively manage and review their vendors’ sub-processor chains.

Finally, organizations often err by failing to maintain a central repository of DPAs. When a regulatory audit occurs, or a user submits a Data Subject Access Request (DSAR), the privacy team needs immediate access to every DPA signed with every vendor. If these agreements are scattered across individual employees’ email inboxes or local hard drives, the organization cannot demonstrate compliance. A centralized vendor management system is essential for maintaining control over your DPAs.

Getting Started

To ensure your organization is compliant with DPA requirements, begin by mapping your data flows. Create a comprehensive inventory of every third-party vendor, SaaS tool, and API that receives personal data from your systems. This includes cloud hosts, marketing platforms, HR software, and payment gateways.

Once you have your vendor list, audit your contracts. Verify that you have a signed, valid Data Processing Agreement in place for every vendor on that list. If you find gaps, contact the vendor immediately and request to sign their standard DPA. For high-risk vendors or custom enterprise contracts, you may need to draft and negotiate a custom DPA using a template prepared by your legal counsel.

Finally, integrate DPA checks into your procurement process. Establish a strict rule that no employee is allowed to purchase new software or integrate a new API until the privacy team has reviewed and signed the necessary DPA. By making the DPA a non-negotiable prerequisite for onboarding new vendors, you prevent compliance gaps from forming in the future. To further understand the legal landscape surrounding these agreements, review our guides on Controller vs Processor GDPR Roles and What Is Purpose Limitation in Data Privacy.