Quick answer
A Business Associate Agreement and a Data Processing Agreement are two different documents required by two different bodies of law. A BAA is required by HIPAA at 45 CFR 164.502(e) before a covered entity or business associate shares PHI with a vendor. A DPA is required by state privacy laws (CCPA, VCDPA, CPA, TDPSA, and others) before a vendor processes personal data on a regulated business’s behalf. Some vendors need a BAA, some need a DPA, some need both, some need neither. The work is figuring out which is which.
The short answer
| Element | BAA (HIPAA) | DPA (State Privacy Laws) |
|---|---|---|
| Triggering law | HIPAA Privacy Rule and Security Rule | CCPA, VCDPA, CPA, TDPSA, CTDPA, UCPA, and other state laws |
| What it protects | Protected health information (PHI / ePHI) | Personal data of state residents, broadly defined |
| When required | Before sharing PHI with any vendor that creates, receives, maintains, or transmits it | Before a vendor processes personal data on behalf of a regulated business |
| Required contents source | 45 CFR 164.504(e) | The specific state statute, plus CCPA service provider language at Cal. Civ. Code 1798.140(ag) as a common baseline |
| Who enforces | HHS Office for Civil Rights (federal) | State Attorneys General, plus the California Privacy Protection Agency for CCPA |
| Private right of action | Limited, no general private right under HIPAA | Limited under CCPA for certain data breaches; otherwise typically AG-only |
| Penalty for missing | OCR enforcement against the covered entity for impermissible disclosure | Statutory penalties under each state law, plus loss of processor liability shield |
The categories overlap in some vendor relationships and not in others. The next sections walk through each document, then through the four vendor situations that need both and the common cases that need neither.
What a BAA is and when HIPAA requires one
A Business Associate Agreement is the written contract HIPAA requires at 45 CFR 164.502(e) before a covered entity may share protected health information with a vendor that qualifies as a business associate. The definition is in 45 CFR 160.103 and covers any person or organization that creates, receives, maintains, or transmits PHI on behalf of a covered entity. The required contents are listed in 45 CFR 164.504(e).
The required terms include the vendor’s commitment to not use or disclose PHI other than as permitted, to use appropriate safeguards, to report breaches, to flow restrictions down to subcontractors, to make PHI available for patient access requests, and to return or destroy PHI when the contract ends. The practical limits of what a BAA covers are detailed in why your IT provider’s BAA does not make your practice HIPAA compliant.
Vendors that need a BAA typically include the EHR or practice management platform, the email provider when patient communication runs through it, cloud storage holding PHI, backup providers, IT managed service providers, billing and transcription services, secure messaging tools, and any analytics or AI platform that ingests PHI. Microsoft 365, Google Workspace, and AWS all sign BAAs for healthcare customers, but coverage is limited to specific in-scope services and paid tiers (free consumer Gmail accounts, for example, are not covered, and not every Microsoft 365 service falls under the BAA).
Vendors that do not need a BAA include software that never touches PHI, marketing platforms used only for non-patient communications, and back-office tools that do not involve patient information. A scheduling tool the practice uses for staff meetings only is not a business associate. The same tool used for patient appointments is.
The BAA covers the vendor’s handling of PHI. It does not transfer the covered entity’s obligations under HIPAA, including the Risk Analysis at 45 CFR 164.308(a)(1)(ii)(A), workforce training, the Notice of Privacy Practices, and the rest of the Privacy and Security Rule.
What a DPA is and when state laws require one
A Data Processing Agreement, sometimes called a Data Processing Addendum, is the written contract state privacy laws require before a vendor processes personal data on a regulated business’s behalf. The vendor is called a service provider (California), a processor (Virginia, Colorado, Connecticut, Texas, Utah, Oregon), or a contractor (California, in some circumstances). The business that controls the data is called a business under CCPA and a controller under most other state statutes. Note: Utah’s processor agreement requirement, unlike the other states above, does not include an explicit deletion-or-return-at-end-of-contract clause; the other obligations apply.
The most prescriptive baseline comes from California. The CCPA defines service provider at Cal. Civ. Code 1798.140(ag) and sets the contract requirements: limits on how the service provider may use the data, prohibitions on selling or sharing personal information, requirements to assist with consumer rights requests, and obligations to flow down restrictions to subcontractors. CPRA added the contractor concept and the third-party category, each with its own contract requirements.
The Virginia Consumer Data Protection Act, the Colorado Privacy Act, the Connecticut Data Privacy Act, the Utah Consumer Privacy Act, and the Texas Data Privacy and Security Act each require similar processor agreements: purpose limitation, confidentiality, deletion or return at end of contract, subprocessor flow-downs, cooperation with audits, and assistance with consumer rights requests. The structures are close enough that a well-drafted DPA can satisfy multiple state requirements at once. Details on the Texas version are in the Texas Data Privacy and Security Act guide and the broader landscape is at the state privacy laws hub.
The trigger for a DPA is whether the business itself falls under a state law and whether the vendor processes personal data on the business’s behalf. Many small businesses underestimate the first half; the 5 signs your small business already falls under state privacy laws covers the most common qualifying patterns.
Vendors that typically need a DPA include payment processors, CRM platforms, email marketing tools, analytics platforms, customer support software, HR and payroll systems, and any SaaS tool that receives customer or employee personal data.
Side-by-side comparison
The two documents look similar from a distance because both are vendor contracts about data. They diverge in every operational detail.
The triggering question for a BAA is whether the vendor will touch PHI. For a DPA, whether the vendor will process personal data on behalf of a regulated business. A vendor can answer yes to one and no to the other.
Required contents diverge with the underlying obligations. A BAA must address the HIPAA items in 45 CFR 164.504(e). A DPA must address the state-specific items in the applicable statute. Combining the two into a single document is possible but uncommon.
Penalties also diverge. Sharing PHI with a vendor that has not signed a BAA is an impermissible disclosure under HIPAA, enforceable by OCR against the covered entity. Sharing personal data without a DPA where state law requires one creates controller-level liability and, under CCPA, can convert the vendor from a service provider into a third party, changing the disclosure and opt-out posture of the relationship.
Enforcement is split: OCR for HIPAA, state Attorneys General for state privacy laws, plus the California Privacy Protection Agency for CCPA. The investigation pathways and penalty structures are not interchangeable.
The four vendor situations that need both
Common patterns where the same vendor needs both a BAA and a DPA in the same file:
First, an EHR or practice management vendor serving a practice with patients from regulated states. The vendor processes PHI under HIPAA (BAA required) and processes personal data of California, Texas, Colorado, or other state residents on the practice’s behalf (DPA required under each applicable state law).
Second, a patient communication or scheduling platform used by a multi-state practice. The platform sends appointment reminders that include patient names and visit information (PHI). It also holds contact information for patients who are residents of states with privacy laws. BAA for the PHI handling, DPA for the broader personal data processing.
Third, a managed service provider that supports both PHI and non-PHI systems. The MSP touches the EHR, email, and file shares that hold PHI. It also touches HR systems, CRM, and other systems holding personal data of employees and non-patient contacts. The BAA covers the PHI side, the DPA covers everything else.
Fourth, a cloud or analytics platform processing both PHI and broader personal data. A cloud provider hosting an EHR and also hosting CRM data for marketing needs the BAA for the PHI workload and the DPA for the marketing workload, even when the contracting party is the same.
In each case, the vendor file should contain both documents. The operational pattern, including inventory and tiering, is covered in the hospitality vendor privacy program case study.
Vendors who need neither
Not every vendor needs a BAA, a DPA, or both. The common false-positive cases:
Software the business uses internally that does not receive personal data of customers, employees, or other regulated individuals. A project management tool used only for internal task tracking, a code repository used only for engineering work, a design tool used for internal design files.
Tools that handle only aggregated or anonymized data with no identifiers. The honest test is whether the data is genuinely anonymized under the applicable statute, not merely de-identified in a marketing sense.
Read-only reference services. A weather API, a market data feed, a public records lookup. These deliver data to the business but do not process personal data on the business’s behalf.
Vendors the business buys from but does not direct. The office supply company. The cleaning service. The accountant performing their own professional services rather than processing data on the business’s behalf.
The risk in this category runs the other direction: assuming a vendor does not need paper when it actually does. The check is always the same. Does the vendor receive PHI? If yes, BAA. Does the vendor process personal data on behalf of a business in a state with a privacy law? If yes, DPA. If both, both.
How to operationalize
Building this into a sustainable program requires the steps to be done in order.
Inventory first. List every vendor the business uses. Not just the ones the business pays for directly. Include the free tools, the trial accounts, the shadow IT the team adopted without telling anyone. The inventory is useless if incomplete.
Categorize next. For each vendor, identify what data the vendor receives: PHI, personal data of state residents, both, or neither. This is where most small businesses discover the gap between what they thought their vendor footprint looked like and what it actually is.
Require the right paper. For PHI vendors, request the BAA. For personal data vendors where the business is in scope of a state privacy law, request the DPA. Many vendors have standard versions of both on request but do not proactively offer them. The customer has to ask.
Store the executed agreements. A vendor register that maps each vendor to the data they touch, the agreements in place, the execution date, and the renewal or review date. This is the document an OCR investigator, a state AG, or a customer doing vendor due diligence will ask for.
Review annually. Vendors change. Subprocessors change. Data flows change. The inventory and the underlying agreements should be reviewed at least annually, with off-cycle reviews triggered by significant business changes.
This sequence is the core of the vendor risk service, and for businesses without any of this foundation today, the work usually fits into a 30-day engagement.
Closing
The BAA and the DPA exist because two different legal regimes require two different contractual structures for two different categories of data. They are not interchangeable.
The mistake to avoid is treating the question as binary. A vendor inventory that asks only “do we have a BAA” or only “do we have a DPA” will miss half the exposure. The right question is “what does this vendor touch, and what does each applicable law require us to have on file.”
If the inventory has never been done, or the file is a folder of BAAs with no DPAs (or vice versa), the Vendor Risk Review is designed exactly for this. For a smaller first step, the Privacy Exposure Review identifies the top three vendor and data risks in 48 hours for a flat fee.
Book a 30-minute consultation to walk the vendor inventory against both frameworks. No charge, no obligation.