Start with the status, because most of what is being written about this gets it wrong.
The proposed overhaul of the HIPAA Security Rule was published in the Federal Register on 6 January 2025, with comments closing on 7 March 2025. OCR received 4,745 of them. No final rule has been issued. A January 2025 executive order paused agency rulemaking, the Unified Agenda target has slipped from May 2026 to a reported July 2027, and OCR has signalled it wants to finalise the Privacy Rule update first. Opposition has been organised and heavy: in December 2025 a coalition of more than a hundred hospital systems and provider associations, led by CHIME and including Cleveland Clinic, Yale New Haven Health System and Advocate Health, asked the Secretary to withdraw it outright. HHS itself estimated first-year compliance costs of around 9.3 billion dollars and roughly 34 billion over five years.
So anything presenting this as a final rule with a deadline is wrong. It is a proposal that is overdue, contested, and may be substantially changed or shelved.
That does not make it irrelevant. It makes the question more interesting than a compliance date would. The proposal is the clearest statement available of what regulators think adequate security looks like, and it would give regulated entities a reported 240 days to comply once final. Several of the things it asks for take longer than 240 days to build. So the real question is not when to comply. It is which of these to build before anyone makes you, and which to leave alone until the shape is fixed.
Key takeaways
The rewrite is a proposal, not a rule. It is past its target date, heavily opposed, and may change or be withdrawn.
Its single most consequential change is the removal of the addressable versus required distinction, which has been doing more work than most organisations realise.
Three of the proposed requirements are worth building now because they are defensible on their own merits and take longer than the compliance window allows.
Three are worth leaving until the text is final, because what would change is a specific interval or artefact rather than a capability.
The decision rule is lead time against 240 days, not likelihood of the rule passing.
Why "addressable" is the whole story
The Security Rule has always split its implementation specifications into two kinds. Required ones must be implemented. Addressable ones must be assessed, and if an entity decides a specification is not reasonable and appropriate for its circumstances, it may document that decision and implement an equivalent alternative measure, or nothing, if it can justify that.
Encryption of electronic protected health information is addressable. So, in practice, are several of the controls most people assume are mandatory.
Addressable was never meant to mean optional. It has often functioned that way, because the alternative to implementing a control is writing a paragraph explaining why you did not, and a paragraph is cheaper than a project. Over two decades that has produced a large installed base of unencrypted systems backed by documented justifications, many of them written once and never revisited.
The proposal would remove the distinction. All implementation specifications would have to be implemented, with limited exceptions. That single change is worth more than the rest of the proposal combined, because it converts a documentation exercise into an engineering programme at a stroke. Every justification written over twenty years becomes a gap.
It is also the reason the opposition is as organised as it is. The cost estimate attached to this rule is not about any one control. It is about an entire sector's accumulated addressable decisions coming due at once.
What changes, item by item
Current position on the left, proposal on the right. Intervals are as the proposal states them.
AreaSecurity Rule todayAs proposedImplementation specificationsSplit into required and addressableAll required, with limited exceptionsAsset inventory and network mapNot explicitly requiredRequired, reviewed and updated at least every 12 monthsEncryption of ePHIAddressable, at rest and in transitRequired at rest and in transit, with limited exceptionsMulti-factor authenticationNot explicitly requiredRequired for access to ePHI, with limited exceptionsVulnerability scanningNot explicitly requiredAt least every 6 monthsPenetration testingNot explicitly requiredAt least every 12 monthsData restorationGeneral contingency planningWritten procedures to restore within 72 hours, prioritised by criticalityInternal compliance auditPeriodic evaluation, undefinedAt least every 12 monthsBusiness associate assurancesContractual assurancesVerification of safeguards at least every 12 months
Read down the right-hand column and the pattern is clear. The proposal replaces judgement with intervals. Almost every item that was previously a matter of reasonable and appropriate assessment becomes a thing you do on a clock and can be asked to evidence.
Three worth building now
The test is not whether the rule will pass. It is whether the item is defensible on its own merits and whether its lead time exceeds 240 days. Three pass both.
The asset inventory and network map. This is the one to start today, and it is arguably already required indirectly, because a risk analysis that does not know where electronic protected health information lives is not a risk analysis. It is also the longest job on the list by a wide margin. In any organisation of reasonable age, finding every system, integration, backup, log store, analytics copy and vendor-hosted environment that touches ePHI takes months and turns up things nobody remembered. Nothing else on this list can be done properly without it, which makes it the dependency for the whole programme. The discovery work it produces usually belongs in the same place as the rest of a healthcare data analytics platform, because an inventory that is not queryable goes stale the week after it is finished.
Multi-factor authentication. Cheap, well understood, and the single highest-value control on the list against the breach patterns that actually occur. There is no serious argument for not doing it on general principles. The work that takes time is not the rollout but the discovery: finding the legacy systems, service accounts, integration credentials and clinical workstations where it cannot be applied without breaking something. That list takes longer to produce than most teams expect, and you want it before a clock starts rather than during one. Patient-facing surfaces are usually the easiest place to begin, and authentication design there is part of patient portal software development regardless of what the rule ends up saying.
The encryption exception list. Not encryption itself, which most organisations have largely done for the obvious paths. The thing to build now is the enumerated list of places where you cannot encrypt and the reason in each case. Legacy clinical systems, embedded devices, certain backup formats, log and telemetry stores, and anything a vendor controls. Under today's rule that list is a set of addressable justifications. Under the proposal it becomes the set of limited exceptions you would need to defend. Either way it is the same list, it is genuinely hard to compile, and the places it surfaces are the places where custom EMR and EHR software development work tends to find its real constraints.
All three share a property. They are discovery work rather than control implementation, their output is useful immediately, and none of it is wasted if the rule is withdrawn.
Three worth leaving
The scanning and testing cadence. Vulnerability scanning and penetration testing are worth doing on risk grounds and most organisations already do both. What the proposal adds is a specific interval, six months and twelve months respectively. Intervals are exactly the kind of detail that moves between a proposal and a final rule. Run the programme on a schedule your own risk analysis supports, and do not sign a multi-year testing contract priced against an interval that may not survive.
The annual internal audit as a formal artefact. A documented, repeatable internal compliance audit is a few weeks of work to stand up once you know what it has to cover, and what it has to cover is precisely what would change. Build the capability to evidence your controls, which the inventory gives you anyway, and leave the audit template until there is a text to write it against.
Wholesale business associate re-verification. The proposal would require verifying business associates' safeguards at least every twelve months, which for most organisations means reopening a large vendor estate. It is also among the most opposed provisions, and the one where a final rule is most likely to land somewhere softer. Opening every contract now, against language that may change, is expensive and hard to undo. The proportionate move is to handle the highest-risk vendors at natural renewal points and leave the rest.
One thing in this group is free and worth doing immediately regardless: measure how long a restoration actually takes you today. Not the documented procedure, the real elapsed time. That number is useful information whatever the rule says, and if it is well outside 72 hours you have learned something important at no cost.
The number that should shape the plan
If a final rule issues, the reported compliance period is 240 days. Treat that as the planning constraint rather than the uncertain publication date.
Two hundred and forty days is comfortable for implementing a control and uncomfortable for discovering what you have. An organisation that already knows where its ePHI lives, which systems cannot take MFA, and where encryption is not currently possible can make almost any version of this rule inside the window. An organisation starting its inventory on the day the rule drops cannot, and will spend the window doing archaeology instead of engineering.
That asymmetry is the argument, and it holds even for people who think the rule will never land. The discovery work is the part that takes longer than the window and the part that is useful anyway.
None of this is legal or compliance advice. It is engineering guidance on a pending proposal, and determinations about any specific obligation belong with counsel and your compliance function. At Woltrio we treat this as a data discovery and architecture question rather than a documentation exercise, which is where our healthcare software development services start on anything where the answer depends on knowing what you actually have.