A data processing agreement (DPA) is a legally binding contract between a data controller and a data processor that details how personal data will be handled, protected, and used. This agreement is required under the General Data Protection Regulation (GDPR) and similar privacy laws whenever a company shares personal data with a third-party provider.

In some contexts, DPAs are also called data processing addendums, especially under US privacy law like CCPA. In these cases, they often appear as an addendum to a Master Service Agreement rather than as a standalone contract.

In this article, we’ll cover what a DPA is, when you need one, what it must contain, who the parties are, and how to create one.

Legal disclaimer: PandaDoc is not a law firm. This article is for informational purposes only and is not a substitute for professional legal advice. Data protection laws vary by jurisdiction — consult a qualified privacy attorney for guidance specific to your business.

Why data processing agreements matter

GDPR Article 28 requires a written DPA between any data controller and data processor that handles the personal data of EU residents. This is a legal requirement and not optional. Plus, under GDPR article 83, any organization that fails to comply will face fines of up to EUR 20 million or 4% of its annual worldwide turnover, whichever is higher.

US companies are not exempt from these laws. The California Consumer Privacy Act (CCPA), as amended by the CPRA, mandates written contracts with service providers, contractors, and third parties that handle California residents’ personal data. A DPA or equivalent written contract would meet this requirement.

Even beyond legal obligations, a DPA will protect you if your processor mishandles data. If you don’t have one, liability for a vendor’s failures can fall back on you.

According to the IBM Cost of Data Breach Report, the average cost of a data breach reached $4.44 million in 2024. Companies without proper data processing controls face significantly higher costs and exposure.

Data controller vs. data processor: understanding the key roles

Let’s break down the differences between these two roles.

Data controller: The organization that determines why and how personal data is processed. If you collect customer data and decide what to do with it, you are the controller.

Data processor: The third party that processes data on the controller’s behalf, following the controller’s instructions. Your CRM, email marketing platform, cloud storage provider, or analytics tool is typically the processor.

Here are some common examples:

Sub-processors are another component. A processor may engage its own sub-processors. For example, a SaaS company can use AWS to host its infrastructure. Your DPA has to address whether sub-processors can be engaged, and the controller must be notified of any changes.

In some situations, two organizations may both be controllers of the same data. That would be a joint controller arrangement, which requires a different type of agreement (Joint Controller Agreement), not a DPA.

When does your business need a data processing agreement?

Whenever you share personal data with a third party that processes it on your behalf, you need a DPA. This is not just for EU data. The trigger is not where your business is located; it’s where your users and customers are located.

GDPR triggers: Any time you process personal data of EU residents using a third-party service, a DPA is legally required.

CCPA/CPRA triggers: Any time you share California residents’ personal data with a service provider, contractor, or third party, a written contract (like a DPA or similar) is required.

Here are some common situations that would require a DPA:

• Signing up for a CRM (Salesforce, HubSpot, Pipedrive)
• Using email marketing software (Mailchimp, Klaviyo, ActiveCampaign)
• Storing files in cloud storage (Dropbox, Google Drive, AWS S3)
• Running website analytics (Google Analytics 4, Mixpanel, Hotjar)
• Using a customer support platform (Zendesk, Intercom, Freshdesk)
• Processing payments (Stripe, Square, PayPal)
• Using HR or payroll software that handles employee data (Rippling, Gusto, BambooHR)

It’s likely that you do not need a DPA if you’re sharing data with a joint controller or if the third party processes data purely for their own purposes. In this case, they would be a controller, not your processor.

Create your own with PandaDoc’s free DPA template, which covers all the required clauses and can be customized in minutes.

Who needs a DPA?

Here are the groups most likely to be managing third-party data processors, along with the specific situations where a DPA is required.

Sales and RevOps teams

Sales and RevOps teams typically own the most densely connected tool stacks in the company. CRM platforms like Salesforce, HubSpot, and Pipedrive process prospect and customer personally identifiable information (PII) on the company’s behalf, which means a DPA is legally required before those tools go live.

CPQ tools and proposal platforms that store contact data also qualify. A typical RevOps stack runs five to ten integrated tools, and each one may require its own DPA or addendum. If your team is managing that volume, you’ll want a way to centrally track vendor DPAs and their renewal dates, rather than hunting through email threads.

HR and people operations teams

Payroll processors like Gusto, Rippling, and BambooHR handle some of the most sensitive data categories under GDPR: compensation, Social Security numbers, health information, and banking details. A failure here carries the highest regulatory and reputational risk of any team on this list.

Background check vendors and benefits providers are also processors, and they’re easy to overlook. In multinational companies, employee data constantly crosses borders, making international transfer clauses in your DPAs especially important. Employee data is distinct from customer data, but it is equally regulated.

Marketing teams

Marketing teams typically have the most third-party integrations in the company and the least legal oversight, a combination that creates real exposure. Email platforms like Mailchimp and Klaviyo, ad platforms collecting pixel and cookie data, and analytics tools like GA4, Hotjar, and Mixpanel all trigger DPA requirements.

One important clarification: consent management platforms (CMPs) do not replace a DPA with the underlying analytics or ad vendors. They handle user consent at the front end, but the data processing relationship with the vendor still requires a separate agreement. If your marketing team is running vendor evaluations, a vendor agreement or data processing addendum should be part of the standard onboarding checklist.

Finance and accounting teams

Payment processors like Stripe, PayPal, and Square, along with accounting platforms like QuickBooks and Xero, handle financial PII that triggers both GDPR and CCPA obligations. Invoice and billing data often contains enough personal information, such as names, addresses, and account numbers, to qualify on its own.

Finance teams should review DPAs annually because sub-processor lists change. A vendor that was compliant last year may have added new sub-processors without proactive notification. If your team manages payment processing agreements, building that review into the renewal cycle is a practical safeguard.

Legal and compliance teams

Legal typically owns the DPA process, but is often the last team looped in. By the time procurement or IT escalates a vendor relationship, the tool may already be live. The smarter approach is a procurement checklist that gates vendor onboarding on DPA execution before access is granted.

It’s also worth noting that CLM tools used by legal teams are themselves processors of contract data, which often includes PII embedded in agreements. Those tools require their own DPAs. If your team uses PandaDoc or another document management platform to store executed contracts, that relationship needs to be covered.

Industries with heightened DPA obligations

Some industries operate under layered regulatory frameworks that add obligations on top of GDPR and CCPA.

• Healthcare and life sciences: HIPAA applies in the US, where the equivalent of a DPA is a Business Associate Agreement (BAA). But if you process EU patient data, GDPR still applies independently. Both may be required at the same time.
• Financial services: Frameworks like PSD2 in the EU add data processing obligations on top of GDPR, and financial institutions often need DPAs that address these additional requirements explicitly.
• EdTech: Processing children’s data triggers stricter rules under GDPR Article 9 and US COPPA. Standard DPA templates may not cover the additional consent and retention restrictions that apply here.
• SaaS companies: SaaS businesses often act as both controller (for their own user data) and processor (for their customers’ end-user data). DPA obligations run in both directions, and getting the roles right in each contract matters.

What must a data processing agreement include?

GDPR Article 28(3) specifies eight mandatory elements that every DPA must contain.

Beyond these eight mandatory elements, the following clauses are not required by Article 28 but are standard practice in well-drafted DPAs:

• Data subject rights assistance: how the processor will assist the controller in responding to access, deletion, and correction requests.
• Breach notification: the time frame within which the processor must notify the controller of a security incident, typically 24 to 72 hours.
• Data return and deletion: What happens to the data when the contract ends?
• International data transfers: if data will leave the EU, the DPA must address the transfer mechanism, such as Standard Contractual Clauses (SCCs).

You can use PandaDoc’s free DPA template to meet these requirements without starting from scratch.

DPA vs. data sharing agreement: what is the difference?

These two documents are often confused, so let’s break down the distinction:

A data processing agreement (DPA) is between a controller and a processor. The processor handles data solely on the controller’s instructions and for the controller’s purposes.

A data sharing agreement is between two data controllers. Both parties independently determine how they use the shared data. This agreement is used when two organizations exchange data, not when one processes data on behalf of the other.

Additionally, a data processing addendum is functionally equivalent to a DPA. The term is more common in the US, particularly under the CCPA, and typically appears as an addendum to a broader services agreement (such as a Master Service Agreement) rather than as a standalone document.

A good rule of thumb is that if you’re outsourcing data processing to a vendor who handles data only as you instruct, you need a DPA. If you’re sharing data with another organization that will use it for its own purposes, you need a data sharing agreement.

How to create a data processing agreement

Now that you know what a DPA is, let’s talk about how to create one:

1. Start with a template. A pre-built, legally reviewed DPA template will reduce the risk of missing required clauses. PandaDoc’s DPA template is free and covers GDPR Article 28 requirements.
2. Identify the parties clearly. State which organization is the controller and which is the processor, using full legal names.
3. Complete the processing schedule. Specify the data types, categories of data subjects, purpose of processing, and duration. This is the most commonly incomplete section.
4. Address security measures. Describe the technical and organizational measures the processor will implement. Be specific here.
5. Cover sub-processors. List known sub-processors or include a mechanism for notifying the controller of new ones.
6. Handle international transfers. If data will leave the EU or UK, you need to include Standard Contractual Clauses (SCCs) or reference the applicable transfer mechanism.
7. Have legal counsel review it before signing. This is especially important for high-value relationships or contracts that involve sensitive personal data categories such as health, financial, or children’s data.

Once you’re through those seven steps, both parties need to sign the agreement for it to be legally binding. PandaDoc handles eSignature natively and stores the executed agreement with a full audit trail, which matters when you need to demonstrate GDPR compliance to a regulator.

How PandaDoc helps you manage data processing agreements

PandaDoc is GDPR- and CCPA-compliant and provides its own legally reviewed DPA to customers here.

Plus, our free DPA template covers the required GDPR Article 28 clauses and can be customized, sent, and eSigned in minutes. Once it’s signed, the agreement is stored alongside your other agreements. You’ll see status, expiry dates, and version history all in one place.

And if your team manages multiple vendor DPAs, you can use PandaDoc’s contract management features to track renewal dates and maintain a full audit trail. PandaDoc also supports eSignature by both parties, generating a legally binding audit trail that is important for demonstrating GDPR compliance to regulators. Use our free DPA template, or try PandaDoc today.

Disclaimer

PandaDoc is not a law firm, or a substitute for an attorney or law firm. This page is not intended to and does not provide legal advice. Should you have legal questions on the validity of e-signatures or digital signatures and the enforceability thereof, please consult with an attorney or law firm. Use of PandaDoc services are governed by our Terms of Use and Privacy Policy.