Is Your Old BAA Enough? No. HIPAA's Proposed Security Rule Will Make That Very Clear.

By Michele Alexander | MDA Solutions LLC | HIPAA AI Compliance & C-Suite Advisory

Let's talk about something a lot of healthcare organizations do, which they call compliance.

They send a vendor a Business Associate Agreement. The vendor signs it. It goes into a folder, physical or digital, and everyone moves on feeling covered.

Here's the problem: the signed BAA isn't doing what you think it is.

It is not encrypting a file. It is not stopping a phishing attack. It does not verify whether your vendor's system has been patched. It does not tell you whether patient data is moving through secure workflows or whether it's moving at all in the direction you think.

A BAA is a legal document. It is not a safeguard.

And if the proposed changes to the HIPAA Security Rule go final, which could happen as early as this month, May 2026, that BAA will matter a lot more than it already does.

What's Changing

The proposed HIPAA Security Rule update is not a minor tweak. It is a meaningful shift in what healthcare organizations and their business associates will be expected to prove.

The current rule includes "addressable" implementation specifications, requirements that organizations may handle differently based on what is reasonable and appropriate for their situation. That flexibility has been widely misread as optional. It was not, but it gave organizations room to document their reasoning and move on.

The proposed changes remove that distinction. Everything becomes required. And required means documented, tested, and verifiable, not assumed.

Under the proposal, organizations would need to:

• Maintain a complete technology asset inventory

• Map where electronic protected health information moves across systems and vendors

• Implement encryption of ePHI at rest and in transit

• Deploy multifactor authentication

• Conduct continuous monitoring and vulnerability scanning

• Perform penetration testing

• Manage patches and system configurations

• Maintain audit logs

• Run annual testing of technical controls

That is not a small list. And it applies to business associates, not just covered entities.

The Vendor Problem Nobody Wants to Name

Here is something healthcare leaders know but do not always say out loud: most breaches do not start inside the hospital.

They start through a vendor. A subcontractor. A platform. A cloud environment. A workflow nobody mapped, set up three systems ago, and has not been reviewed since.

In March 2026 alone, 44 large healthcare data breaches were reported to OCR, affecting more than 1.5 million individuals. Forty of those 44 were hacking or IT incidents. That is 90.9 percent. And several of the highest-profile cases, including breaches affecting Atrium Health Navicent and Interim HealthCare, originated at third-party vendors.

The covered entity still had to answer for it.

That is the part that tends to get people's attention.

When your vendor fails, your patients are affected. Your organization is named. Your leadership team is answering questions. Your board wants to know what happened. And investigators and auditors are not particularly interested in hearing that you had a signed BAA, because the buck stops with you and your organization.

Under the proposed rule, organizations would need written verification from business associates that cybersecurity safeguards are in place, validated by subject-matter experts, and certified by an authorized person. Vendors would also be required to notify covered entities within 24 hours of activating a contingency plan.

That changes the conversation from "did you sign our BAA?" to "can you prove your safeguards are working?"

This Is Also an AI Problem

If your organization is using AI tools, for documentation, coding assistance, patient intake, quality review, analytics, care coordination, or anything else that touches clinical or operational data, this conversation is about you.

Every AI tool that interacts with patient data raises questions that most organizations have not formally answered yet:

• What data enters the tool?

• Is ePHI involved?

• Where is it stored after the session?

• Is it retained and used for model training?

• Who has access on the vendor side?

• Does the vendor use subcontractors?

• Is there a current BAA in place—one that accurately reflects how the tool operates today?

AI readiness and HIPAA readiness are not separate workstreams. They are the same conversation. If you cannot map the workflow, you cannot govern the risk.

The technology is moving fast. The accountability has not changed.

What Governance Actually Looks Like Here

This is not about panicking. Panic is not a strategy; it is just cortisol with a laptop.

But preparation is a strategy. And the organizations that are preparing now are not waiting for a final rule to tell them what to do. They are doing the foundational work that makes compliance sustainable instead of reactive.

That work looks like this:

Know what you have. Build a current inventory of all systems, platforms, tools, and applications that handle ePHI, including those in place before the current IT team arrived.

Map where data moves. Not just what systems you use, but how data flows between them. Where does it begin? Who touches it? Where does it go next? Where does it rest? What happens if a system fails?

Review your vendor relationships. Are your BAAs current? Do they reflect how your vendors actually operate today — including subcontractors, cloud environments, and AI tools? A BAA from three platform updates ago may not cover what the vendor is doing now.

Ask harder questions. Stop accepting "yes, we're HIPAA compliant" as an answer. Ask about MFA, encryption, audit logs, penetration testing, breach notification timelines, disaster recovery, and subcontractor oversight.

Connect compliance to workflow. If a safeguard disrupts the way people actually work, they will work around it. That workaround is where risk hides. Compliance has to be designed into operations, not bolted on after the fact. You can't blame the vendor or subcontractor if you choose to ignore the safeguard to get something done faster.

Include AI tools in every review. No exceptions.

The Real Issue Is Trust

Patients hand healthcare organizations the most sensitive information they have. Their diagnoses. Their medications. Their mental health history. Their family. Their personal information.

When that information is exposed, it is not just a technical failure or a regulatory event. It is a breach of trust. And for communities that already experience medical mistrust, fragmented access, and disparities in care, that trust is not easily rebuilt.

Security belongs in leadership meetings, not just IT. It belongs in vendor selection, workflow design, staff training, AI governance, and the budget. It belongs in the conversation before something goes wrong, not after.

The organizations that treat it that way will be better positioned when the final rule arrives. More importantly, they will be better positioned to protect the people who depend on them.

Ready to Know Where You Stand?

MDA Solutions works with hospital leaders, clinic executives, and healthcare C-suites to evaluate workflow, AI readiness, vendor risk, and compliance gaps — before they become the kind of problem that ends up in a breach report.

Book a consultation at mdasolutionsllc.com. Let's find the gaps before someone else does.

Sources: HIPAA Journal, May 2026 | HHS/OCR Proposed HIPAA Security Rule NPRM | OCR Report to Congress on HIPAA Compliance and Data Breaches, 2023 | March 2026 Healthcare Data Breach Report, HIPAA Journal | Reuters analysis of proposed HIPAA Security Rule changes

© 2026 MDA Solutions LLC | mdasolutionsllc.com