HIPAA Compliance May 6, 2026 8 min read

Why Your IT Provider's BAA Does Not Make Your Practice HIPAA Compliant

By Sam Cherkaoui, CIPP/US Certified Data Privacy Advisor

Quick Answer

The BAA covers the vendor, not you: 45 CFR 164.504(e)(2) binds the IT provider's handling of PHI it touches. It does not transfer the practice's regulatory liability.
Risk Analysis stays with the practice: 45 CFR 164.308(a)(1)(ii)(A) is a covered entity obligation. No vendor BAA, however comprehensive, satisfies it.
Seven obligations the BAA never covers: Risk Analysis, Risk Management Plan, Notice of Privacy Practices (164.520), workforce training (164.530(b)), Privacy and Security Officer designation, six-year documentation retention (164.316(b)(2)(i)), and ongoing vendor management.
OCR enforces against the practice: Every Risk Analysis Initiative settlement since October 2024 cited the covered entity, not the IT provider, for missing or inadequate Risk Analysis documentation.
Close the gap in 3 to 6 weeks: A current written Risk Analysis built against the HHS Audit Protocol's five criteria is the foundation. Risk Management Plan, NPP, training records, and designated officers follow from there.

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.

What a Business Associate Agreement Actually 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.

What the IT Provider’s BAA Covers

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:

The IT provider will not use or further disclose PHI other than as the contract permits or law requires
The IT provider will use appropriate safeguards to prevent unauthorized use or disclosure
The IT provider will report any unauthorized use, disclosure, or breach to the practice
The IT provider will ensure its subcontractors agree to the same restrictions
The IT provider will make PHI available for patient access requests, amendments, and accounting of disclosures, to the extent it holds the data
The IT provider will return or destroy PHI when the contract ends, where feasible

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.

What the IT Provider’s BAA Does Not Cover

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 specifics of what a Risk Analysis OCR actually wants to see are well documented in the HHS Audit Protocol and Final Guidance.

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.

Where This Matters: OCR Enforcement

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. Practices that receive a letter should review the first 72 hours of an OCR investigation before responding.

The IT provider’s BAA, however well drafted, does not appear in this conversation. It is a different document addressing a different obligation.

Why the Misconception Is So Common

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.

What Practices Should Actually Do

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:

A current written Risk Analysis built against the HHS Audit Protocol and the HHS Final Guidance, conducted at least annually, covering the entire practice environment and all systems that touch PHI
A Risk Management Plan derived from the Risk Analysis that documents which risks the practice mitigates, accepts, or transfers, with implementation timelines for the controls the practice owns
A Notice of Privacy Practices that complies with 45 CFR 164.520, given to patients and posted in the practice and on the website
A workforce training program that documents who was trained, on what topics, and when, retained for six years
A designated Privacy Officer and Security Officer, with documented responsibilities
Policies and procedures covering each Security Rule standard, organized so that an OCR request letter can be responded to within the deadline OCR sets, typically 10 to 30 days
Documented vendor management that goes beyond the BAA: the vendor inventory, the BAA repository, evidence that the practice monitors vendor performance, and an exit plan for when a vendor is replaced

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.

Closing

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 with a credentialed HIPAA Risk Analysis as the anchor deliverable.

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.

Frequently Asked Questions

Does my IT provider's BAA make my practice HIPAA compliant?

No. A signed Business Associate Agreement with your IT provider is required under 45 CFR 164.502(e), but it is necessary, not sufficient. The BAA binds the IT provider's handling of PHI it touches. It does not transfer the practice's regulatory liability for HIPAA compliance to the IT provider. OCR enforces the rule against the covered entity, not the practice's vendors. The BAA also does not satisfy your Risk Analysis obligation, your Risk Management Plan, your Notice of Privacy Practices, your workforce training, your Privacy and Security Officer designations, or your six-year documentation retention. Each of those is a separate covered entity obligation that stays with the practice no matter how comprehensive the BAA is.

What does an IT provider's BAA actually cover?

The contract requirements in 45 CFR 164.504(e)(2) define what the IT provider commits to in the BAA. The provider agrees not to use or disclose PHI other than as the contract permits, to use appropriate safeguards to prevent unauthorized use or disclosure, to report any unauthorized use or breach to the practice, to ensure subcontractors agree to the same restrictions, to make PHI available for patient access and accounting of disclosures, and to return or destroy PHI when the contract ends. Every obligation in that list 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.

What HIPAA obligations stay with the practice even after the IT provider signs a BAA?

Seven core obligations stay with the practice. The Risk Analysis under 45 CFR 164.308(a)(1)(ii)(A), the Risk Management Plan under 164.308(a)(1)(ii)(B), the Notice of Privacy Practices under 164.520, workforce training under 164.530(b), Privacy Officer and Security Officer designations under 164.530(a) and 164.308(a)(2), six-year documentation retention under 164.316(b)(2)(i), and ongoing vendor management beyond the BAA. The IT provider may help operationally with some of these. They may run the EHR, configure encryption, or flag suspicious activity. None of that converts the practice's regulatory obligations into the IT provider's regulatory obligations. The practice owns the compliance program.

Why do OCR enforcement actions cite the practice and not the IT provider?

Because the Security Rule is enforced against the covered entity. Every Risk Analysis Initiative settlement since October 2024 cited the covered entity, not the IT provider, for missing or inadequate Risk Analysis documentation. When an OCR investigation opens, the request letter cites 45 CFR 164.308(a)(1)(ii)(A) and asks for the practice's written Risk Analysis. If the practice produces a vendor-generated security checklist instead, OCR evaluates it against the HHS Audit Protocol's five substantive criteria. 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 addresses a different obligation.

What should I do if I have only relied on my IT provider's BAA so far?

Build a complete compliance program that the practice itself owns. Start with a current written Risk Analysis built against the HHS Audit Protocol's five evaluation criteria, covering the entire practice environment and all systems that touch PHI. Then add a Risk Management Plan derived from the analysis, a Notice of Privacy Practices that complies with 45 CFR 164.520, a workforce training program documented for six years, designated Privacy and Security Officers, and policies and procedures organized so an OCR request letter can be answered within the typical 10 to 30 day deadline. Most practices can close this gap in three to six weeks of focused work with a credentialed HIPAA Risk Analysis as the anchor deliverable.

Last updated: May 6, 2026. This article reflects current US HIPAA and state privacy law enforcement practice. NPA is not a law firm; for case-specific legal advice, consult licensed counsel in your jurisdiction.

Need help with HIPAA compliance or US data privacy law?

NPA helps small healthcare practices and small to mid-sized businesses build and maintain audit-ready compliance programs. CIPP/US certified. Houston-based, serving practices nationwide.

Book a Consultation