What Is a Data Processing Agreement? A Plain-English Guide to DPAs

If your business uses almost any modern software, you’ve probably been asked to sign a data processing agreement, or at least clicked past one. It usually shows up as an extra document attached to a vendor’s terms, filled with references to “controllers,” “processors,” “sub-processors,” and GDPR articles. Most people assume it’s legal housekeeping and move on.

But a data processing agreement is doing real work. It spells out what a vendor is allowed to do with your customers’ personal information, how it has to protect that data, and what happens when something goes wrong. Here’s what a DPA is, when you need one, what it should include, and what to look for before you sign.

Quick reminder: I’m not a lawyer, and this is a plain-English overview, not legal advice. Privacy law varies by jurisdiction and changes often, so talk to a privacy professional about your specific situation.

What Is a Data Processing Agreement?

A data processing agreement, or DPA, is a contract between a business that collects personal data and a vendor that handles that data on the business’s behalf. It sets the rules for how the vendor can use, store, protect, share, and eventually delete that information.

Think about the tools a typical business relies on: a CRM, an email marketing platform, payroll software, cloud storage, a customer support desk, a texting platform. Every one of those vendors touches personal information about your customers or employees. A DPA is the agreement that keeps that vendor on a short leash, so it only uses the data to provide the service you’re paying for.

Controllers and Processors: The Two Roles in a DPA

DPAs are built around two roles that come from European data protection law but now show up in privacy laws worldwide:

• The controller is the business that decides why and how personal data is processed. If you collect customer information to run your business, you’re usually the controller.
• The processor is the vendor that processes the data on the controller’s behalf and according to its instructions. Your email platform, cloud host, or payroll provider is usually a processor.

A simple example: when you upload your customer list to an email marketing tool to send a newsletter, you’re the controller and the email tool is the processor. The same logic applies to business texting. When you send customer phone numbers to a messaging platform to deliver reminders or updates, that platform is processing personal data for you. If you’re new to how business texting works, my guide to what 10DLC is covers the basics.

The line between these roles isn’t always obvious, and it matters a lot. I’ll cover it in more depth in an upcoming post on data controllers vs processors.

When Is a Data Processing Agreement Required?

A DPA isn’t just good practice in many situations. It’s a legal requirement.

Under GDPR

The European Union’s General Data Protection Regulation requires a written contract whenever a controller uses a processor to handle personal data. Article 28 of the GDPR lays out what that contract must cover. This applies to businesses established in the EU, and it can also apply to businesses outside the EU that offer goods or services to people in the EU or monitor their behavior. A US company with European customers can easily fall within its reach.

Under US State Privacy Laws

The US doesn’t have a single national privacy law like GDPR, but a growing number of states do, and many of them require contracts with vendors that process personal data. California’s privacy law uses the terms “service provider” and “contractor” rather than “processor,” but the idea is similar: businesses need written contracts that limit how vendors use personal information. The IAPP has a helpful breakdown of California’s contracting requirements, including what those agreements must say. Several other states with comprehensive privacy laws have adopted their own processor contract requirements as well.

In Practice

Even when the law doesn’t strictly require one, many larger customers will insist on a DPA before they’ll buy your product, especially if you sell software or services that touch their data. For B2B companies, having a solid DPA ready is often part of closing deals.

What Should a Data Processing Agreement Include?

DPAs vary, but a GDPR-compliant agreement generally needs to address a specific list of topics, and most DPAs follow a similar structure even outside Europe. Look for:

• Details of the processing: what data is involved, whose data it is (customers, employees, website visitors), what the processing is for, and how long it will last.
• Instructions: the processor may only handle the data according to the controller’s documented instructions.
• Confidentiality: anyone at the processor who handles the data must be bound by confidentiality obligations.
• Security measures: the technical and organizational safeguards the processor will use, often listed in an appendix.
• Sub-processors: rules for when the processor can hand data off to its own vendors, including notice or approval requirements and a duty to pass the same obligations down the chain.
• Assistance with individual rights: helping the controller respond when people ask to access, correct, or delete their data.
• Breach notification: how quickly the processor must tell the controller about a data breach, and what help it will provide.
• Deletion or return of data: what happens to the data when the contract ends.
• Audits and information: the controller’s right to verify that the processor is complying.
• International transfers: if data leaves the EU or another protected region, the legal mechanism that makes the transfer lawful, commonly the European Commission’s standard contractual clauses.

Data Processing Agreement vs Data Processing Addendum

You’ll see both terms used, sometimes interchangeably. The difference is mostly about format:

• A data processing agreement can be a standalone contract.
• A data processing addendum is attached to an existing contract, such as a master service agreement or terms of service, and adds the data protection terms on top.

Most software vendors use the addendum approach. Their main terms cover the commercial relationship, and the DPA addendum covers the data. Either way, the substance is what counts.

Who Writes the DPA?

In practice, the vendor usually provides its own DPA template. Large software companies often publish their DPA online and incorporate it automatically into their terms, sometimes with no signature required. Smaller vendors might send one on request.

That doesn’t mean the template is automatically fair. Vendor DPAs are written to protect the vendor. If you’re a larger customer or handling sensitive data, it’s common to negotiate certain terms, like breach notification timing or sub-processor approvals.

What to Watch For Before You Sign a DPA

A few areas deserve extra attention:

1. Breach notification timing. Vague language like “without undue delay” is common. If you have your own legal deadlines for notifying regulators or customers, make sure the vendor’s timeline gives you room to meet them.
2. Sub-processor changes. Can the vendor add new sub-processors without telling you? Do you get a chance to object?
3. Use of data for the vendor’s own purposes. Some agreements allow vendors to use data to improve their products or train models. Make sure you understand and are comfortable with any use beyond delivering the service.
4. Data location and transfers. Know where your data will be stored and what transfer mechanisms apply.
5. Deletion at the end. Confirm how and when data will be returned or deleted if you cancel.
6. Liability and indemnification. DPAs often point back to the main contract’s liability caps, and a data breach can be expensive. It’s worth understanding who covers what if the vendor causes a breach. My post on the indemnification clause explains how these risk-shifting promises work.

Why DPAs Matter More Than They Look

When a vendor mishandles personal data, the business that collected it often ends up facing the consequences with regulators and customers, even if the vendor caused the problem. A DPA won’t prevent every breach, but it sets clear expectations, gives you rights to enforce, and helps show that you took reasonable steps to protect the people whose data you hold.

It also forces a useful exercise: understanding exactly which vendors have your customers’ data and what they’re doing with it. Plenty of businesses discover they have far more processors than they realized once they start asking.

The Bottom Line

A data processing agreement is the contract that governs how vendors handle personal data on your behalf. It’s required under GDPR whenever you use a processor, increasingly required under US state privacy laws, and routinely expected by business customers. A good DPA defines what data is involved, limits how it’s used, requires security and breach notification, controls sub-processors, and covers what happens to the data when the relationship ends.

The next time a vendor asks you to accept its DPA, take ten minutes to actually read it. It’s one of the few documents that tells you, in writing, what happens to your customers’ information once it leaves your hands.