Most people sign a Business Associate Agreement without reading it, on the assumption that it is a formality that transfers risk to the vendor. It isn't a formality, it doesn't transfer much, and since 2013 it hasn't been the only thing binding the vendor. The regulation is short enough to read in full, so the useful thing is to know what it actually says.

What a BAA is and where it comes from

The written contract requirement sits at 45 CFR 164.502(e) and the contract terms themselves at 45 CFR 164.504(e). The security-specific organizational requirements are at 45 CFR 164.314(a).

A business associate is any person or entity that creates, receives, maintains or transmits protected health information on behalf of a covered entity. For a healthcare or NEMT operator that means the call center, the dispatch vendor, the billing company, the credentialing firm, the transcription service, and the cloud platform holding any of it. If they touch PHI to do work for you, they are a business associate, and operating without a BAA is itself a violation whether or not anything ever goes wrong.

The ten clauses the rule requires

164.504(e)(2)(ii) sets out what the contract must require of the business associate. Here they are in the order the regulation lists them, with what each one means in practice.

ClauseWhat the BA must doWhat it means operationally
(A)Not use or further disclose PHI other than as permitted by the contract or required by lawThe contract, not the vendor's judgment, defines the permitted scope. Analytics, marketing and AI training are outside it unless written in.
(B)Use appropriate safeguards and comply, where applicable, with Subpart C for electronic PHIThe Security Rule applies to the vendor directly, not by reference.
(C)Report any use or disclosure not provided for by the contract, including breaches, as required by 164.410This is the notification clause. It is where you set a real clock. See below.
(D)Ensure subcontractors agree to the same restrictions and conditionsFlow-down. Your vendor's vendors are in scope, and you should be able to see who they are.
(E)Make PHI available for individual access under 164.524If a patient requests their record and part of it lives with the vendor, the vendor has to produce it.
(F)Make PHI available for amendment under 164.526Corrections have to propagate into the vendor's copy.
(G)Make available the information needed for an accounting of disclosures under 164.528The vendor has to be able to answer who received what.
(H)Where carrying out your obligation, comply with the requirements that apply to youIf the vendor performs a covered entity function, it inherits that function's rules.
(I)Make internal practices, books and records available to the SecretaryHHS can inspect the vendor. Ask whether that has ever happened.
(J)At termination, if feasible, return or destroy all PHI"If feasible" is doing a lot of work here. Make it specific.

The contract must also give you the right to terminate for material breach. That right is only as useful as your ability to detect one, which is why the reporting clause and the audit clause matter more than the termination clause.

Direct liability: what changed in 2013

Before the Omnibus Rule, a business associate answered to its client contractually and to nobody else. The HITECH Act at 42 U.S.C. 17931 changed that, and 45 CFR 164.306(a) now states the Security Rule's general requirements apply to "covered entities and business associates" alike.

OCR published a fact sheet in May 2019 listing the areas where it can act against a business associate directly. They include failure to comply with the Security Rule, failure to notify the covered entity of a breach, impermissible uses and disclosures, failure to give HHS access to records, failure to enter into BAAs with its own subcontractors, failure to apply minimum necessary, and retaliation. OCR also notes what a BA is not directly liable for, including failing to have a BAA in place with the covered entity, which remains the covered entity's obligation.

Read that last point carefully, because it reverses a common assumption. If there is no BAA, the regulator's first question is for you, not for your vendor. Getting the agreement signed is your duty.

The breach clock, and why 60 days is the wrong number to write down

45 CFR 164.410 requires a business associate to notify the covered entity, not individuals, following discovery of a breach of unsecured PHI, without unreasonable delay and no later than 60 calendar days after discovery. Notice must identify each individual affected to the extent possible.

Two details do most of the work:

  • Discovery is earlier than you think. A breach is treated as discovered on the first day it is known, or by exercising reasonable diligence would have been known, to any employee, officer or agent of the business associate other than the person who committed it. A vendor that doesn't review its logs can't argue it had not discovered anything.
  • Sixty days is an outer limit, not a target. Your own obligation to notify individuals under 164.404 also runs 60 days from discovery. If your vendor uses its full window, yours is gone. This is why serious BAAs tighten the vendor clock to 24, 48 or 72 hours from confirmed discovery, and why a vendor that volunteers a tighter number is telling you something real about its detection capability.

Ask for the number in hours and get it written into the contract. A vendor that will commit to notifying you within 24 hours of confirmed discovery is making a claim you can hold them to. A vendor that repeats "within 60 days as required" is quoting the ceiling.

Need a BPO that signs a BAA before the first call, not after the first invoice?Free operations audit, with a written plan within 1 business day.

Get My Free Audit

Flow-down: the part almost nobody checks

45 CFR 164.308(b)(2) requires a business associate to obtain satisfactory assurances from its own subcontractors that create, receive, maintain or transmit ePHI on its behalf, and 164.314(a)(2)(i)(B) carries the same requirement into the contract terms. So the chain is meant to be unbroken all the way down.

In practice it goes dark quickly. The clearest federal evidence of that is GAO-06-676, which found that 57 percent of Medicare Advantage contractors didn't know whether their domestic vendors further transferred PHI offshore, along with 29 percent of Medicare fee-for-service contractors and 26 percent of state Medicaid agencies. The report is old. The structural problem it documents isn't, and it is the precise fear a healthcare operator has about outsourcing.

The fix is a question, not a clause: ask for the list. A vendor that can name every subcontractor touching your PHI, and produce the executed BAA for each, has a program. A vendor that says "we have BAAs in place" without a list has an intention.

What the proposed rule would add, and why it is not law yet

A great deal of vendor content refers to "the 2026 HIPAA Security Rule". There is no such rule in force. What exists is a Notice of Proposed Rulemaking, RIN 0945-AA22, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information", published in the Federal Register on January 6, 2025. The comment period closed March 7, 2025. HHS has since moved the rulemaking to the Long-Term Actions section of the Unified Agenda with a projected final action date of July 2027, which signals it doesn't expect to finalize within twelve months. Agency timetables aren't binding.

If it is finalized broadly as proposed, three changes land directly on business associates:

  • The addressable and required distinction would disappear, making every implementation specification mandatory subject to narrow documented exceptions. Encryption at rest and in transit and multi-factor authentication would become explicit requirements rather than addressable ones.
  • A business associate would have to notify the covered entity within 24 hours of activating a contingency plan. That is a different and earlier trigger than the 60-day breach clock.
  • A business associate would have to provide written verification at least every 12 months that required technical safeguards are deployed, analyzed by a subject matter expert and certified by someone with authority at the BA.

The honest framing for any vendor is: this isn't law, the direction is clear, and here is what we already do. A vendor telling you today that "the 2026 rule requires MFA" is either misinformed or hoping you are.

What to ask before you sign

Nine questions, all answerable in writing:

  • Will you sign our BAA, or do you require yours? If theirs, read clause (J) and the notification clause first.
  • How many hours from confirmed discovery until you notify us? Get a number, then get it in the contract.
  • Who is your named security official under 164.308(a)(2)? A name and a title, not a department.
  • When was your last risk analysis, and who performed it? A date. If the answer is vague, that is the single most likely enforcement finding against them.
  • List every subcontractor that will touch our PHI, and confirm a BAA exists with each.
  • Where will the work be performed? See below, because for Medicaid this is often a hard gate.
  • Do agents have unique named logins, and is MFA on everything that reaches PHI?
  • What happens to our data at termination, and how long does it take? Clause (J) says "if feasible". Make it a number of days and a method.
  • May we audit you, or receive a completed security questionnaire? Willingness matters more than the answers.

One question you should not ask is whether they are HIPAA certified. HHS has stated since 2003 that no such certification exists and that it doesn't endorse private certifications, which its own FAQ confirms. A vendor that claims one has told you something useful, just not what it intended.

How we handle it

We sign a Business Associate Agreement with every healthcare client before any protected health information is handled. Agents complete HIPAA training before touching client work. Access is role based and logged, and we work inside your systems rather than copying data into a platform of our own, which keeps the number of PHI locations down instead of managing more of them. Our incident process is written: contain, assess scope, notify your designated contact promptly, and support the notification timeline your BAA sets. We don't conceal incidents.

We also state on our trust center what we don't have. No SOC 2. No HIPAA certification, because there is no such thing. If that changes, we will publish the scope and the date. In the meantime we will complete a reasonable security questionnaire as part of your due diligence, which is the version of proof that can actually be checked. If it is useful, our guide to the questions to ask any healthcare BPO goes further into what a good answer sounds like.

Frequently asked questions

The required terms are listed at 45 CFR 164.504(e)(2)(ii). The business associate must not use or disclose PHI beyond the contract or as required by law, must apply appropriate safeguards and comply with the Security Rule for ePHI, must report impermissible uses and disclosures including breaches under 164.410, must ensure its subcontractors agree to the same restrictions, must make PHI available for individual access under 164.524 and amendment under 164.526 and for an accounting of disclosures under 164.528, must comply with the covered entity obligations it carries out, must make its books and records available to the Secretary, and must return or destroy all PHI at termination if feasible. The agreement must also allow termination for material breach.

Directly liable. The HITECH Act at 42 U.S.C. 17931 and the 2013 Omnibus Rule extended the Security Rule to business associates, and 45 CFR 164.306(a) now states the general requirements apply to covered entities and business associates alike. OCR published a fact sheet in May 2019 listing where it can enforce directly, including Security Rule failures, failure to notify the covered entity of a breach, impermissible uses and disclosures, failure to give HHS access, failure to have BAAs with its own subcontractors, and minimum necessary failures. OCR also notes a business associate isn't directly liable for failing to have a BAA with the covered entity, which stays the covered entity obligation.

45 CFR 164.410 requires notice to the covered entity without unreasonable delay and no later than 60 calendar days after discovery. Discovery is the first day the breach is known, or would have been known by exercising reasonable diligence, to any employee, officer or agent other than the person who committed it. Sixty days is a ceiling and a poor target, because the covered entity clock to notify individuals also runs 60 days from discovery. Contracts routinely tighten the vendor clock to 24, 48 or 72 hours from confirmed discovery, and that number is worth negotiating.

Yes. 45 CFR 164.308(b)(2) requires a business associate to obtain satisfactory assurances from any subcontractor that creates, receives, maintains or transmits ePHI on its behalf, and 164.314(a)(2)(i)(B) carries that into the contract terms. The practical test is to ask for the list of subcontractors that will touch your PHI along with the executed agreements. A vendor that can produce the list has a program. A vendor that only says agreements are in place has an intention.

No. What exists is a Notice of Proposed Rulemaking, RIN 0945-AA22, published in the Federal Register on January 6, 2025, with the comment period closed on March 7, 2025. It would remove the addressable and required distinction, mandate MFA and encryption at rest and in transit, and add asset inventories, annual risk analysis, vulnerability scanning and penetration testing. HHS has moved it to the Long-Term Actions section of the Unified Agenda with a projected final action date of July 2027. It isn't law, and a vendor describing it as a current requirement is wrong.

SS
Syed Shahzaib Shah, Founder & CEO

Syed Shahzaib Shah founded SS Support Network LLC in 2020 and leads the company as CEO. He works in cybersecurity research and coordinated vulnerability disclosure, and has reported security issues to large technology vendors and to government systems. SS Support Network LLC is a US-registered business process outsourcing company headquartered in Vancouver, Washington, with a 24/7 global delivery team.