The HIPAA Security Rule Is Changing for the First Time in Over a Decade: What a Healthcare CEO Needs to Know and Do Now

Why the HIPAA Security Rule Is Being Revised — And What Changed Since 2013

The HIPAA Security Rule's last meaningful update came through the Omnibus Rule in 2013. In 2013, the average hospital ran its EHR partly on paper backups, the iPhone 5 was a year old, public cloud storage in healthcare was a debated possibility rather than an operational reality, and "Business Associate" relationships extended typically two layers deep: a covered entity, its EHR vendor, and that EHR vendor's hosting provider.

What changed since 2013 is the operating environment. Public cloud is the default. Mobile devices are the primary endpoint for clinical staff. Telehealth platforms route ePHI through video and messaging stacks the rule's drafters did not anticipate. AI tools, including clinical scribes, decision support, and claims automation, receive ePHI from EHRs through APIs that did not exist when the rule was last written. Vendor relationships routinely run four and five layers deep, with downstream sub-processors many covered entities cannot name.

The rule is being revised because the operating environment has changed. The CEO who reads the proposed revisions and asks why now will find that the answer is in their own organization's footprint, not in the regulator's office.

The Five Proposed Changes Every Healthcare CEO Should Be Planning For

The Notice of Proposed Rulemaking issued by HHS contains many specific changes. Five of them deserve a CEO's attention because each affects multi-year operating decisions and budget cycles, not quarterly tactical work.

The first is the proposed move from "addressable" to "required" on multiple safeguards. Encryption of ePHI in transit and at rest is the most prominent example. Under the 2013 rule, a covered entity could implement an equivalent alternative or document why encryption did not apply. Under the proposed rule, the encryption obligation becomes mandatory in defined contexts. The implication is operational and budget-immediate. Every device, backup, and cloud-storage location handling ePHI is in scope.

The second is the proposed mandate for multi-factor authentication on systems containing ePHI. The 2013 rule treated authentication as a flexible standard. The proposed rule names MFA explicitly. For most healthcare organizations, this is consistent with where their cyber insurance carriers and accreditation bodies have already pushed them. The rule's effect is to move MFA from a recommended posture to a documented, enforceable obligation with regulatory consequences if absent.

The third is the proposed expansion of audit logging and access tracking requirements. The rule has always required monitoring of system activity. The proposed text sharpens the requirement, naming specific events, defined retention windows, and documented review cadences. Many healthcare organizations generate the logs already; the gap is that they do not have a documented program for reviewing and acting on them.

The fourth is the proposed extension of Business Associate Agreement scope to all sub-contractors handling ePHI. The 2013 rule reaches one layer beyond the BA. The proposed rule reaches further down the chain, requiring covered entities to ensure that BAs flow equivalent obligations to all downstream sub-processors. The CEO implication is significant. Vendor contracts in many healthcare organizations have not been renegotiated since the 2013 rule, and the contract redlines required to comply with the proposed rule will take quarters, not weeks.

The fifth is the proposed strengthening of written-policy and Risk Analysis requirements. The Risk Analysis has always been required. The proposed rule sharpens what counts as adequate, including recency, scope, methodology, and integration with the organization's risk management. Several Resolution Agreements over the past two years have already cited inadequate Risk Analyses; the proposed rule formalizes the standard those settlements have informally established.

What Happens When "Addressable" Becomes "Required"

The compliance distinction sounds technical, but the operational consequences are direct. Under the existing rule, a healthcare organization could choose to encrypt or to implement an equivalent control, and document why. The "addressable" framing gave organizations flexibility, and gave OCR investigators a path to find the documentation insufficient when a breach happened. Many of the small-clinic settlements over the past several years cite the failure to either encrypt or document the alternative.

Under the proposed rule, that flexibility narrows. Encryption becomes the default expectation, and the burden of justifying an alternative, if alternatives are permitted at all in the final rule, shifts upward. The practical implication for a healthcare CEO is that the program's defensibility depends on actually having the safeguards in place, not on producing a written argument for why they are missing. The audit defense becomes a control evidence question, not a documentation question.

That is a different posture, and it changes the CEO's conversation with the IT and compliance functions. The right question is no longer can we explain the gap. The right question is do we have evidence the gap is closed.

Why "Wait for the Final Rule" Is the Most Expensive Planning Posture

A healthcare CEO will hear, somewhere in the organization, this argument over the next several quarters: the rule is not yet final, the regulatory landscape may shift, and the responsible posture is to wait for clarity before committing budget and vendor effort.

That is a false choice, and its cost is the price of a planning cycle the CEO cannot recover. The rule's likely effective date is constrained by the rulemaking timeline, which is largely visible in advance. The implementation work, including vendor contract renegotiation, encryption deployment, MFA rollout, Risk Analysis updates, and audit-log program standup, runs longer than most organizations expect. A CEO who waits for the final rule will find that the budget cycle for implementation has already passed, the vendor contract cycle for amendments has already passed, and the only remaining option is to negotiate compliance under deadline pressure with vendors who know exactly when the rule takes effect.

The right framing is not whether to commit to the final rule before it is issued. It is to plan toward the proposed rule's most-likely outcomes, in writing, with a vendor and budget posture that flexes if the final rule changes. The cost of being wrong is small while the cost of being late is large.

The Three Decisions a CEO Should Make Before the Rule Takes Effect

There is a recognizable sequence among healthcare partners who get this transition right. The CEO drives three decisions, in order, before the operational work begins.

The first decision is to commission a current-state assessment of the organization against the proposed rule's principal changes, including encryption coverage, MFA coverage, audit-log program maturity, vendor contract scope, and Risk Analysis recency. This is an exec-level briefing document, not an IT-level deliverable. Five Nines produces this for our healthcare partners as a one-page board-ready summary with the gaps named explicitly.

The second decision is to allocate budget across two cycles, both current and next, based on the gap profile. Some organizations have most of the safeguards in place and need only documentation work. Others have substantial encryption or MFA gaps and need real spend. The split between the two cycles, meaning what to fund now and what to plan into next year's budget, should be made by the CEO and CFO together, not deferred to IT.

The third decision is the vendor letter. The covered entity's BAs need to receive a written communication that the organization expects equivalent safeguards through the chain of sub-processors, that contract amendments may follow, and that the timeline is anchored to the rule's likely effective date. This letter is what protects the CEO when the rule lands. It establishes that the organization gave its vendors notice and allowed time to respond, and it forces the BA to engage rather than wait.

Those three decisions, in that order, are the ones that separate organizations that meet the rule on their own terms from organizations that meet it under audit.

Plan Toward the Proposed Rule Now — The Final Rule Won't Wait for Your Budget Cycle

The 2013 rule was written for an operating environment that no longer exists. The proposed rule attempts to catch the regulatory framework up to where the industry has actually been operating for the last several years. A CEO who plans toward the proposed rule, on a timeline that runs ahead of the final rule's effective date, will land the transition with the budget and vendor work already in motion. A CEO who waits will land it under deadline pressure, and the operational and financial cost of that pressure will be the part of this transition that does not appear in the rule's text but appears in the CEO's quarterly review.

If your healthcare organization has not produced a board-ready briefing on the proposed Security Rule changes in the last six months, that is the conversation to have with your Tech-Operations partner before the final rule is issued.

Five Nines Technology Group is the Tech-Operations partner serving hospitals, clinic systems, and healthcare practices across the region. We focus on helping CEOs and boards translate regulatory change into operating decisions on a timeline that runs ahead of the rule, not behind it.