If a small medical practice has signed a Business Associate Agreement with its IT provider, the practice owner often believes the box is checked. The MSP handles the technology, the MSP signed a BAA, the practice is covered.
That belief is the most expensive misunderstanding in small practice HIPAA compliance. It survives because nothing about it is obviously wrong. The IT provider really did sign a real BAA. The BAA really is required. But the BAA does not do what most practice owners think it does.
This post explains, in plain language and with the specific regulatory citations, what an IT provider's BAA actually covers, what it does not cover, and what stays with the practice regardless of how comprehensive the BAA is.
A Business Associate Agreement is a written contract required by 45 CFR 164.502(e) before a covered entity may share protected health information with a vendor. The contract specifications are listed in 45 CFR 164.504(e), and the definition of who qualifies as a Business Associate is in 45 CFR 160.103.
Under the regulation, a Business Associate is any person or organization that "creates, receives, maintains, or transmits protected health information" on behalf of a covered entity. An IT provider that hosts the practice's EHR, manages email containing patient communication, runs backups that include PHI, or supports any system where PHI lives is a Business Associate. They are required to sign a BAA. Cloud providers like Microsoft 365, Google Workspace, and AWS all sign BAAs for healthcare customers. So do most managed service providers.
The BAA itself is real. It is enforceable. It binds the IT provider to specific obligations.
The contract requirements in 45 CFR 164.504(e)(2) define exactly what the IT provider commits to in the BAA. The list is specific:
Read that list carefully. Every obligation listed is something the IT provider does with PHI it touches. The BAA defines the IT provider's responsibilities for the data it processes. That is what the BAA is for.
This is where the misunderstanding lives.
The BAA does not transfer the practice's regulatory liability for HIPAA compliance to the IT provider. The covered entity remains the regulated party. OCR enforces the rule against the practice, not the practice's vendors.
The BAA does not satisfy the practice's obligation to conduct and document a Risk Analysis under 45 CFR 164.308(a)(1)(ii)(A). The Risk Analysis is the covered entity's obligation. It must reflect the entire practice environment, not only the systems the IT provider touches.
The BAA does not satisfy the practice's obligation to develop and implement a Risk Management Plan under 45 CFR 164.308(a)(1)(ii)(B). The IT provider can implement specific technical safeguards, but the decision about which risks the practice accepts, mitigates, or transfers stays with the practice.
The BAA does not satisfy the practice's obligation to maintain a Notice of Privacy Practices under 45 CFR 164.520. The IT provider is not the public-facing covered entity. The practice is.
The BAA does not satisfy the practice's obligation to train its workforce on HIPAA policies and procedures under 45 CFR 164.530(b). Workforce training is the practice's responsibility.
The BAA does not satisfy the practice's obligation to designate a Privacy Officer and a Security Officer under 45 CFR 164.530(a) and 45 CFR 164.308(a)(2). Those roles must exist within the practice.
The BAA does not satisfy the practice's obligation to retain documentation for six years under 45 CFR 164.316(b)(2)(i). The practice must retain its own records.
In each of these areas, the IT provider may help operationally. They may run the EHR that holds the records. They may configure the email system with encryption. They may flag suspicious activity. None of that converts the practice's regulatory obligations into the IT provider's regulatory obligations.
OCR's Risk Analysis Initiative, launched in October 2024, has produced a steady cadence of enforcement actions against small healthcare entities. Every settlement reviewed cites the same root issue: the practice did not have an adequate written Risk Analysis when OCR asked for one.
These were not large hospitals with sophisticated compliance programs that should have known better. The cases include solo and small-practice covered entities. The pattern is consistent: when an OCR investigation opens, the request letter cites 45 CFR 164.308(a)(1)(ii)(A) and asks for the written Risk Analysis. If the practice produces a vendor-generated security checklist, OCR evaluates it against the HHS Audit Protocol's five substantive criteria and the HHS Final Guidance's nine required elements. Most vendor outputs do not meet those standards because they were not designed to.
The IT provider's BAA, however well drafted, does not appear in this conversation. It is a different document addressing a different obligation.
There are three reasons the "we have an IT provider with a BAA, so we are covered" belief survives in small practices.
First, the BAA is something tangible. It is a signed document the practice can produce. When the practice owner asks "are we HIPAA compliant," and the office manager says "yes, our IT provider signed a BAA," the answer feels solid. There is paper to point at.
Second, IT providers themselves sometimes contribute to the misunderstanding. Marketing language like "HIPAA-compliant managed services" or "we handle your HIPAA compliance" implies a scope of responsibility that the actual BAA does not transfer. The IT provider is HIPAA-aware. They are not the covered entity's compliance program.
Third, the actual obligations a covered entity carries are administrative and documentary, not technical. They feel less concrete than firewalls, encryption, and EHR access controls. Practice owners default to focusing on the visible technical posture and assume the rest is handled. It is not handled by the BAA.
The IT provider's BAA stays. It is required by law and the IT provider should continue to be a Business Associate of the practice. Nothing about this post argues against the BAA itself.
What the practice needs in addition to the BAA is a complete compliance program that the practice itself owns. At minimum:
This is not a list of things the IT provider can do for the practice. The IT provider can support some elements operationally. The practice owns the compliance program.
The IT provider's BAA is necessary. It is not sufficient.
If a practice has been operating on the assumption that the BAA covers HIPAA compliance, the gap is real but the work to close it is defined. A current Risk Analysis built against the HHS Audit Protocol's five evaluation criteria is the foundation. The Risk Management Plan, NPP, training documentation, and designated officers fall into place from there. Most practices can build this in three to six weeks of focused work.
What the practice cannot do is wait until an OCR letter arrives to learn that the BAA was never the answer to that question.
If you want to compare your current compliance posture against what the HHS Audit Protocol actually evaluates, book a 30-minute consultation. There is no charge and no obligation. Most practices use the call to identify which obligations they have covered, which ones their IT provider's BAA does not address, and what to prioritize first.
NPA's HIPAA Risk Analysis is built directly against the HHS Audit Protocol's 5 evaluation criteria and the 9 elements of HHS Final Guidance. Three weeks. Flat fee. CIPP/US certified.
See the service