DPA vs BAA: The Two Data Contracts Everyone Mixes Up

I once watched a healthtech startup proudly tell a hospital prospect that yes, of course they had a data agreement in place — and produce a GDPR DPA. The hospital's counsel asked for the BAA. Blank stares all around. The startup had genuinely done paperwork; they'd just done the wrong paperwork, and the deal stalled for a month while everyone scrambled.

The acronyms look interchangeable. They aren't. A DPA and a BAA solve different problems under different laws, and which you need depends entirely on what kind of data is moving and where the people behind it live. Get them straight once and you'll never have that hospital conversation.

What a DPA actually is

A DPA — Data Processing Agreement — is a contract about privacy law, primarily GDPR. Under GDPR Article 28, when one company decides how and why personal data gets processed (the controller) and hands that data to another company to process on its behalf (the processor), there has to be a written agreement governing the relationship. The DPA is that agreement.

It exists because GDPR doesn't let a controller wash its hands of responsibility by outsourcing. The DPA pins down obligations in writing: the processor only acts on documented instructions, keeps the data secure, helps with data-subject requests (access, deletion), notifies the controller of breaches, and deletes or returns data at the end. It also lists the sub-processors the processor uses, because your data's risk includes whoever they trust.

One more piece matters: international transfers. If personal data of EU residents leaves the EU — say, to servers in the US — the DPA typically incorporates Standard Contractual Clauses (SCCs), the EU-approved contract language that makes that transfer lawful. If your vendor stores EU data outside the EU and there are no SCCs, that's a gap, not a footnote.

DPAs aren't GDPR-only in practice. Laws like the CCPA/CPRA in California and the UK's own regime have their own required terms, and a well-drafted DPA usually covers them in one document.

What a BAA actually is

A BAA — Business Associate Agreement — is a contract about health data, required by HIPAA in the United States. The vocabulary is different on purpose. A covered entity is a healthcare provider, health plan, or clearinghouse. A business associate is any vendor that creates, receives, maintains, or transmits protected health information (PHI) on the covered entity's behalf — your cloud host, your analytics tool, your support desk, if any of them touch PHI.

HIPAA requires a signed BAA before that PHI ever flows. The agreement obligates the business associate to safeguard PHI under the HIPAA Security Rule, use and disclose it only as permitted, report breaches, and flow the same obligations down to their subcontractors. Crucially, a BAA makes the business associate directly liable under HIPAA — the regulator can come after the vendor, not just the hospital.

If you handle PHI and don't have a signed BAA with everyone downstream, you are out of compliance the moment the data moves. There is no "we're working on it" grace period in an audit.

Side by side

The cleanest way to see the difference is to put them next to each other.

When you need each — and when you need both

This is where people trip. The two aren't mutually exclusive. Which you need depends on the data:

• Personal data of EU/UK/California residents, no health data? You need a DPA.
• PHI in the US, no GDPR-covered individuals? You need a BAA.
• A US healthtech serving European patients? You may well need both — a BAA for HIPAA and a DPA (with SCCs) for the EU residents in that same dataset. Needing one never excuses the other.
• Truly no personal or health data — anonymized, aggregated, nothing identifiable? You may need neither. But be honest about whether your "anonymized" data is actually re-identifiable, because regulators apply a stricter test than marketing does.

The practical move during a vendor review is to ask the data-access question first, then pull the matching agreement. That's exactly the sequence I use in the full vendor risk program — diligence tells you whether to trust a vendor, and these contracts make the trust enforceable.

Who signs, and the clauses worth reading

Both are usually signed by someone with authority to bind the company — counsel, an executive, or whoever owns contracts. Most vendors offer a standard template, and for routine cases signing theirs is fine. But don't sign blind. The clauses I always check:

• In a DPA: the sub-processor list and the notification terms for adding new ones, the transfer mechanism (are SCCs actually attached?), and the deletion/return commitment at termination.
• In a BAA: the breach-notification timeline, the subcontractor flow-down language, and the permitted uses of PHI — watch for vendors quietly reserving the right to use PHI for their own product analytics.

These two documents are also where your other diligence pays off — a vendor with a clean SOC 2 will usually have polished, defensible DPA and BAA templates ready, while one that fumbles the agreements often fumbles the controls too. If you're building out the full picture of how data agreements fit alongside certifications and audits, the frameworks guide maps how the regulatory pieces connect, and the security questionnaires guide covers the assessment side of the same review.

Sort the DPA-versus-BAA question at the start of a vendor relationship, while you still have leverage, and you'll never be the team producing the wrong contract in front of the customer who actually knew the difference.

Get the templates we actually use.

One practical email a week: a new template, a teardown of a real framework requirement, and the occasional honest tool review. No fluff, unsubscribe anytime.

Send me the templates

No spam. Unsubscribe in one click.