HIPAA Compliance for MSPs: Why Signing a BAA Is Only the Beginning

Most managed service providers (MSPs) treat a signed Business Associate Agreement (BAA) as the finish line for compliance with the Health Insurance Portability and Accountability Act (HIPAA).

The reality is it’s closer to the starting line.

A BAA is only one piece of the relationship. If an MSP creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity or another business associate, it can carry direct obligations under HIPAA, obligations that reach well past the BAA itself. They show up in the Master Services Agreement (MSA), the Statements of Work (SOW), security practices, subcontractor relationships, incident response duties, and liability exposure.

That distinction matters more now that the U.S. Department of Health and Human Services (HHS) is considering changes to the HIPAA Security Rule that would make many cybersecurity requirements specific and mandatory rather than flexible. The proposal is not final, but an MSP that waits for a compliance deadline to arrive may find that its contracts, service model, vendor stack, and internal controls cannot be updated on short notice.

For Bronston Legal’s MSP clients, the real question is not whether a BAA exists. It is whether the entire contract stack and operating model tell the same story.

When Does HIPAA Apply to an MSP?

Not every MSP is a HIPAA business associate. That status depends on the services the MSP actually performs, and on whether those services involve creating, receiving, maintaining, or transmitting PHI on behalf of a covered entity or another business associate.

HHS specifically identifies information technology (IT) contractors and managed service providers as potential business associates when maintenance or support work requires access to electronic protected health information (ePHI). Cloud providers that process or store ePHI can fall within the same framework.

This is a functional test, not a labeling exercise. An MSP’s obligations turn on what it actually does with PHI, not on what the agreement calls it. An MSP can be a business associate even if its staff members rarely view patient information and even if its role is largely technical.

Business associates can also be held directly liable for certain violations of the HIPAA Privacy, Security, and Breach Notification Rules. HHS has been clear that business associates bear direct responsibility for safeguarding ePHI and can face penalties for falling short of the Security Rule.

The Bigger Risk Is Often the Contract Stack

For many MSPs, the most significant HIPAA exposure has nothing to do with a technical control. It starts with contract language that is inconsistent or too broad.

The BAA says one thing. The MSA says another. The SOW carves out compliance services entirely, while the marketing page promises a “HIPAA compliant environment.”

Those gaps rarely matter until a security incident forces someone to read all of the documents at once.

The BAA cannot function as a standalone piece of compliance paperwork. It has to work together with the MSA, SOW, security addenda, vendor agreements, and service descriptions so that every document reflects the same scope of responsibility.

That coordination matters because HIPAA compliance is rarely controlled by the MSP alone. The MSP may manage endpoints, identity systems, backups, email security, or monitoring, while the client controls employee behavior, medical devices, applications, physical security, or vendor selection.

When the agreement does not clearly allocate those responsibilities, the MSP can end up answering for controls it never had the authority or ability to manage.

Where MSP Contracts Commonly Create HIPAA Exposure

A few recurring issues deserve close attention.

The MSA, SOW, and BAA Do Not Match

This is one of the most common problems.

The MSA may limit the MSP’s services while the BAA assumes broad responsibility for protecting all PHI. The SOW may exclude certain controls while the sales proposal promises more.

These documents should use compatible definitions, responsibilities, notice requirements, and limitations. When they do not, the ambiguity tends to work against the MSP when something goes wrong.

Client Responsibilities Are Not Clearly Defined

Healthcare security is a shared operational process, not something an MSP delivers alone.

Clients refuse recommended controls, delay upgrades, keep unsupported systems running, or use applications the MSP does not manage. The agreement should set minimum security requirements and a process for documenting exceptions whenever a client declines to meet one.

If a client rejects multifactor authentication (MFA), encryption, endpoint protection, patching, or other safeguards, the contract should say how that decision affects the MSP’s responsibility and risk.

Subcontractor Risk Is Pushed Downstream

Most MSPs rely on a long chain of third parties: cloud platforms, backup providers, ticketing systems, remote monitoring tools, security vendors, and increasingly, artificial intelligence (AI) tools.

If any of those vendors creates, receives, maintains, or transmits ePHI, additional HIPAA obligations can follow.

The MSP should know which vendors will sign a BAA, how quickly each one reports incidents, what its contract permits it to do with data, and whether its liability cap leaves the MSP holding more risk than the vendor that actually caused the problem.

Incident Obligations Are Too Vague

A contract that requires “prompt notice” sounds sufficient until an incident actually happens.

At that point, the parties can disagree about when the notification clock started, who investigates, who communicates with affected individuals, who decides whether an event is a reportable breach, and who pays the forensic and notification costs.

Those questions need answers before an incident, not during one.

Liability Does Not Match the Service

Healthcare clients sometimes ask for unlimited indemnification, broad HIPAA compliance warranties, uncapped breach liability, or responsibility for every act of an MSP subcontractor.

Those terms should be weighed against the actual services delivered, the fees paid, the MSP’s insurance, the level of control the MSP has over the environment, and the risks the client’s own conduct creates.

A BAA should never silently override protections that were carefully negotiated in the MSA.

Is the Proposed HIPAA Security Rule Final?

No.

As of August 2026, the proposed changes have not been finalized, and the current HIPAA Security Rule remains in effect. HHS published the proposed rule in January 2025 and closed the public comment period in March 2025.

The federal government’s 2026 Unified Agenda lists a projected final action in July 2027, but that is a planning estimate, not a guaranteed publication date or compliance deadline.

If a final rule follows the proposal’s timetable, regulated entities would generally have about 240 days from publication to the general compliance date. That sounds like a comfortable runway, but it can disappear quickly once contract amendments, vendor reviews, control changes, documentation, staff training, and client coordination all have to happen at once.

What Would the Proposed Rule Change for MSPs?

The proposal would move HIPAA toward a more prescriptive cybersecurity model.

Many implementation specifications that are currently “addressable” could become expressly required, subject to limited exceptions. That shift would cut flexibility and raise the stakes of documenting who is responsible for each control.

For MSPs, the most significant proposed changes include mandatory asset inventories and network maps, broader use of multifactor authentication and encryption, network segmentation, recurring vulnerability scanning and penetration testing, more specific backup and recovery expectations, annual audits, and stronger verification of business associates.

Those changes reach beyond security operations. They shape how MSPs define scope, price services, document responsibilities, select vendors, and allocate legal risk.

If an MSP promises “vulnerability management,” does that include formal penetration testing? If it provides backup services, does that mean it guarantees restoration within a specific window? If a client refuses MFA, who accepts the resulting risk?

Those are contract questions as much as technical ones.

Why MSPs Should Not Wait for the Final Rule

The proposed controls may not be enforceable yet, but many of the underlying obligations already exist.

The current Security Rule already requires regulated entities to perform risk analyses, manage identified risks, control access to ePHI, review system activity, respond to security incidents, maintain contingency plans, and periodically evaluate the effectiveness of safeguards. Business associates also carry downstream obligations when their subcontractors handle ePHI.

The proposed rule may sharpen those expectations, but it does not invent the concept of HIPAA security from scratch.

For MSPs, waiting to see what happens is itself a form of risk.

A 2026 Enforcement Action Shows Why Technology Vendors Should Pay Attention

In March 2026, HHS announced a settlement involving MMG Fusion, a software company that handled PHI for oral healthcare practices and was treated as a business associate.

HHS’s Office for Civil Rights (OCR) identified potential issues involving an impermissible disclosure, an allegedly inadequate risk analysis, and a failure to notify affected covered entities. MMG agreed to pay $10,000 and enter a corrective action plan subject to three years of monitoring. The resolution agreement did not constitute an admission of liability.

The lesson for MSPs is not the size of the payment. It is that technology vendors can face direct HIPAA scrutiny, and that the burden of an enforcement action often reaches well beyond the settlement amount: regulatory monitoring, remediation, legal expenses, customer disputes, and reputational harm can all follow.

AI Creates a New Layer of HIPAA Risk

AI adds another challenge because PHI can move into tools that were never part of the original technology or contract stack.

An employee can copy patient information into a generative AI tool without knowing where that data is stored, how long it is retained, who can access it, or whether it can be reused to train the model.

Before deploying AI in a healthcare environment, the MSP and client should determine whether the tool will receive PHI, whether the vendor will sign an appropriate BAA, how prompts and outputs are retained, whether the data can be reused, how users are authenticated, how information can be deleted or transferred, and how quickly the provider must report a security event.

An AI feature bolted onto an existing platform should never be assumed to carry the same contractual protections as the platform’s core service.

What MSPs Should Do Now

MSPs do not need to predict the final text of the proposed rule to make useful changes today.

Start by understanding where ePHI exists and how it moves. That means identifying healthcare clients, mapping systems and administrative access, and documenting the cloud platforms, support tools, vendors, and applications that touch regulated data.

Then reconcile the contract stack. Review the MSA, SOW, BAA, security addenda, proposals, privacy terms, and marketing claims together to catch conflicting promises or undefined responsibilities.

From there, compare current controls against the proposed requirements, review downstream vendors, keep defensible documentation, and set minimum security standards for clients. Be ready to amend agreements once a final rule changes the services, documentation, or security responsibilities required across healthcare relationships.

The Bottom Line for MSPs

The proposed HIPAA Security Rule is not just a cybersecurity story.

It is a contract story.

It shapes how MSPs define services, supervise vendors, document safeguards, allocate responsibility, respond to incidents, and manage liability.

Signing a BAA does not resolve those issues. In some cases, it simply exposes them.

An MSP that accepts broad HIPAA responsibilities without clearly defining its scope, dependencies, client obligations, and liability limits may be taking on risk its service model and insurance were never built to absorb.

Bronston Legal, an award-winning, nationally recognized IT and telecom law firm, helps MSPs evaluate how HIPAA requirements affect their Master Services Agreements, Statements of Work, Business Associate Agreements, vendor contracts, service boundaries, and overall risk exposure. The goal is not to pile on compliance language for its own sake. It is to make sure the legal documents match the operational reality of the business.

If your MSP serves healthcare clients, it is worth asking whether your MSA, SOW, BAA, vendor agreements, and actual service delivery all say the same thing. Contact Bronston Legal to review your contracts before an incident or a regulatory change puts them to the test.

HIPAA Compliance for MSPs: Questions and Answers

Is every MSP subject to HIPAA?

No. An MSP becomes a business associate when it creates, receives, maintains, or transmits PHI on behalf of a covered entity or another business associate. The analysis turns on the services actually provided and the MSP’s access to regulated data.

Does signing a BAA make an MSP HIPAA compliant?

No. A BAA is an important contractual requirement in many business associate relationships, but it does not replace the administrative, physical, and technical safeguards the HIPAA Security Rule requires.

Is the proposed HIPAA Security Rule enforceable now?

No. The proposed changes are not yet final, and the current HIPAA Security Rule remains in effect while HHS continues the rulemaking process.

When could the new HIPAA Security Rule take effect?

The 2026 Unified Agenda lists a projected final action in July 2027, though that date is not guaranteed. If the final rule follows the proposal’s timetable, the general compliance date would fall roughly 240 days after publication.

What are the most important proposed HIPAA requirements for MSPs?

Key proposed requirements include multifactor authentication, encryption, asset inventories, network maps, vulnerability scanning, penetration testing, network segmentation, annual compliance audits, stronger backup and recovery procedures, and expanded business associate verification.

Can an MSP be directly penalized for a HIPAA violation?

Yes. Business associates can be held directly liable for certain violations of the HIPAA Privacy, Security, and Breach Notification Rules. HHS can investigate business associates, require corrective action, enter resolution agreements, and impose civil money penalties when warranted.

How does AI affect HIPAA compliance for MSPs?

AI creates risk when PHI is submitted to tools that have not been reviewed, approved, or contractually authorized. Before using AI with PHI, MSPs and clients should evaluate data retention, model training rights, access controls, security protections, incident obligations, and whether the provider will sign an appropriate BAA.

What should an MSP do first?

Start by identifying healthcare clients and mapping where ePHI is created, received, maintained, or transmitted. Then compare the MSP’s actual services and controls against its MSA, SOW, BAA, vendor agreements, and marketing promises. That review usually surfaces the most urgent legal and operational gaps.

Contact Bronston Legal at techlawyers.com/contact-us/

This article is provided for general informational purposes and does not constitute legal advice. The application of HIPAA depends on the facts of each relationship, the services provided, the data involved, and the governing agreements.

© 2026 Bronston Legal. All rights reserved.