HIPAA Business Associate Oversight Under the New Rule: Verifying, Not Trusting, Your Vendors

A signed business associate agreement has never told you whether a vendor is secure. It tells you the vendor promised to be. The proposed HIPAA Security Rule finally makes that distinction explicit, and it turns a filing-cabinet document into a recurring assurance workflow.

Most healthcare organisations treat the business associate agreement as a box to tick at onboarding. Legal drafts it, procurement files it, and nobody reads it again until there is a breach and a regulator asks who was responsible for what. The paper says the business associate will implement appropriate safeguards. It does not say whether they did, whether they still do, or how anyone would know. For two decades that gap has been tolerated because the rule never required you to close it. The Office for Civil Rights is now proposing to change that.

What the proposal actually requires

The Security Rule Notice of Proposed Rulemaking was published in the Federal Register on 6 January 2025, following the HHS announcement in late December 2024, with a 60-day comment period that closed in early March 2025. At the time of writing the rule is not final; a final rule is pending and its timing and content may shift. So everything here should be read against the final text when it lands, not banked as settled law. But the direction is clear enough to plan against, and the verification requirement in particular is unlikely to soften, because it addresses a gap regulators have been complaining about for years.

The core proposal is this. A business associate would have to verify, at least once every twelve months, that it has deployed the technical safeguards the Security Rule requires to protect electronic protected health information. That verification is not a self-attestation on a form. It has two specific components: a written analysis of the business associate’s relevant electronic information systems, performed by a subject matter expert, and a written certification that the analysis has been performed and is accurate. Business associate contractors would owe the same verification to the business associates they serve. The obligation runs down the chain.

Read that carefully, because the wording does the work. “A written analysis by a subject matter expert” is not a questionnaire the account manager fills in over lunch. It is a technical assessment of actual systems, signed off by someone competent to make it, produced on a clock. The covered entity’s job shifts from holding a promise to holding evidence that the promise is being kept, refreshed annually. That is a different operating model, and it does not fit in a filing cabinet.

Why the signed BAA was never the control

The uncomfortable truth the proposal exposes is that the agreement was always a liability instrument, not a security control. Its function was to allocate blame and satisfy the contracting requirement, not to make the vendor secure. A firm can hold a perfectly drafted BAA for a vendor that has no multi-factor authentication, encrypts nothing at rest, and has not patched a public-facing system in eighteen months. The document and the reality are entirely decoupled, and until now the rule only inspected the document.

This is the same failure mode that runs through third-party risk generally. The organisation outsources a function, signs a contract, and quietly outsources the risk judgement along with it, without ever building the machinery to know whether the vendor’s actual posture matches the contractual one. I have written before about how your vendors end up making decisions for your business when you stop looking; the BAA-on-file culture is that pattern in its purest form. The proposed rule is, in effect, the regulator refusing to accept the promise as a proxy for the practice.

The verification requirement is a system, not a form

If verification has to happen every twelve months, for every business associate, and be backed by an expert analysis and a certification, then you are running a recurring process with a schedule, owners, artefacts and a retention story. Treating it as an annual email exchange will not survive contact with a regulator asking to see the evidence. The things that need to exist are concrete:

• An inventory of every business associate and contractor that touches ePHI, mapped to what data each one holds and which systems it reaches. If you cannot list them, you cannot verify them.
• A verification cycle with dates. Each vendor has a due date; each due date has an owner; missed dates escalate. This is a calendar-driven control, like certificate renewal, not an ad hoc chase.
• A defined artefact you will accept. The written analysis and certification the rule describes, or a mapped equivalent, with a standard for what “a subject matter expert” means so you are not accepting a marketing PDF as an assessment.
• A place to store it and a way to retrieve it on demand, tied to the vendor record, so that “show me the current verification for this business associate” is a query, not an archaeology project.
• An exception path for when a vendor cannot or will not verify, because that is now a live risk decision the covered entity has to own, not a silence it can ignore.

None of that is exotic. It is ordinary supplier-assurance engineering, and any firm that has run a serious vendor security programme already has the shape of it. The novelty is that HIPAA would now compel it for the health sector, with a named cadence and a named artefact.

It does not arrive alone

The verification duty sits inside a broader tightening. The same NPRM proposes to make a range of safeguards mandatory that were previously “addressable” — encryption of ePHI at rest and in transit, multi-factor authentication, a maintained technology asset inventory and network map, annual compliance audits and penetration testing, all with limited exceptions. I have covered that wider shift in the HIPAA Security Rule overhaul separately. What matters for third-party control is that these are the very safeguards the annual verification is supposed to confirm. The verification requirement and the mandatory-controls requirement are two ends of the same rope: the rule specifies what “secure” means, then requires your vendors to prove annually that they meet it.

There is a resilience thread here too. The proposal would also require business associates to notify covered entities within 24 hours when they activate a contingency plan or an emergency affects their electronic systems. That is a tight window, and it only works if your recovery and continuity expectations are written into the relationship and understood on both sides before the incident, not discovered during one. Verification tells you the vendor is secure on a normal day; the 24-hour notice is about the day it is not.

What to do before the rule is final

The mistake would be to wait for the final text and then scramble. The verification workflow takes longer to build than the compliance deadline that will follow the final rule, because the hard part is not the policy — it is knowing who all your business associates are, agreeing what evidence you will accept, and standing up a process that produces and stores it every year without heroics. That work is worth doing now regardless of the rule’s final shape, because it is simply good third-party governance, and because a firm that already runs it converts to whatever the final text says by editing a template rather than inventing a capability.

When the rule bites, “we have a BAA on file” stops being an answer. The answer becomes “here is this vendor’s current verification, dated within the last twelve months, with the analysis and the certification behind it.” If you cannot produce that on the day it is asked for, the signature you collected at onboarding will not save you — and it never could.