Guide

DPA vs. BAA vs. Data Processing Addendum: Which Contract Do You Actually Need

DPA, BAA, and data processing addendum get used interchangeably, but they cover different legal ground. Here's how to tell which one a given vendor relationship actually requires.

Published August 13, 2026·Last updated August 13, 2026

The terms get used loosely enough in vendor contracts that it’s worth being precise about what each one actually is, because signing the wrong one, or assuming a vendor’s generic terms cover you when they don’t, is a compliance gap that’s easy to miss until it matters.

Data Processing Agreement (DPA)

The GDPR term, specifically the Article 28 contract required between a controller (you) and a processor (a vendor handling personal data on your behalf). If your business has any GDPR exposure, EU/UK visitors or customers, this is the baseline contract you need with any vendor touching that data. Our DPA overview covers what one has to include.

Data Processing Addendum

Functionally the same thing as a DPA in most cases, “addendum” just signals it’s attached to and amends an existing master services agreement or terms of service, rather than standing alone. Most SaaS vendors structure it this way: accept the main terms, then separately accept or request the data processing addendum that adds the Article 28 provisions. If a vendor’s site talks about a “DPA” in one place and a “data processing addendum” in another, they’re very likely referring to the same document.

Business Associate Agreement (BAA)

A different legal instrument entirely, specific to US healthcare data under HIPAA. A BAA governs how a “business associate” (a vendor) may use and disclose protected health information on behalf of a “covered entity” (a healthcare provider, insurer, or clearinghouse). It has its own required provisions under HIPAA’s Privacy and Security Rules, distinct from GDPR’s Article 28 requirements, and covers a different category of data (protected health information, not personal data broadly).

A GDPR DPA does not substitute for a BAA, and a BAA does not substitute for a GDPR DPA. If your business handles both EU personal data and US health data, through separate product lines or customer bases, you may genuinely need both contracts with the same vendor.

Our recommendation

CookieYes

Your consent management platform is a processor of visitor data under GDPR, confirm it has a standard DPA available. CookieYes provides one as part of its standard terms, which covers this specific relationship even if you also need a separate BAA elsewhere in your stack.

Try CookieYes

Which one do you actually need?

  1. Handling EU/UK personal data through a vendor? You need a DPA (or data processing addendum, same thing under a different name).
  2. Handling US protected health information through a vendor? You need a BAA, specifically, not a generic DPA.
  3. Handling both, through the same or different vendors? You may need both contracts, check each vendor relationship independently rather than assuming one document covers everything.
  4. Only California/US state consumer data, no EU exposure and no health data? You still want a contract establishing the vendor as a “service provider” under CCPA/CPRA, similar function to a DPA but with CCPA-specific provisions rather than GDPR’s Article 28 language.

The bottom line

These aren’t interchangeable paperwork, they’re built for different regulatory regimes and cover different categories of data. Matching the right contract to the right vendor relationship, rather than assuming any signed-sounding document covers you, is what actually closes the compliance gap.

This guide is educational and not legal advice. For your specific vendor relationships, consult a privacy attorney.