A Business Associate Agreement (BAA) is the contract that makes a vendor legally accountable for the Protected Health Information (PHI) it handles on your behalf. Under 45 CFR §164.502(e), a covered entity (or a business associate using a subcontractor) must have a BAA in place before any PHI flows to that vendor. Without one, simply using the vendor for PHI is itself a HIPAA violation, regardless of how secure the vendor actually is.
The BAA does real work beyond paperwork. It binds the vendor to the Security Rule safeguards, obligates it to report security incidents and breaches back to you, restricts how it may use the data, and — importantly — requires it to flow those same obligations down to any of its own subcontractors. That is how the chain of accountability reaches from a hospital all the way down to a sub-processor it has never met.
For a product team the operationally important fact is that BAA coverage is binary, and it is per vendor and often per service tier. A cloud platform might be HIPAA-eligible on one plan and explicitly not permitted for PHI on a cheaper tier; a feature within an otherwise-covered product might be carved out. So you must verify the exact configuration you actually deploy, not the vendor's general "we support HIPAA" marketing. The classic pitfall is signing a BAA and then enabling a feature or region outside its scope, or piping PHI into an analytics or AI add-on that the BAA never covered — re-opening the very liability the agreement was meant to close.
