Use a BAA when protected health information is handled for a HIPAA covered entity, and use a DPA when personal data is processed under privacy laws such as the GDPR. If a vendor touches both U.S. health data and broader personal data, you may need both agreements, not one renamed document.
TLDR: A Business Associate Agreement is a HIPAA contract for vendors that create, receive, maintain, or transmit protected health information. A Data Processing Agreement sets rules for processing personal data, often under the GDPR, UK GDPR, or similar privacy laws. For example, a telehealth platform serving 40,000 U.S. patients and 8,000 EU users may need a BAA for patient records and a DPA for EU account, billing, and usage data. Mixing the two can leave gaps in breach notice, subcontractor control, and audit rights.
What a BAA Contract Covers
A BAA contract, or Business Associate Agreement, is required under the U.S. Health Insurance Portability and Accountability Act, better known as HIPAA. It applies when a vendor works with a covered entity, such as a hospital, clinic, health plan, or clearinghouse, and handles protected health information, or PHI.
PHI is not just a diagnosis or lab result. It can include names, email addresses, birth dates, appointment notes, prescription records, insurance numbers, and billing data when tied to healthcare.
A BAA usually requires the vendor to:
- Use PHI only as permitted by the agreement.
- Apply administrative, physical, and technical safeguards.
- Report breaches and security incidents.
- Ensure subcontractors follow the same restrictions.
- Return or destroy PHI when the service ends, where feasible.
- Allow compliance reviews or provide evidence of controls.
The main point is simple. The vendor must protect PHI and cannot treat it like ordinary customer data.
What a DPA Covers
A Data Processing Agreement, or DPA, is broader. It governs how a processor handles personal data for a controller. Under the GDPR, a controller decides why and how personal data is processed. A processor acts on the controller’s instructions.
Personal data can include names, addresses, device IDs, IP addresses, employment records, payment details, location data, and health data. Health data may receive special protection, but a DPA is not limited to healthcare.
A DPA usually addresses:
- The subject matter and duration of processing.
- The type of personal data involved.
- The categories of data subjects.
- The processor’s duties and limits.
- Security measures.
- Subprocessor approval and notice.
- International data transfers.
- Assistance with data subject requests.
- Data deletion or return at contract end.
The DPA is built around privacy rights and lawful processing. A BAA is built around HIPAA compliance and PHI protection. They overlap, but they are not twins.
BAA vs DPA: The Practical Difference
The fastest way to compare them is to ask two questions. What law applies? And what type of data is being handled?
| Issue | BAA Contract | DPA |
|---|---|---|
| Main legal source | HIPAA and HITECH | GDPR, UK GDPR, CCPA contracts, and similar laws |
| Data focus | Protected health information | Personal data |
| Common parties | Covered entity and business associate | Controller and processor |
| Core concern | HIPAA safeguards and PHI use limits | Lawful processing, rights requests, transfers, and deletion |
| Breach timing | Often tied to HIPAA breach rules and contract terms | Often requires prompt notice, sometimes within tight GDPR timelines |
The catch is that many vendors try to solve this with one generic privacy addendum. That can waste review time and still miss key terms. A legal team may spend three extra review cycles just to confirm whether PHI is included, whether EU data is transferred, and whether subprocessors are listed.
When You Need a BAA
You likely need a BAA if a vendor handles PHI for a HIPAA covered entity or another business associate. Common examples include cloud hosting providers, billing vendors, analytics tools, transcription services, claims processors, backup providers, and patient messaging platforms.
A BAA is not optional just because the vendor never reads the data. Storage, transmission, and maintenance can be enough. A cloud provider hosting encrypted patient records may still be a business associate if it can receive or maintain PHI for a covered entity.
You may not need a BAA when the vendor acts only as a conduit, such as certain internet service providers, or when the data is fully de identified under HIPAA. Still, these calls require care. Labels do not control the analysis. The actual service does.
When You Need a DPA
You need a DPA when one party processes personal data for another party under laws that require processor terms. This is common in SaaS, HR systems, marketing platforms, payment tools, support desks, and cloud services.
For GDPR purposes, the DPA must include specific Article 28 terms. These include documented instructions, confidentiality, security, subprocessor controls, assistance with data subject rights, deletion, audits, and proof of compliance.
Honestly, it feels like some tools make this harder than it should be. A vendor may publish a DPA online but hide its subprocessor list behind three links and a login screen. That slows down risk review and makes renewal season more painful than necessary.
Can One Agreement Cover Both?
Yes, but only if it is drafted carefully. Some organizations use a master services agreement with attached schedules. One schedule may be a BAA. Another may be a DPA. This structure is clean because each legal regime gets its own required terms.
Combining both into one document can work for smaller vendor relationships. Yet it must avoid conflict. For example, a BAA may permit certain HIPAA uses and disclosures, while a DPA may require processing only on documented instructions. The contract should explain how those duties interact.
Pay close attention to these points:
- Definitions: PHI, personal data, controller, processor, covered entity, and business associate must be clear.
- Order of control: State which terms apply if HIPAA and GDPR duties clash.
- Breach notice: Set a strict notice period that satisfies both legal and business needs.
- Subcontractors: Require flow down terms for both PHI and personal data.
- Data transfers: Address cross border transfers if data leaves the original country.
- Deletion: Match HIPAA retention needs with privacy law deletion duties.
Common Mistakes
The most common mistake is signing a DPA and assuming it covers HIPAA. It usually does not. A DPA may discuss security, confidentiality, and deletion, but HIPAA requires specific business associate obligations.
The reverse mistake also happens. A company signs a BAA and assumes it satisfies GDPR. It likely will not. A BAA does not usually cover controller instructions, data subject access requests, international transfer tools, or GDPR audit language in enough detail.
Another problem is vague data scope. If the contract says “customer data” but never says whether PHI is included, expect confusion during an incident. During a breach, unclear wording can cost days. Those days matter.
Simple Decision Guide
- Is PHI involved for a HIPAA covered entity? Use a BAA.
- Is personal data processed for another party under privacy law? Use a DPA.
- Are both PHI and EU personal data involved? Use both, or one agreement with separate BAA and DPA sections.
- Is the vendor only receiving de identified data? Confirm the de identification method and document it.
- Is data transferred across borders? Add transfer safeguards and related terms.
Final Takeaway
A BAA contract and a DPA both protect sensitive information, but they serve different legal purposes. The BAA is the healthcare specific HIPAA tool. The DPA is the broader privacy law tool for personal data processing.
If your organization handles healthcare data, do not rely on titles alone. Review the data, the parties, the service, and the laws that apply. The safest approach is usually a clear contract package: a service agreement, a BAA where PHI is involved, and a DPA where privacy law requires processor terms.
