The short version
If your SaaS sells to US healthcare providers, you need a HIPAA Business Associate Agreement (BAA). If you sell to European businesses or process data of EU residents, you need a GDPR Data Processing Agreement (DPA). If you do both — you need both. They serve different legal frameworks, cover different data types, and have different enforcement consequences. Confusing them (or ignoring them) is one of the more expensive compliance mistakes a SaaS founder can make.
What is a HIPAA BAA?
A Business Associate Agreement is a contract required by the Health Insurance Portability and Accountability Act (HIPAA), specifically under 45 CFR § 164.504(e). It must be signed between a Covered Entity (a healthcare provider, health plan, or healthcare clearinghouse) and a Business Associate (any company that creates, receives, maintains, or transmits Protected Health Information — PHI — on behalf of that Covered Entity).
If your SaaS is used by a clinic, hospital, health insurance company, or any HIPAA-covered entity, and your system touches patient data in any way, you are a Business Associate. You need a signed BAA before you can go live. No BAA = HIPAA violation on day one.
What counts as PHI? The 18 HIPAA Safe Harbor identifiers, when combined with health information, constitute PHI. This includes: names, addresses, dates (birth, admission, discharge), phone numbers, email addresses, Social Security Numbers, medical record numbers, health plan beneficiary numbers, diagnoses, treatment data, IP addresses, and more.
What is a GDPR DPA?
A Data Processing Agreement is required by the General Data Protection Regulation (GDPR), Article 28. It must be signed between a Controller (the entity that determines why and how personal data is processed — typically your B2B customer) and a Processor (the entity processing data on behalf of the Controller — typically your SaaS company).
If your SaaS processes any personal data of EU/EEA residents on behalf of a business customer, you are a Processor. Article 28(3) requires a written contract containing specific mandatory clauses. No DPA = GDPR violation, enforceable by the customer's supervisory authority.
Side-by-side comparison
| Feature | HIPAA BAA | GDPR DPA |
|---|---|---|
| Legal basis | 45 CFR § 164.504(e), HITECH Act | GDPR Article 28 |
| Jurisdiction | United States | EU/EEA (+ UK GDPR, Swiss nFADP) |
| Data covered | Protected Health Information (PHI) | All personal data of EU residents |
| Who requires it | Covered Entity → Business Associate | Controller → Processor |
| Trigger | Any PHI access/storage/transmission | Any personal data processing on behalf of controller |
| Breach notification | To CE within 60 days (45 CFR § 164.410) | To Controller without undue delay; CE notifies DPA within 72h |
| Sub-contractor chain | Sub-contractors must sign sub-BAAs | Sub-processors must sign sub-DPAs |
| Maximum penalty | $1.9M/year per violation category (civil); criminal charges possible | €20M or 4% of global annual turnover, whichever higher |
| Enforcement body | HHS Office for Civil Rights (OCR) | National supervisory authorities (e.g., ICO, DPA, CNIL) |
| Security standard | HIPAA Security Rule — Administrative, Physical, Technical safeguards | GDPR Art. 32 — state-of-the-art TOMs; encryption, pseudonymization |
Can one document cover both?
Technically possible, but generally not advisable. The legal frameworks have different structures, definitions, and mandatory clauses. A combined BAA/DPA often ends up satisfying neither framework cleanly, and a healthcare customer's legal team will likely push back on a hybrid document. Best practice: maintain separate documents, but cross-reference them in your Master Service Agreement (MSA).
Some large SaaS vendors (AWS, Microsoft Azure, Google Cloud) offer combined HIPAA/GDPR documentation, but they have the legal resources to draft and maintain these carefully. For a startup, separate documents reviewed by specialists in each framework is safer.
When do you need both?
If your SaaS serves healthcare customers in both the US and Europe (increasingly common in global health tech), you'll need both. The trigger points:
- BAA: Selling to a US hospital, clinic, health plan, or any HIPAA-covered entity, and your system accesses, stores, or transmits PHI
- DPA: Processing personal data of EU/EEA residents on behalf of a business customer — even if that data has nothing to do with health
Note that health data in the EU is also "Special Category" data under GDPR Article 9, requiring explicit consent or other specific legal bases for processing. So EU health data triggers both the DPA requirement and heightened GDPR restrictions — entirely separately from HIPAA.
What goes in a HIPAA BAA (mandatory clauses)
Under 45 CFR § 164.504(e)(2), a BAA must include provisions that:
- Limit PHI uses/disclosures to those permitted by the agreement or required by law
- Require appropriate safeguards (administrative, physical, and technical) for ePHI
- Require reporting of security incidents and breaches to the Covered Entity
- Ensure sub-contractors sign sub-BAAs before receiving PHI
- Make PHI available to individuals and the Covered Entity as required
- Support the Covered Entity's accounting of disclosures obligations
- Make books and records available to HHS for compliance audits
- Return or destroy PHI upon termination
What goes in a GDPR DPA (mandatory clauses)
Under GDPR Article 28(3), a DPA must specify that the Processor:
- Processes data only on documented instructions from the Controller
- Ensures confidentiality obligations on all authorized persons (Art. 28(3)(b))
- Implements Art. 32 technical and organisational measures (encryption, pseudonymization, resilience, testing)
- Respects sub-processor conditions — sub-processors need a sub-DPA (Art. 28(4))
- Assists the Controller with data subject rights requests
- Assists the Controller with Art. 32-36 obligations (security, breach notification, DPIA, prior consultation)
- Deletes or returns all data at termination (Art. 28(3)(g))
- Provides audit cooperation and evidence of compliance
Practical checklist: managing BAAs and DPAs in your contract stack
- ✅ Create a template BAA and a template DPA as separate documents
- ✅ Have each reviewed by a specialist: a US healthcare attorney for the BAA, a GDPR-qualified lawyer for the DPA
- ✅ Include BAA/DPA signing as a prerequisite in your sales process for covered customers
- ✅ Keep a signed-agreement register — track which customers have signed which agreements
- ✅ Maintain a sub-contractor/sub-processor list and ensure all have signed the appropriate agreements with you
- ✅ Review and update both agreements annually or when your sub-processor list changes
- ✅ Your cloud provider BAAs (AWS, Azure, GCP) must be signed before you store PHI in their services
Bottom line
BAA and DPA are not interchangeable. They're required by different laws, cover different data, and have different enforcement consequences. If you serve healthcare customers in the US: get a BAA. If you process EU personal data on behalf of businesses: get a DPA. If you do both: get both, and keep them separate.
Use our generators to create starting-point templates: HIPAA BAA generator for US healthcare customers and GDPR DPA generator for EU business customers. Both are free, no account required.