Most healthcare security teams have spent close to two years hearing that a major rewrite of the HIPAA Security Rule is on its way, and many have reacted in one of two ways.
Some paused large security investments until the final text appears, on the reasoning that there is no point building to a draft. Others started rewriting policies line by line against the proposal, as though it were already law.
Neither approach holds up well, because the proposal is still unsettled in its details while much of what it describes is work that a regulated organization should be doing under the current rule anyway.
The more useful question is which parts of the proposal are worth acting on now and which parts can safely wait for the final version.
Where the Proposed Security Rule Update Stands Today
The Office for Civil Rights at the Department of Health and Human Services issued its notice of proposed rulemaking in late December 2024, and it was published in the Federal Register on 6 January 2025.
The comment period closed on 7 March 2025, after the department had received thousands of comments, a large share of them from providers and industry groups concerned about cost and implementation timelines.
The rulemaking was originally expected to reach a final rule in May 2026, but the most recent federal regulatory agenda moved it to the long-term actions list and now projects final action no earlier than July 2027.
In the meantime, the existing Security Rule remains fully in force and enforceable. Every covered entity and business associate is still required to conduct an accurate and thorough risk analysis, implement safeguards that address the risks it finds, and document what it has done. That obligation is the starting point for any sensible readiness plan.
What the Proposal Would Change for Regulated Entities
The proposal is the most significant revision of the Security Rule since it was first written, and its central change is structural.
Today, many implementation specifications are labeled addressable, which allows an organization to adopt an alternative measure or document why a specification is not reasonable for its environment. The proposal would remove that distinction and make nearly all specifications required, with only narrow exceptions.
Several new and more specific obligations would follow from that shift. Regulated entities would need written documentation of all security policies, procedures, and analyses, along with a technology asset inventory and a network map showing how electronic protected health information moves through their systems, reviewed at least once every 12 months and whenever the environment changes.
Risk analyses would have to follow a more defined structure. Encryption of ePHI at rest and in transit, multi-factor authentication, and network segmentation would become explicit requirements rather than matters of judgment.
Organizations would need to run vulnerability scans at least every six months and penetration tests at least once a year, keep written procedures for restoring critical systems and data within 72 hours, and complete a compliance audit against the rule every 12 months.
The Work That Makes Sense to Start Now
The strongest candidates for immediate action are the items that improve compliance with the current rule regardless of how the final text reads. The asset inventory and data flow map belong at the top of that list.
A risk analysis is already mandatory, and it cannot be accurate if the organization does not know which systems hold or transmit ePHI, which vendors touch that data, and which connections run between them. Teams that build the inventory now will find their next risk analysis easier to complete and far easier to defend in an audit.
Multi-factor authentication and encryption sit close behind. Both are widely available, both address the attack paths that appear most often in healthcare breach reports, and both are already expected in practice even where the current rule leaves room for judgment.
The same logic applies to backups that are tested rather than assumed, and to a restoration order that ranks systems by how critical they are to patient care and revenue, since that ranking is exactly what a 72-hour recovery target would demand.
The practical difficulty for most organizations is turning a general awareness of the proposal into a specific list of gaps in their own environment.
An outside review through healthcare compliance consulting can map the current risk analysis, policies, and technical controls against both the existing rule and the proposed requirements, then rank the gaps by how much risk each one leaves open. That gives leadership a defensible sequence of work instead of a long and undifferentiated checklist.
Where Cloud Infrastructure Decisions Come in
A noticeable share of the proposal reads less like policy and more like infrastructure design. Network segmentation, encryption of stored data, separate controls for backup and recovery, and a tested ability to bring critical systems back within a fixed window are decisions made in how an environment is built and operated, not in how a policy document is worded.
For organizations that run clinical or claims workloads in the cloud, much of this is easier to build in than to retrofit, because segmentation, key management, and automated backups can be defined as part of the environment itself rather than added around it.
The harder part is keeping those controls in place over time. Patches have to be applied on schedule, segmentation rules drift as new services are added, and a restoration procedure that has not been tested recently offers little assurance.
Whoever operates the environment has to own that routine work, which is why many teams use healthcare cloud managed services to cover patching, monitoring and restore testing continuously, so that evidence of each control exists before anyone asks for it.
Business Associates and the 24-Hour Contingency Notice
The proposal would also change what covered entities can expect from their vendors. Business associates would need to verify at least once every 12 months that they have deployed the required technical safeguards, through a written analysis by a subject matter expert and a written certification.
They would also need to notify the covered entity within 24 hours of activating a contingency plan, which means a vendor outage affecting ePHI could no longer remain quiet for days.
Covered entities do not need to wait for the final rule to raise these points. Contract renewals are a natural moment to ask vendors how they currently document their safeguards, when they last tested their own recovery procedures, and how quickly they would report an incident that affects shared data.
The answers reveal which vendors are already close to the proposed standard and which ones would struggle to meet it.
What to Hold Off on Until the Rule is Final
Some work is better deferred. The exact wording of new requirements, the length of compliance periods, and the scope of exceptions could all change as the department works through the comments it received, and the timing itself has already slipped once.
Rewriting every policy to mirror the draft text risks doing the same work twice, and committing budget to controls that exist only to satisfy a specific proposed clause is hard to justify while that clause may still move.
The more durable approach is to treat the proposal as a description of where expectations are heading rather than a list of deadlines.
Organizations that know where their ePHI lives, protect it with strong authentication and encryption, can restore critical systems quickly, and hold their vendors to clear standards will be in a good position whatever the final rule says.
They will also be in a stronger position under the rule that applies today, which remains the one an auditor or investigator would measure them against.
