When do I need a data processing agreement?

You need a DPA whenever one company processes personal data on behalf of another. The most common trigger is a vendor relationship: a SaaS tool, payroll provider, email platform, or analytics service that handles your customers' or employees' personal data. Under GDPR Article 28, a written DPA is mandatory before the processing starts, and CCPA/CPRA require similar contractual terms when you share personal information with a service provider.

What is the difference between a controller and a processor?

The controller decides why and how personal data is processed. The processor acts only on the controller's documented instructions. A company collecting customer signups is the controller; the email platform sending those customers messages is the processor. The same company can be a controller for some data and a processor for other data, so define the roles for each data flow rather than for the company as a whole.

Is a DPA the same as a privacy policy?

No. A privacy policy is a public-facing notice that tells individuals how you handle their data. A DPA is a private contract between two businesses that allocates legal responsibility for processing. You need both: the privacy policy satisfies your transparency duty to individuals, and the DPA satisfies your contractual duty to vendors and partners.

Do I need a separate DPA for every vendor?

You need DPA terms in place with every processor, but they do not have to be separate standalone documents. Many companies attach a DPA as an addendum to a master service agreement or include processing terms directly in the main contract. What matters is that the required clauses exist in writing and are signed before processing begins.

What happens if there is no DPA in place?

Processing personal data without a required DPA is itself a violation under GDPR, separate from any data breach. Regulators have issued fines purely for missing or inadequate processing agreements. Beyond the regulatory risk, without a DPA you have no contractual right to audit the vendor, no agreed breach-notification timeline, and no clear allocation of liability if something goes wrong.

Data Processing Agreement (DPA) Template

A practical guide to writing a DPA. Covers controller vs. processor roles, GDPR Article 28 clauses, sub-processors, security measures, and breach notification.

A data processing agreement (DPA) is the contract that governs what happens to personal data when one company hands it to another. If you use a payroll provider, an email platform, a CRM, or any SaaS tool that touches your customers' or employees' personal data, you almost certainly need one. And under GDPR, having one in writing is not optional.

This guide explains what a DPA is, who the parties are, which clauses are legally required, and the mistakes that turn a DPA into a liability instead of a protection.

What is a Data Processing Agreement?

A 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. It defines the scope of the processing, the security the processor must apply, and what each side owes the other if something goes wrong.

DPAs go by a few names: data processing addendum (the same DPA, attached to a larger contract), data protection agreement, or GDPR addendum. They all do the same job, which is to put the legal relationship around personal data in writing before that data starts moving.

The agreement exists because privacy law treats personal data as something you are responsible for even after you pass it to a vendor. If your email provider leaks your customer list, regulators can still come to you. A DPA is how you set the rules, document the vendor's obligations, and limit your exposure.

Controller vs. Processor: Getting the Roles Right

Every DPA rests on correctly identifying who is the controller and who is the processor. Get this wrong and the rest of the agreement allocates the wrong duties to the wrong party.

The Controller

The controller decides why and how personal data gets processed. The controller chooses the purpose, sets the rules, and carries the primary legal responsibility to the individuals whose data it is.

The Processor

The processor acts only on the controller's documented instructions. It does not get to decide what the data is used for. A processor that starts using the data for its own purposes stops being a processor and becomes a controller in its own right, with all the liability that brings.

A practical example: a fitness studio collects member details and uses a scheduling app to manage bookings. The studio is the controller because it decided to collect the data and why. The scheduling app is the processor because it handles that data only to deliver the booking service the studio asked for.

One company can be both. A marketing agency is a processor when it runs campaigns using a client's customer list, and a controller for its own employee records. Define the roles for each data flow, not for the company as a whole.

Required Clauses Under GDPR Article 28

GDPR Article 28 lists the terms a DPA must contain. These are not suggestions; a DPA missing them can be treated as no DPA at all.

1. Subject Matter, Duration, Nature, and Purpose

Describe what is being processed and why. State the type of personal data (names, emails, payment details, health data), the categories of individuals (customers, employees, patients), and how long the processing lasts. Vague descriptions like "all data as needed" fail this test.

2. Processing Only on Documented Instructions

The processor must process personal data only on the controller's written instructions, including for international transfers. Any processing the processor does on its own initiative breaches the agreement.

3. Confidentiality

Everyone the processor authorizes to handle the data must be bound by confidentiality, whether by contract or statutory duty. This pushes the obligation down to individual employees rather than stopping at the company level.

4. Security Measures

The processor must apply appropriate technical and organizational measures: encryption, access controls, backups, and the like. The clause should reference the risk level of the data rather than promising a fixed checklist that ages badly.

5. Sub-Processors

The processor cannot bring in another processor (a sub-processor) without the controller's authorization, and must flow the same data protection terms down to that sub-processor. The controller needs visibility into who else touches the data.

6. Assisting the Controller

The processor must help the controller respond to data subject requests (access, deletion, correction) and help meet obligations like breach notification and impact assessments.

7. Deletion or Return of Data

At the end of the relationship, the processor must delete or return all personal data, and delete existing copies, unless law requires retention. Spell out which option applies and the timeline.

8. Audits and Inspections

The processor must make available the information needed to prove compliance and allow audits or inspections by the controller. In practice this is often satisfied with a recognized certification report rather than an on-site visit.

CCPA and US State Law: What Changes

GDPR gets the most attention, but US privacy laws now require contractual terms too. Under the CCPA and CPRA in California, a business sharing personal information with a service provider must have a contract that prohibits the service provider from selling the data, retaining it for unrelated purposes, or combining it with data from other sources.

Other states (Virginia, Colorado, Connecticut, and a growing list) follow a similar controller-processor model. The practical takeaway: a DPA written to GDPR's Article 28 standard usually covers US state requirements with a few added clauses, so build to the higher bar and adapt down.

If your vendor handles data on people in multiple regions, address each applicable law rather than assuming one framework covers everything.

International Data Transfers

Where the data physically goes matters as much as who handles it. GDPR restricts moving personal data outside the European Economic Area unless the destination offers adequate protection. If your processor stores data on US servers, or uses a sub-processor that does, the DPA has to account for that transfer.

There are a few accepted mechanisms. An adequacy decision is the simplest: the European Commission has ruled that a handful of countries protect data to an equivalent standard, so transfers to them need no extra paperwork. Where no adequacy decision exists, the most common tool is the Standard Contractual Clauses, a set of pre-approved terms the parties incorporate into the DPA. Some large vendors also rely on the EU-US Data Privacy Framework for transfers to certified US companies.

The practical point is to ask where your data lives before you sign. A DPA that says nothing about transfers, while the processor quietly runs everything through a data center in a third country, leaves you exposed. Name the transfer mechanism in the agreement and confirm it actually applies to your vendor.

How to Write a DPA: Step-by-Step

Step 1: Identify the parties and their roles. Use full legal names and state who is the controller and who is the processor for the data in question. If roles differ across data flows, note that.

Step 2: Describe the processing. Fill in the subject matter, duration, nature, purpose, data types, and categories of individuals. This is usually an annex at the back of the agreement so it is easy to update.

Step 3: Lock in the instructions clause. State that the processor acts only on documented instructions and define how new instructions get issued.

Step 4: Set the security standard. Reference appropriate technical and organizational measures tied to the sensitivity of the data. List specifics in an annex if the parties want them concrete.

Step 5: Handle sub-processors. Decide between specific authorization (the controller approves each one) or general authorization with notice (the processor can add sub-processors but must tell the controller and allow objection).

Step 6: Define breach notification. Set a clear timeline. Many DPAs require the processor to notify the controller "without undue delay," but a fixed window such as 48 or 72 hours removes ambiguity.

Step 7: Cover international transfers. If data will leave its home region, name the transfer mechanism, whether that is an adequacy decision, Standard Contractual Clauses, or a recognized framework, and confirm it fits the vendor.

Step 8: Address data return and deletion. State what happens at termination and the deadline for it.

Step 9: Add audit rights, liability, and signatures. Cover how compliance gets verified, whether through a certification report or an on-site inspection, how liability is allocated between the parties, and get authorized signatories from both sides. A signature from someone without authority to bind the company can undermine the whole agreement.

Common Mistakes That Weaken a DPA

Signing the vendor's version without reading it. Most SaaS vendors offer a standard DPA, and most are written to protect the vendor. Check the breach-notification window, the liability cap, and the sub-processor terms before you accept.

Leaving the breach window vague. "Without undue delay" invites a fight after a breach, exactly when you have no time for one. Put a number on it.

Ignoring sub-processors. Your vendor's vendors can be the weak link. If the DPA lets the processor add sub-processors with no notice and no objection right, you lose control of where your data ends up.

No deletion timeline. "Data will be deleted upon termination" with no deadline lets a former vendor sit on your data indefinitely. Set a date.

Confusing the DPA with a privacy policy. A privacy policy faces individuals; a DPA faces vendors. You need both, and one does not substitute for the other.

Mismatched roles. Labeling a true controller as a processor (or vice versa) misallocates liability and can be challenged by a regulator. Map the data flow before you assign roles.

When You Need a DPA

Onboarding any SaaS tool that stores or handles personal data: CRMs, email platforms, help desks, analytics
Using a payroll or HR provider that processes employee personal data
Hiring a marketing agency that runs campaigns against your customer list
Working with a cloud hosting provider that stores your application's user data
Engaging a call center or support vendor that accesses customer records
Sharing data with any partner that processes personal information on your behalf rather than its own

A DPA usually sits alongside other contracts. It often attaches to a master service agreement as an addendum, pairs with a SaaS agreement when you buy software, and works next to an NDA that protects confidential information more broadly. For partnership data sharing, a B2B non-disclosure agreement covers ground a DPA does not.

Related guides

Generate Your Data Processing Agreement with Contractable

Writing a DPA from scratch means tracking GDPR Article 28, CCPA service-provider terms, and the right security and sub-processor language for your situation. Contractable generates a customized data processing agreement in seconds, with the correct controller and processor roles, breach-notification terms, and deletion clauses for your use case. No legal background required.