MSAs, DPAs, and BAAs show up in the same vendor review all the time, which is why teams often blur them together. They should not. An MSA is the commercial contract. A DPA governs processing of personal data under privacy laws. A BAA is a HIPAA-specific agreement for protected health information.
Sometimes you need one. Often you need two. In healthcare or health-adjacent deals, you may need all three. The mistake is signing whatever document someone asks for without checking what data is actually moving.
Key takeaways
- MSAs are commercial contracts; DPAs and BAAs are law-driven addenda. They do not replace each other.
- If a vendor processes personal data covered by the GDPR, UK GDPR, or similar, a DPA is legally required under GDPR Article 28.
- If a vendor handles protected health information on behalf of a HIPAA-covered entity, a BAA is required under 45 CFR §164.504(e).
- A DPA does not satisfy the BAA requirement, and a BAA does not satisfy GDPR's DPA requirement. They cover different regulators and different data.
- A simple rule helps: the MSA does the business work, while the DPA and BAA handle specific compliance obligations.
What is a Master Service Agreement (MSA)?
An MSA is the baseline commercial contract between two companies. It sets the legal and financial ground rules for the relationship and is usually meant to cover more than one order over time. In a typical B2B SaaS deal, the MSA covers the license grant, payment terms, confidentiality, warranties, indemnity, liability caps, term and termination, and dispute resolution.
The MSA is usually paired with one or more Order Forms. The Order Form contains the variables: product, quantity, price, term, start date. The MSA contains the rules that apply across orders. That is why sales teams like the structure: negotiate the legal terms once, then transact under them repeatedly.
MSAs are not required by a specific law. They are a business convention. Two companies can do business under a one-off services agreement, a purchase order, a click-through, or a single order form. The MSA is simply the cleaner shape when the relationship is expected to continue.
What is a Data Processing Agreement (DPA)?
A DPA is the data-processing agreement that sits under an MSA or another services contract. It governs how one party processes personal data on behalf of the other. Under GDPR Article 28, a controller needs one when it shares personal data with a processor. Many other privacy regimes have similar contract requirements.
A good DPA is not just a privacy-themed exhibit. It should cover the subject matter and duration of processing, purpose, categories of data and data subjects, processor obligations, security, subprocessors, breach notice, help with data subject rights, audit rights, and return or deletion at the end of the engagement. If data moves internationally, transfer terms may also be needed.
The practical test is straightforward: will one party process identifiable personal data on behalf of the other, and is that data covered by a privacy law with processor contract requirements? If yes, plan on a DPA. If the data is truly anonymized, aggregated, or not about individuals, a DPA may not be necessary.
What is a Business Associate Agreement (BAA)?
A BAA is a HIPAA-specific agreement. It is required under 45 CFR §164.504(e) when a covered entity, such as a health plan or healthcare provider, shares protected health information (PHI) with a business associate: a vendor or subcontractor that creates, receives, maintains, or transmits PHI on its behalf.
The mandatory BAA terms are narrow and specific: permitted uses and disclosures, safeguards, breach reporting, subcontractor flow-through, support for individual rights, and return or destruction of PHI at termination. A BAA can be short, but it cannot skip those core requirements.
Two things about BAAs trip teams up. First, a BAA is only required when HIPAA applies. A general B2B SaaS vendor that does not touch PHI should not sign one defensively, because it creates obligations without a matching data flow. Second, a DPA does not satisfy the BAA requirement, and a BAA does not satisfy GDPR's DPA requirement.
MSA vs DPA: what is the actual difference?
The cleanest way to think about it: the MSA says what the business deal is. The DPA says how personal data inside that deal gets handled. They answer different questions.
An MSA is mostly commercial. A DPA is largely statutory. The MSA can be negotiated freely between the parties. A DPA has required elements, so the negotiation is usually around implementation details rather than whether the obligations exist at all.
In practice, most vendors have a standalone DPA that attaches to the MSA by reference. Review them together. The MSA's liability cap often applies to DPA breaches, so you need to know whether data-related claims get a higher cap or carve-out.
DPA vs BAA: why they are not interchangeable
A DPA is privacy-law-driven and broad across jurisdictions. A BAA is HIPAA-specific and tied to protected health information. They both deal with sensitive data, but they are built for different regulators and different legal tests.
If a SaaS vendor handles both PHI and EU personal data, you may need both addenda: a DPA for personal data generally and a BAA for the PHI. You can try to combine everything into one document, but it is usually harder to maintain and easier to get wrong.
Do you need all three? A quick decision tree
- Does the vendor process personal data on your behalf? If yes, check whether a DPA is required.
- Is any of that data PHI under HIPAA, and are you a covered entity or business associate? If yes, you likely need a BAA too.
- Is this a one-off purchase or an ongoing relationship? If ongoing, an MSA usually makes life easier. If truly one-off and low-value, a single services agreement or order may be enough.
- Are there multiple orders or SOWs expected? If yes, an MSA plus Order Forms is cleaner than stacking full contracts.
- Is the data flowing internationally out of the EEA or UK? If yes, the DPA needs to include Standard Contractual Clauses or an equivalent transfer mechanism.
Common mistakes teams make
- Signing a BAA with a vendor that never touches PHI. That creates HIPAA obligations without a reason.
- Assuming a DPA covers HIPAA compliance. It does not. PHI needs a BAA, not a DPA with health language added to it.
- Using an old DPA for AI vendors. Older DPAs often do not address model training, outputs, logging, or inference-time data use.
- Letting the MSA's liability cap silently apply to DPA breaches without checking. Data breach claims often need special cap treatment.
- Signing a DPA attached to a marketplace order (AWS, Azure, Salesforce) without checking which terms control. Marketplace DPAs often prevail over your MSA's DPA on specific points.
Frequently asked questions
Do I need a DPA with every SaaS vendor?
Legally, only if the vendor processes personal data subject to the GDPR, UK GDPR, or a similar law with processor contract requirements. In practice, many B2B buyers ask for one anyway because it is a fast way to test whether the vendor has basic privacy controls.
Can a single contract be both an MSA and a DPA?
It can, but a standalone DPA is usually easier to maintain. Privacy terms change more often than commercial terms, and separate documents make replacement and audit cleaner.
Is a BAA required if no PHI is ever shared?
No. A BAA is only required when protected health information is actually involved. Signing one "just in case" can create HIPAA obligations even when the vendor never receives PHI.
Which takes precedence if the MSA and the DPA conflict?
Most well-drafted agreements include an order-of-precedence clause that puts the DPA on top for anything related to data processing, and the MSA on top for everything else. If the clause is silent, courts typically read the more specific document (the DPA) as controlling on its subject matter.
Do US state privacy laws like the CPRA require a DPA?
The CPRA and similar laws require specific contract terms when a business shares personal information with a service provider, contractor, or third party. Most teams satisfy this by signing a GDPR-style DPA that already covers the required CPRA terms, rather than maintaining a separate US-only addendum.
Does HIPAA require a BAA with a cloud provider?
Yes, if the cloud provider creates, receives, maintains, or transmits PHI on your behalf — even if it never "sees" the decrypted data, per HHS guidance. All major cloud providers (AWS, Microsoft Azure, Google Cloud) offer standard BAAs on request.
Keep reading
These resources are starting points, not legal advice. Review every template and recommendation against your facts, policies, and applicable law before use.