What does a BAA not cover?
Legal sends back a signed agreement and the project moves on. Nothing about the software changed, which is the problem.
The short answer
6 things that decide this
- 01A business associate agreement makes a vendor promise to safeguard protected health information and to limit how it uses and discloses it. That is a contract, not a technical control.
- 02A BAA does not make software HIPAA compliant. Compliance comes from what the system does with access, audit logging, authentication and transmission, which no signature changes.
- 03A BAA does not transfer your liability. Since HITECH, a business associate can be penalised directly, and a covered entity is not indemnified by having the paper.
- 04A BAA does not travel down the chain on its own. Federal regulation requires a business associate to make its own subcontractors agree to the same restrictions, and that includes the model provider behind an AI feature.
- 05A BAA does not remove your own risk analysis. Signing one with a vendor that never touches PHI adds paperwork and no protection.
- 06This page is engineering guidance, not legal advice. Your privacy officer and counsel decide what your agreements have to say.
"We are on AWS and they signed a BAA"
Cloud providers sign these agreements. That covers what the provider owes you for the machines it runs. It says nothing about how you set them up. It says nothing about who on your team can read a record. And it says nothing about an API that hands back the whole patient when the screen shows only a name.
The distinction matters because the two halves fail differently. A provider breach is rare and their problem. A misconfigured bucket is common and yours.
The federal text is specific about the chain. At 45 CFR 164.504(e) the contract must require a business associate to ensure that its subcontractors agree to the same restrictions and conditions. That reaches any subcontractor that creates, receives, maintains or transmits protected health information on its behalf. So your hospital's agreement covers your company. It does not reach your email provider, your logging vendor or your model API.
- HospitalCovered entity.
- YouBAA signed here.
- CloudIts own BAA, its own scope.
- Model APINeeds its own. Often missed.
- LogsThe one nobody maps.
Every hop that touches protected health information needs its own agreement. Teams map the first three and discover the last two during a security review.
The controls the agreement assumes you already have
A BAA points at the Security Rule and says you will follow it. Reading what that rule asks for is more useful than reading the contract, because the rule names things a build either has or does not.
One detail surprises most teams. At 45 CFR 164.312 the technical safeguards mark audit controls as a required standard, while encryption sits under access control and transmission security as addressable. Addressable does not mean optional, and it does not mean skip it. It means you implement it or document a reasoned alternative. Meanwhile the logging most teams treat as a nice-to-have is the part written as required.
Proposed changes would tighten this. A notice of proposed rulemaking published in January 2025 would remove the addressable category for nearly all specifications and make encryption and multi-factor authentication mandatory. It remains a proposal. Building toward it now is cheaper than retrofitting a live system later.
- 01Audit controls that can answer who read one record on one day, not just that logging exists.
- 02Minimum necessary enforced at the API, because hiding a field in the interface leaves the endpoint returning everything.
- 03Unique user identification, so an action traces to a person rather than to a shared service account.
- 04An inventory of every downstream service that sees protected health information, including the ones added last sprint.
What people ask next
01Do we need a BAA with a vendor that never sees patient data?
No, and signing one anyway costs you clarity. A business associate is a party that creates, receives, maintains or transmits protected health information on your behalf. A design agency that never touches the data is not one. Papering everything makes it harder to see which agreements are load-bearing when an auditor asks.
02Does a BAA make our app HIPAA compliant?
No. HIPAA compliance belongs to the system and the programme around it. That means access controls, audit controls, authentication, transmission security, and a risk analysis you actually did. A BAA is the contract that binds a vendor to those duties. Both parties can still be penalised for failing them.
03Who is liable when a subcontractor causes the breach?
Potentially everyone in the chain, which is the point of the flow-down requirement. HITECH extended obligations directly to business associates, so a vendor can be penalised in its own right rather than only through its contract. The covered entity keeps its own duties, including the risk analysis.
04Is HIPAA compliance the same as SOC 2 or HITRUST?
No, and this trips up procurement conversations. HIPAA names no certification at all, which is exactly why buyers fall back on SOC 2 Type II or HITRUST as evidence. Health systems increasingly specify HITRUST; most commercial buyers accept SOC 2 Type II. Neither is required by HIPAA.
Related reading
- How do you build HIPAA-compliant AI? →Where PHI enters an AI pipeline, and what has to be true at each point.
- PHI (protected health information) →Health data plus anything that points at a person.
- Healthcare software development →What we have shipped in clinical workflow, and what we have not.
- TrialTriage: AI clinical trial matching →De-identified data model, field-level encryption, 23 audited action types.
