Your BAA Doesn't Protect Your PHI. Here's What Does.

In March 2026, the HHS Office for Civil Rights (OCR) announced a major settlement with MMG Fusion, LLC, a healthcare software company that operates as a third-party business associate. An unauthorized actor infiltrated their systems, exposing the Protected Health Information (PHI) of approximately 15 million individuals. The breach included names, dates of birth, and appointment details—and left the company facing a strict, multi-year federal corrective action plan.

MMG Fusion was a business associate. The covered entities whose patients were affected and the healthcare providers who had signed Business Associate Agreements (BAAs) with them didn't breach a single thing. Their own internal networks were untouched, yet their patient data was compromised and their vendor ecosystem disrupted.

This is a compliance conversation that gets skipped over. A BAA documents the relationship. It doesn't protect the data.

What Is a Business Associate Under HIPAA?

A business associate is any person or entity that performs functions or activities on behalf of a covered entity that involve the use or disclosure of Protected Health Information (PHI). The list is broad:

• Billing and coding companies
• Cloud storage providers hosting PHI
• Third-party EHR vendors
• Medical transcription services
• Health information exchanges
• Legal and accounting firms handling PHI on your behalf

The moment PHI moves to any of these parties, HIPAA's Security Rule goes with it. The BAA formalizes that transfer. But signing a contract and controlling what happens to the data afterward are very different things.

What Does a Business Associate Agreement Actually Cover?

A BAA establishes that the business associate is required to:

• Use PHI only for the agreed purpose
• Implement appropriate safeguards to prevent unauthorized use or disclosure
• Report breaches to the covered entity
• Return or destroy PHI at the end of the relationship

Notice what isn't in that list: actual controls on the data. A BAA says your BA must protect the PHI. It doesn't say how, it doesn't enforce how, and it definitely doesn't keep enforcing how once the data has moved to their system.

The BAA is a contract. Contracts don't encrypt files.

Why Are Business Associate Breaches So Common?

Because PHI routinely travels to environments with smaller security budgets, smaller IT teams, and less oversight than the covered entity itself.

Your hospital may have a mature CISO function, a dedicated security team, and a multi-million dollar security stack. Your billing processor has three IT staff and a shared file server. When your billing staff emails PHI to that processor — which happens thousands of times a week at most health systems — the security posture of the data becomes theirs, not yours.

HHS OCR enforcement data is consistent on this: business associate breaches now account for a significant and growing share of reportable HIPAA incidents. Healthcare breach costs average $7.42 million per incident, making it the costliest sector for 14 consecutive years. Many of those costs land on covered entities whose own systems were never compromised.

Your security ceiling — for that PHI — is the business associate's security floor.

What Happens When Your Business Associate Gets Breached?

This is where the BAA's limitations become concrete.

When the BA is breached, the covered entity must:

• Conduct a risk assessment to determine whether PHI was compromised
• Notify affected individuals, HHS, and potentially the media (for breaches affecting 500+ individuals in a state)
• Potentially face OCR investigation and financial penalties, regardless of whether the covered entity did anything wrong

The BAA will typically require the BA to notify the covered entity of the breach. That notification requirement didn't stop the breach from happening. It just ensures you find out about it, usually after the damage is done.

That's not a failure of the contract. It's the nature of contracts: they govern behavior; they don't enforce it in real time.

Does Encrypting PHI Before Sharing It With a Business Associate Satisfy HIPAA?

This is the question most healthcare security teams should be asking — and most aren't.

HIPAA's Security Rule (45 CFR § 164.312) addresses encryption as an "addressable" specification, not a required one — which often gets interpreted as "optional." The nuance is important: "addressable" means you must either implement it or document why an equivalent alternative is sufficient. In practice, encryption is the standard answer.

What encryption at rest (on your servers) doesn't solve: what happens to PHI once it leaves your system. A file encrypted in your EHR is decrypted when it's exported to a billing spreadsheet, attached to an email, or uploaded to the BA's portal. At that point, the security of that data depends entirely on what the BA does with it.

Encrypting PHI at the file level — before it leaves — changes that. The file arrives at the BA's system still encrypted, still access-controlled by your policy. The BA gets the access they need to do their job. But if their system is breached, the attacker gets a file they can't read.

That's what "protecting PHI in transit and at rest" actually means in a BA context. Not encrypting your servers. Encrypting the data before it moves.

How Does File-Level Encryption Change the BA Risk Equation?

When PHI is protected at the file level before leaving your environment, several things change at once.

The BA breach risk changes. If a BA's systems are compromised and the PHI was transmitted as encrypted files, the attacker has ciphertext. They can't read it, they can't use it, and the practical harm to patients is dramatically lower. OCR's own breach notification guidance acknowledges that encrypted data breaches carry a lower presumption of harm, which affects notification obligations.

The audit trail changes. Per-file encryption systems log every access to every file — who opened it, when, from what system. If an OCR investigation asks "who had access to this patient's record over the past 18 months," the answer is immediately queryable, not reconstructed from fragmented system logs.

The offboarding risk changes. When a BA relationship ends, file-level access can be revoked centrally, even for files the BA has already downloaded to their systems. The data becomes inaccessible the moment the relationship ends, not whenever their IT team gets around to deleting it.

How Theodosian Addresses the BA Problem

Theodosian applies per-file encryption and access controls to PHI before it leaves the covered entity's environment. Every file processed through Theodosian carries its own FIPS 140-3 validated encryption and its own access policy — so the protection travels with the data, not just with the container it started in.

When PHI goes to a billing processor, a transcription service, or a health information exchange, it arrives encrypted. The BA gets access — under the conditions the covered entity sets — for the duration they need it. When the work is done, access is revoked from the covered entity's side, regardless of where the file ended up.

The audit log is per-file, per-user, per-action. OCR investigations, internal compliance reviews, and breach risk assessments all get a queryable record of every access event. Not a SIEM summary, a file-level log.

That's not just supporting HIPAA compliance. That's what the technical safeguards in § 164.312 were written to achieve: actual control over PHI, wherever it goes.

FAQs: Beyond the Business Associate Agreement (BAA)