2026 HIPAA Security Rule Update: What Healthcare Leaders Can Prepare Now While the Rule Is Still Proposed

The proposed Security Rule was published in the Federal Register on January 6, 2025. Earlier regulatory planning had pointed to a possible final action in 2026. That did not happen.

The 2026 Unified Agenda now classifies RIN 0945-AA22 as a Long-Term Action and lists July 2027 as an estimated final-action date. That date is an agency planning estimate, not itself a statutory deadline.

For healthcare executives, the distinction matters. HHS continues to state that the current Security Rule remains in effect. A proposed provision is therefore not a present HIPAA requirement simply because it appears likely, prudent, or technically sensible.

That does not make the proposal irrelevant. It changes how leadership should use it. The proposal is best treated as a planning signal for where federal security expectations may become more specific, while today’s Security Rule remains the compliance baseline.

A sound readiness review begins with the HIPAA Security Standards that apply today.

The current rule requires:

• regulated entities to protect the confidentiality, integrity, and availability of electronic protected health information,
• perform an accurate and thorough risk analysis,
• manage identified risks,
• maintain required safeguards,
• and review security measures as conditions change.

That baseline is important because many of the proposed changes do not create an entirely new security problem. They would make several expectations more prescriptive, measurable, or explicitly documented.

An organization that cannot show how its current risk analysis connects to systems, vendors, access decisions, contingency planning, and remediation has work to do regardless of when the proposed rule is finalized.

The same distinction applies to addressable implementation specifications. Under the current rule, addressable does not mean optional. The organization must determine whether an addressable specification is reasonable and appropriate, implement it when it is, or document the rationale and an appropriate alternative when applicable.

Encryption is a familiar example. The proposal would generally make encryption of ePHI at rest and in transit required with limited exceptions, but that proposed change should not be rewritten into current policy as though the final rule already exists.

Healthcare compliance consulting becomes an operating discipline rather than a policy exercise. Leadership needs to know not only what the organization says it does, but where the evidence lives, who owns the control, what happens when conditions change, and how a known gap moves into corrective action.

HHS’s fact sheet points toward a more explicit security operating model. The NPRM would, among other changes:

• remove the current required-versus-addressable distinction for implementation specifications,
• require a technology asset inventory and network map,
• make risk analysis more specific,
• strengthen contingency and incident-response requirements,
• expand business-associate verification,
• generally require encryption and multifactor authentication with limited exceptions,
• and add recurring testing and review expectations.

The details may change before any final rule is issued. The direction is still useful for planning: HHS is signaling a preference for security programs that are documented, testable, asset-aware, and easier to evaluate objectively.

Many proposed elements depend on work that crosses IT, compliance, operations, finance, human resources, clinical leadership, and outside vendors. Asset inventories, access changes, recovery testing, and vendor assurance all depend on operating ownership, not a last-minute policy update.

Leaders can start building that operating capacity now without claiming that the proposed cadence, certification language, or technical specifications are already mandatory.

This is not a substitute Security Rule checklist. It is a sequencing tool. A compliance audit checklist can help expose missing documentation or weak controls, but the executive question is what happens after a gap is found.

If a restore test fails, who owns the remediation?

 If a vendor cannot provide requested evidence, who decides whether to accept, mitigate, or replace that risk?

If MFA is absent from a legacy system, is the constraint technical, contractual, financial, or operational?

Those questions convert readiness from a list of controls into a management system.

The proposal contains specific timeframes and recurring activities. Those details are exactly where leaders should be disciplined.

Do not tell staff that a proposed 72-hour restoration target, annual audit, six-month vulnerability scan, annual penetration test, annual asset-map review, or a particular vendor certification is a current HIPAA deadline unless another applicable requirement independently creates that obligation.

Do not rewrite contracts solely on the assumption that the final rule will preserve every proposed provision.

Do not purchase technology because a seller says a proposed control is already federally mandated.

Instead, convert proposed timeframes into scenario tests. Ask whether the organization could restore critical systems in the proposed window.

Ask what an annual penetration test would require from vendors and budgets.

Ask whether security evidence from business associates is sufficiently structured to support stronger verification.

Ask how quickly access can actually be changed when a worker leaves or changes roles.

Scenario testing produces information that leadership can use even if the final rule changes. It reveals implementation lead time, resource constraints, vendor dependencies, and control weaknesses before those issues become deadline problems.

A useful security program should not depend on memorizing the final wording of one regulation. It should be able to show how a requirement or risk moves through the organization.

For each material security area, leadership should be able to trace five things:

• the applicable requirement or risk,
• the accountable owner,
• the system or workflow where the control operates,
• the evidence that the control is functioning,
• and the escalation or remediation path when it is not.

That trace is especially valuable during a period of regulatory uncertainty. If the final rule changes a proposed frequency, exception, or technical specification, the organization can update the requirement layer without rebuilding the entire operating model. The owner, evidence source, testing process, and remediation structure are already visible.

Policies matter, but they do not prove that terminated accounts were removed promptly, backups restored successfully, or a vendor fulfilled its security responsibilities. Evidence has to connect written expectations to observed operations.

For teams strengthening compliance monitoring between formal reviews, the same principle applies: leadership needs enough visibility to know whether controls are still working as workflows, systems, staffing, and vendors change.

The shift to Long-Term Actions may relieve immediate deadline pressure, but it should also improve planning quality. Organizations can use the additional time to distinguish quick corrective actions from investments that require a budget cycle or vendor project.

Some gaps can be resolved through ownership, documentation, access cleanup, or better evidence collection. Others may require identity architecture, encryption changes, network redesign, backup modernization, contract changes, security tooling, or new testing capacity. Those projects compete for capital and staff attention.

Leadership should therefore ask a more useful budgeting question than “What will the final rule cost?”

The better question is: which security capabilities are already justified by our current risk profile, and which proposed changes would materially increase the scope, frequency, or proof we would need?

That framing protects the organization from two opposite errors. One is postponing necessary current-rule remediation because a future rule was delayed. The other is committing money to a specific proposed requirement before HHS has finalized it.

Use the current rule as the compliance baseline and the proposal as a structured stress test. Make sure the organization can explain its ePHI environment, current risk analysis, access model, encryption decisions, incident and contingency capabilities, vendor dependencies, and unresolved remediation. Then identify which proposed provisions would create the longest implementation lead time if they survive into a final rule.

Keep the proposal in a controlled watch process. Assign an owner to monitor RIN 0945-AA22 and HHS/OCR updates. Record which readiness assumptions depend on proposed language. When a final rule is published, compare the final text against those assumptions before changing policy, declaring compliance, or setting a final implementation deadline.

This gives leadership a disciplined position: no manufactured urgency, no regulatory complacency, and no need to restart readiness from zero when the rule changes.