HIPAA Security Rule: The Rewrite That Ends “Addressable”
The HIPAA Security Rule has not had a substantial update since 2013, but that is about to change. In December 2024, the HHS Office for Civil Rights proposed a rewrite, and it was published in the Federal Register in January 2025.
Most coverage of the proposal is cybersecurity basics: encryption, multifactor authentication, asset inventories, penetration testing. The lists are accurate, and they are easy to skim past.
Another change is getting less attention. One word is coming out of the rule: “addressable.” For two decades, it has shaped how healthcare organizations decide which safeguards to put in place and which to defer.
Removing it changes what a document already sitting in a practice’s files now says about that practice.
Get a better view of the security risks posed to your organization: The Security Gap Many Businesses Don’t Know They Have
What “Addressable” Has Meant Until Now
The current Security Rule sorts every implementation specification into two groups: required and addressable. A required specification is straightforward: the organization has to implement it.
Addressable works differently, and it does not mean optional. The rule asks the organization to assess whether the safeguard is reasonable and appropriate for its environment. From there, it has a few routes:
- Implement the specification as written.
- Implement an equivalent alternative measure and document why.
- Document why the specification is not reasonable and appropriate, and put nothing else in place if that decision holds up.
That third route is where things drift. In day-to-day practice, addressable started to function as a way out. A practice could write a short justification for skipping a safeguard such as encryption or MFA, file it, and move on.
The effect was uneven protection. Two practices of similar size could land in very different security postures while both counted as compliant, based on what each one chose to document.
What the Proposed HIPAA Rewrite Changes
The proposed rule removes the required-versus-addressable split. Almost every implementation specification becomes required, with a small set of narrow exceptions.
Flexibility in how a control gets implemented stays, while the choice about whether to implement it goes away.
The safeguards that have most often been treated as addressable would move to expected:
- Encryption of ePHI at rest and in transit
- Multifactor authentication for systems that access ePHI
- A current technology asset inventory and a network map, reviewed on a set schedule
- A written risk analysis with a defined scope
- Vulnerability scanning and scheduled penetration testing
- An incident response and recovery plan with defined restoration targets
A point on timing, because it matters for how a practice should read all of this. The rewrite is a proposal, and the public comment period closed in March 2025. HHS has stated that the current Security Rule stays in effect and enforceable while the agency works toward a final rule.
So while the direction is set and visible, the date is not. The sensible way to treat the proposal is as a planning signal rather than a live deadline.
Had a narrow miss recently? Take advantage of it: The Cyber Incident Near-Miss as a Free Cybersecurity Audit
Why an Old Risk Analysis Now Works Against You
The risk analysis is the document everything else rests on. It has been required for years, but an older one can turn into a liability in two ways.
Documented Decisions Become Records of Known Gaps
Under the addressable framework, a practice that skipped encryption or MFA was supposed to write down why. That reasoning lives in or beside the risk analysis.
Once those safeguards are required, the same paperwork reads as a dated record showing the practice identified the risk and decided not to close it. A written decision to defer a control is harder to defend than an unexamined gap.
Analyses Don’t Match the Environment
A risk analysis captures the systems in place on the day it was written. Over a few years, a practice adds cloud applications, remote access, new devices, and new vendors that touch ePHI.
The proposal’s inventory and network-map expectations bring that drift into view. An analysis from several years ago may say nothing about systems that hold patient data today, which leaves a visible gap between what was assessed and what is now running.
Enforcement is Pointed Here
OCR’s 2024 Risk Analysis Initiative was aimed squarely at organizations that failed to conduct an accurate and thorough risk analysis.
By March 2026, the initiative had produced more than a dozen settlements, each pairing a financial penalty with a multi-year corrective action plan. Every one of those actions happened under the current rule.
Here’s the practical read: the date and scope of the existing risk analysis are worth checking first. If it contains a section explaining why encryption or MFA was set aside, that section is the place to look before anything else.
What Changes in Daily Healthcare Operations
The requirements land on specific systems and routines. Here is what each one asks for in practical terms, based on the HHS fact sheet.
Encryption: This covers ePHI wherever it rests and wherever it moves. Think laptop drives, server databases, backups, and email that carries patient information. The proposal also asks organizations to review and test their encryption on a set schedule.
Multifactor authentication: MFA applies to the systems that reach ePHI. The usual starting points are EHR logins, remote access, email, and administrator accounts.
Asset inventory and network map: This means a written, current list of the hardware and software that create, receive, store, or transmit ePHI, kept next to a map of how that data moves across the network. Both get reviewed at regular intervals.
Vulnerability scanning and penetration testing: Scheduled scans paired with a documented penetration test, with the results written down.
Incident response and recovery: A written plan with a target for getting systems back after an outage or attack. The proposal puts that target at 72 hours for certain systems.
Most of this touches work that already happens in some form. The change under the proposal is that each item needs evidence showing it was done and kept current.
Successful cyberattacks must be reported, but many businesses aren’t aware that unsuccessful attacks need to be explained as well: Reporting Cyber Incidents: When a Near-Miss Still Counts
Who Owns the Security Decisions?
In a lot of mid-market healthcare practices, the title of “security manager” gets assigned to an office manager or a practice administrator who carries a dozen other responsibilities, or it gets shared informally with whoever keeps the technology running.
The gap tends to open where accountability is fuzzy. When the specifications move from optional in practice to required, the ownership questions get sharper.
Each of these needs a clear answer:
- Who signs off on the risk analysis and keeps its scope current?
- Who maintains the asset inventory and the network map?
- Who enforces MFA across every system that reaches ePHI?
- Who schedules the scans and the penetration test?
- Who holds the documentation a reviewer would ask to see?
These do not all have to sit with one person. What matters is that each has an owner, and that the owners know where their work connects.
Get Ahead of the Final HIPAA Security Rule
The move away from “addressable” rewards practices that treat the risk analysis as a living record. The organizations in the strongest position are the ones that can already show a current inventory and point to a named owner for every safeguard. None of it depends on a final rule, which means the groundwork is reachable now.
Louisville Geek works inside regulated healthcare environments every day. We keep the risk analysis current and the safeguards documented, so a practice can walk into its next risk assessment ready rather than scrambling.
If the proposal has you looking at an aging risk analysis and wondering who owns the exposed gaps, that’s worth a conversation now.
