A HIPAA Business Associate Agreement is required when a vendor creates, receives, maintains, or transmits protected health information for a HIPAA covered entity or another business associate. A Data Processing Agreement, often called a DPA, is used when one party processes personal data for another under privacy laws such as the GDPR, UK GDPR, or similar data protection rules.
TLDR: A BAA is a HIPAA contract for vendors that handle PHI, while a DPA is a privacy contract for processors handling personal data. A healthcare SaaS vendor serving a U.S. clinic may need a BAA; if it also stores data about EU patients, it may also need a DPA. For example, a 60-employee telehealth company processing 12,000 patient profiles could need both contracts if 18% of those patients are based in the EU. The two agreements can overlap, but one does not automatically replace the other.
What a HIPAA BAA Does
A Business Associate Agreement is a contract required by the HIPAA Privacy Rule and Security Rule. It applies when a business associate handles PHI for a covered entity, such as a healthcare provider, health plan, or healthcare clearinghouse.
Common business associates include:
- Cloud hosting providers storing medical records
- Billing companies processing insurance claims
- Telehealth platforms transmitting patient video sessions
- Email or messaging tools used for patient communications
- Analytics vendors reviewing PHI for care operations
- Medical transcription services
A BAA sets rules for how PHI may be used and disclosed. It also requires safeguards, breach reporting, subcontractor controls, and return or destruction of PHI when the relationship ends.
The main point is simple: if PHI is involved and the vendor is not just acting as a narrow conduit, a BAA is usually needed. A generic privacy addendum is not enough. It drives compliance teams a little mad when vendors say their standard DPA “covers HIPAA” but refuse to sign a real BAA.
What a Data Processing Agreement Does
A Data Processing Agreement governs how a processor handles personal data for a controller. The best-known version comes from the GDPR, though similar agreements appear under other privacy laws.
A DPA usually covers:
- The subject matter of processing
- The duration of processing
- The type of personal data involved
- The categories of data subjects
- Processor instructions
- Security measures
- Subprocessor approvals
- International data transfers
- Deletion or return of data
- Support for data subject requests
Personal data is broader than PHI in many cases. It may include names, emails, IP addresses, device IDs, employee data, location data, and customer account records. A DPA is not limited to healthcare.
BAA vs DPA: The Core Difference
A BAA is built for HIPAA-regulated PHI. A DPA is built for personal data processing under privacy law. That difference matters because the duties, terminology, and penalties are not the same.
| Issue | HIPAA BAA | Data Processing Agreement |
|---|---|---|
| Primary law | HIPAA | GDPR, UK GDPR, and similar privacy laws |
| Data covered | Protected health information | Personal data |
| Main parties | Covered entity and business associate | Controller and processor |
| Breach focus | Unauthorized use or disclosure of PHI | Personal data breach and regulator or data subject notices |
| Subcontractors | Must agree to HIPAA-style restrictions | Usually need approval and written processor terms |
| Geographic focus | United States healthcare system | Often tied to EU, UK, or global privacy rules |
When Both Agreements Are Needed
Many healthcare technology deals need both a BAA and a DPA. This often happens when a vendor supports a U.S. healthcare provider and also processes personal data from people in the EU or UK.
Consider a digital intake platform used by a U.S. hospital. The platform collects symptoms, insurance details, appointment requests, IP addresses, and patient contact information. For U.S. patients, much of that data may be PHI. If EU residents use the same platform, the vendor may also process personal data under GDPR rules.
In that case, the hospital and vendor may need:
- A BAA for HIPAA PHI obligations
- A DPA for controller and processor duties
- Standard contractual clauses if EU personal data moves to the United States
- Security exhibits describing encryption, access controls, logs, and incident response
The catch is that legal teams often discover this during procurement, not before. That can add 10 to 20 business days to a deal if the vendor has no prepared HIPAA language or transfer terms.
When a BAA Is Not Needed
A BAA is not required for every tool used by a healthcare organization. If a vendor never accesses PHI and does not create, receive, maintain, or transmit PHI, HIPAA may not require a BAA.
Examples may include:
- A janitorial service with no access to patient systems
- A public website vendor that does not collect patient data
- A courier acting only as a narrow conduit in limited cases
- An employee, since workforce members are handled under HIPAA policies rather than BAAs
Still, the facts matter. A marketing tool that tracks patient appointment pages may raise serious privacy issues. A chat widget that collects symptoms may create PHI. Labels do not control the answer; actual data flow does.
Key Clauses to Compare
Both agreements should be read closely. Short templates often miss operational details. The strongest versions include clear, practical duties.
- Permitted use: A BAA limits PHI use to the contract and HIPAA-approved purposes. A DPA limits processing to documented instructions.
- Security controls: Both should address access controls, encryption, backups, monitoring, and staff training.
- Breach notice: A BAA should support HIPAA breach timelines. A DPA should help the controller meet strict notice periods, such as the GDPR’s 72-hour regulator notice rule.
- Subcontractors: Both should stop silent outsourcing. Subcontractors must accept matching privacy and security duties.
- Deletion and return: Both should explain what happens when services end, including backups and legal retention needs.
- Audit rights: Reasonable audit support helps prove compliance without turning every review into a month-long document chase.
Common Mistakes
One common mistake is treating a DPA as a substitute for a BAA. It is not. A DPA may mention health data, but HIPAA has specific business associate terms that must appear.
Another mistake is signing a BAA with a vendor that is not actually HIPAA-ready. Paper does not encrypt databases. A vendor should be able to explain its access controls, incident response plan, data segregation, and subcontractor list.
A third mistake is ignoring consumer privacy laws. Some health-related data falls outside HIPAA but still creates risk under state privacy laws, consumer protection rules, or GDPR. Wellness apps, fertility trackers, and direct-to-consumer health tools often sit in this gray area.
Best Practice for Healthcare Organizations
A healthcare organization should map data before choosing the contract. The map should show what data is collected, where it is stored, who can access it, which countries are involved, and whether the vendor uses subprocessors.
After that, contract choice becomes much easier:
- Use a BAA when HIPAA PHI is handled by a business associate.
- Use a DPA when personal data is processed for a controller under privacy law.
- Use both when PHI and broader personal data rules apply at the same time.
The safest approach is not to force one agreement to do the work of the other. A combined addendum can work, but only if it contains all required HIPAA BAA terms and all required DPA terms.
FAQ
Can a DPA replace a HIPAA BAA?
No. A DPA does not replace a BAA when HIPAA requires a business associate contract. The BAA must include HIPAA-specific terms for PHI use, safeguards, reporting, subcontractors, and termination.
Can one document include both BAA and DPA terms?
Yes. A single data protection addendum can include both sets of clauses. It must clearly separate HIPAA duties from controller and processor duties so no requirement gets watered down.
Is health data always PHI?
No. Health data becomes PHI when it is created, received, maintained, or transmitted by a covered entity or business associate and relates to an identifiable person’s health, care, or payment. Some health app data may fall outside HIPAA.
Who signs a BAA?
A covered entity and its business associate sign a BAA. A business associate may also need a downstream BAA with a subcontractor that handles PHI.
Who signs a DPA?
A controller and processor usually sign a DPA. In some cases, it may also apply between processors and subprocessors.
What should be checked before signing either agreement?
The organization should check data types, processing purposes, locations, security controls, breach timelines, subcontractors, deletion terms, and audit rights. The contract should match the real service, not just the sales pitch.
