Chalice Beam
Sr. Director Healthcare Assessment, Coalfire
HIPAA
The HIPAA Security Rule NPRM: What Business Associates Should Fix Now
July 9, 2026
The HIPAA Security Rule notice of proposed rulemaking (NPRM) is still a proposal, not a final rule.
Business Associates should not treat that as a reason to wait. From an assessment perspective, the more important signal is the direction of travel by electronic protected health information (ePHI). HHS is taking areas that many organizations have handled with too much discretion, too little documentation, or too little testing and turning them into more explicit, more provable expectations.
This matters for business associates because many of the hardest changes sit below the policy layer. Multi-factor authentication, segmentation, vendor evidence, and contingency plan communications do not happen through memo writing. They require scope decisions, architecture work, contract updates, testing, and repeatable evidence. Those changes also take time, especially for organizations that rely on inherited controls, legacy platforms, or a deep subcontractor chain.
From where we sit in healthcare security assessments, that is the real story in this proposal. The biggest impact on business associates is not that OCR has introduced entirely new concepts. It is that the proposal would make it harder to defend weak execution in areas that have already been causing problems for years.
Risk analysis has to become an operating document
Risk analysis has always been required under the current Security Rule, and OCR has spent years signaling that weak risk analysis remains one of the most common compliance failures. What changes in the proposal is the level of specificity. HHS describes a more concrete expectation around technology asset inventories, network maps, threats, vulnerabilities, existing safeguards, and documented determinations of likelihood and impact.
For business associates, that should end the habit of treating the annual assessment as a standalone compliance deliverable. In mature programs, risk analysis drives funding, remediation sequencing, and control validation. In immature programs, it often turns into a gap checklist that never materially changes operations. That distinction matters because the rest of the proposal depends on it. If you cannot clearly define the systems, data flows, dependencies, and risks in scope, you will struggle to justify your multi-factor authentication (MFA) coverage, segmentation boundaries, restoration priorities, or vendor oversight model.
Assessment teams see this gap often in managed service providers, billing platforms, digital health vendors, and cloud heavy environments where responsibility is distributed across multiple teams and vendors. The practical question is not whether a risk analysis exists. The question is whether it can support decisions and withstand scrutiny.
MFA scope is likely wider than many Business Associates assume
The proposal would require MFA across technology assets in relevant electronic information systems, subject to limited exceptions. For many Business Associates, the challenge is not the principle. Most security leaders already agree that MFA belongs on remote access, privileged access, and critical applications. The challenge is scope.
HHS ties scope to systems that can affect the confidentiality, integrity, or availability of ePHI, not only the applications that store or display it. That brings supporting infrastructure into view. Identity systems, administrative consoles, remote management tools, integration points, and certain shared services can all become part of the discussion. In assessments, that is where organizations often discover inconsistent deployment, exception creep, or legacy systems that nobody wants to own.
Business Associates that have grown through acquisition or built around custom workflows should pay close attention here. If MFA cannot be implemented cleanly across the environment, the problem is rarely just technical. It usually points to outdated inventories, unclear ownership, or architecture that has outlived its original design assumptions.
Third party oversight is moving from contract language to recurring evidence
The proposal's most important Business Associate angle may be the annual verification requirement. Covered Entities would need written verification that their Business Associates have implemented required technical safeguards. Business Associates would need the same kind of verification from downstream subcontractors.
That is a meaningful shift. Many organizations have historically treated vendor oversight under HIPAA as a contract management exercise centered on the Business Associate Agreement. The proposal points toward an evidence cycle instead. Covered Entities and upstream Business Associates will be required to have analysis performed by someone with relevant cybersecurity expertise, plus certification from an authorized individual. That moves the conversation from satisfactory assurances on paper to defensible operating evidence.
This is where Business Associates with complex delivery models may feel the most pressure. If your environment depends on cloud providers, offshore support, SaaS components, or shared operational vendors, you need visibility into which subcontractors touch ePHI, which controls they operate, and what evidence you can realistically obtain from them. Unfortunately, many organizations do not have that mapped cleanly today.
Flat networks will be harder to defend
The proposal's segmentation expectation lines up with a common finding in healthcare assessments. Many environments still rely on broad trust relationships, shared administrative pathways, and network designs that make lateral movement too easy once an attacker gains a foothold. Business Associates that support multiple clients or multiple regulated workloads in shared infrastructure should view this as a material exposure, not a minor technical improvement.
Segmentation matters because it turns abstract security principles into enforceable boundaries. It shapes authentication scope, logging, administrative access, blast radius, and restoration planning. It also tends to expose uncomfortable truths about undocumented dependencies. When teams start mapping where ePHI enters, moves, and leaves the environment, they often find integration servers, support tooling, and administrative paths that were never included in the original compliance narrative.
That is why segmentation work usually takes longer than expected. It is not just a firewall project. It is an architecture and scoping exercise that forces the organization to decide what belongs together, what should be isolated, and what evidence will support those decisions.
The 24-hour contingency plan notice requirement changes incident playbooks
One of the proposal's most immediate operational implications is the requirement for Business Associates to notify Covered Entities, and for subcontractors to notify Business Associates, upon activation of a contingency plan without unreasonable delay and no later than 24 hours after activation. That is separate from breach notification. The trigger is operational disruption and contingency plan activation, not a final legal conclusion about whether a reportable breach occurred.
That distinction matters. Many organizations have incident response plans that focus heavily on containment, forensics, and breach analysis, but they have not built a communications trigger around contingency plan activation itself. If the proposal is finalized in substantially similar form, Business Associates will need clearer decision points, escalation paths, and pre-negotiated expectations in their BAAs around who gets notified, when, and with what level of detail.
From an assessment standpoint, this is another example of the proposal pushing organizations to connect controls that are often managed separately. Your contingency planning, incident response, legal review, executive communications, and client contract obligations need to work as one operating model.
What Business Associates should do now
Business Associates do not need to wait for a final rule to take sensible action. The best next step is a readiness assessment that tests whether your current program can produce evidence, not just policy statements. That review should answer a few practical questions.
Can you tie your risk analysis to a current asset inventory, network map, and remediation plan? Can you show where MFA is deployed, where it is not, and who approved the exceptions? Do you know which subcontractors create, receive, maintain, or transmit ePHI on your behalf, and what evidence you can obtain from them? Can you explain your segmentation boundaries in a way that would make sense to a client, an assessor, or a regulator? If you activated a contingency plan tomorrow, do your incident playbooks and BAAs support timely notice upstream?
Those questions reflect an assessment services lens because they focus on proof, scope, and operational readiness. That is where many Business Associates will either gain credibility with Covered Entity clients or lose time trying to reconstruct their story under pressure.
The proposed rule may still change. Legal interpretation and contract language should go through counsel. Even so, the operational message for Business Associates is already clear. Organizations that use this window to tighten evidence, architecture, and vendor oversight will be in a stronger position than those that wait for the final text before they start doing the hard work.
Coalfire's team of healthcare cybersecurity and compliance specialists helps Business Associates and Covered Entities assess readiness against the proposed HIPAA Security Rule changes, from risk analysis, vendor management programs, network evaluations, threat detecting, to compliance reviews. If you'd like to talk through where your organization stands, reach out to our Healthcare team.