Article 2 of 12 | HIPAA Security Readiness: A 12-Month Roadmap for Healthcare Organizations
From Addressable to Required: How the Proposed HIPAA Security Rule Would Change the Standard
The issue
There is one word in the current HIPAA Security Rule that has created more confusion than almost any other:
Addressable.
For years, healthcare organizations have encountered Security Rule requirements labeled either “required” or “addressable.” It is easy to see how the second category came to be interpreted as optional.
But “addressable” has never meant “optional.”
Under the current HIPAA Security Rule, an addressable implementation specification requires an organization to determine whether the safeguard is reasonable and appropriate for its environment. If it is, the organization must implement it. If it is not, the organization must document why and, when reasonable and appropriate, implement an equivalent alternative measure.
The proposed HIPAA Security Rule would fundamentally change that framework. HHS has proposed eliminating the distinction between “required” and “addressable” implementation specifications and making implementation specifications mandatory, with limited exceptions.
That may sound like a technical change in regulatory language, but operationally it is much more significant.
What “addressable” actually means today
The current Security Rule was intentionally designed to accommodate healthcare organizations of dramatically different sizes and capabilities.
A small physician practice does not have the same infrastructure as a regional health system. HIPAA therefore allows regulated entities flexibility in determining how certain safeguards should be implemented based on factors such as their size, complexity, technical infrastructure, costs, and risks to ePHI.
For an addressable implementation specification, the process is essentially:
- Evaluate the safeguard.
- Determine whether it is reasonable and appropriate based on your environment and risk analysis.
- Implement it if it is reasonable and appropriate.
- If it is not reasonable and appropriate, document why and implement an equivalent alternative measure when reasonable and appropriate.
That last part matters.
A healthcare organization cannot simply see “addressable,” decide not to implement the safeguard, and move on.
The decision itself is part of the compliance process, and HHS says that decision should be documented in writing, including the factors considered and the risk assessment supporting it.
Encryption is a good example
Under the current Security Rule, encryption is an addressable implementation specification. That does not mean organizations can simply choose whether they want it.
They must evaluate whether encryption is a reasonable and appropriate safeguard for protecting their ePHI. If it is, they must implement it. If they determine it is not reasonable and appropriate, they must document that decision and consider an equivalent alternative measure.
Twenty years ago, that flexibility was easier to understand. Technology capabilities, costs, and available infrastructure varied dramatically between healthcare organizations.
Today, technologies such as full-disk encryption, encrypted cloud platforms, secure communications, and multifactor authentication are far more accessible.
That evolution is an important part of what HHS is addressing with the proposed rule.
What the proposed rule would change
The January 2025 Notice of Proposed Rulemaking proposes eliminating the distinction between “required” and “addressable” implementation specifications.
Instead, implementation specifications would generally become required, with limited exceptions specifically identified in the regulation. HHS also proposes much greater specificity about how regulated entities must implement and document their security programs.
Among the proposed requirements are:
- Encryption and multifactor authentication, with limited exceptions
- Technology asset inventories, network maps, and network segmentation
- Vulnerability scanning and annual penetration testing
- Secure configuration, monitoring, backup, and recovery controls
- More specific written risk analyses and risk-management plans
- Annual testing and Security Rule compliance audits
The important change is not simply that the proposed rule contains more requirements. It would significantly reduce the amount of discretion organizations have in deciding whether certain cybersecurity safeguards should be implemented at all.
HHS is moving toward a model in which more of the baseline is explicitly defined.
Why is HHS proposing this change?
The technology landscape has changed significantly since the original Security Rule was developed, and so has the threat landscape.
In explaining the proposed modifications, HHS pointed to increasing cyberattacks, significant growth in healthcare breaches, common deficiencies found during OCR investigations, and the evolution of cybersecurity best practices. HHS said the proposed changes are intended to provide more specific direction about what regulated entities must do to protect ePHI and better align the Security Rule with modern cybersecurity practices.
That is an important distinction. The proposed rule is not simply a list of new technologies the government wants healthcare organizations to purchase.
It reflects a broader change in expectations about what constitutes a reasonable cybersecurity program in today’s environment.
What this looks like inside a healthcare organization
Consider a healthcare organization with 25 employees.
It uses a cloud-based electronic health record, Microsoft 365 for email, several laptops, clinical workstations, a firewall, wireless networks, remote access, cloud applications, and several outside vendors with access to its systems or data.
Under today’s rule, the organization may encounter an addressable implementation specification and ask:
Is this safeguard reasonable and appropriate for our particular environment?
Under the proposed framework, that conversation increasingly becomes:
How are we going to implement this safeguard, and how will we document that it is working?
That is a meaningful shift. It changes cybersecurity planning from repeatedly deciding whether certain protections are necessary toward determining how required protections will be implemented, maintained, tested, and documented.
For organizations with mature security programs, the change may be manageable.
For organizations that have historically relied heavily on the flexibility of the current rule, the gap could be considerably larger.
Current enforcement isn’t waiting for the proposed rule
There is another reason not to treat the proposed changes as a concern to address only when a final rule arrives: OCR is actively enforcing the Security Rule that exists today.
In April 2026, OCR announced settlements with four organizations following separate ransomware investigations that together affected more than 427,000 individuals. Across the four investigations, OCR repeatedly identified failures involving accurate and thorough risk analysis, a deficiency that continues to feature prominently in Security Rule enforcement. OCR’s director noted that implementing the Security Rule before a breach or investigation is not only the law but a regulated entity’s best opportunity to prevent or reduce the harm of a cyberattack.
Each of those settlements involved deficiencies in areas the current Security Rule already requires organizations to address. The flexibility of today’s framework did not shield them from accountability.
Even under today’s risk-based framework, organizations must understand their environment, identify risks, make defensible security decisions, implement appropriate safeguards, and retain evidence of those decisions.
Four actions to take this month
1. Identify where you are relying on “addressable”
Ask whoever manages your HIPAA security program to identify which addressable implementation specifications have not been implemented exactly as written. You should be able to see what decisions were made and why.
2. Review the documentation supporting those decisions
If an addressable safeguard was not implemented, locate the written analysis explaining why it was not reasonable and appropriate and what alternative protection was selected. If that documentation does not exist, that is a current compliance concern, not merely a future one.
3. Revisit older decisions
A security decision that was reasonable five years ago may not be reasonable today. Technology, costs, threats, and your organization all change. A documented decision should not become a permanent exemption simply because nobody has revisited it. The question isn’t simply whether an exception was documented. It’s whether that decision would still be reasonable and defensible if OCR reviewed it today.
4. Ask a different question about the proposed rule
Instead of asking:
“Which of these requirements can we avoid?”
Ask:
“Which proposed requirements would be difficult for us to implement today?”
That produces a much more useful readiness list. It identifies projects that may require budgeting, infrastructure changes, vendor cooperation, replacement of legacy systems, or significant implementation time.
Evidence to retain
For every addressable implementation specification your organization evaluates, documentation should make the reasoning understandable to someone who was not involved in the original decision. That documentation may include:
- The safeguard evaluated
- The systems or ePHI involved
- The risks considered
- Whether the safeguard was considered reasonable and appropriate
- The basis for that determination
- Any alternative security measure selected
- Who approved the decision
- The date of the evaluation
- When the decision should be reviewed again
This documentation is valuable for more than regulatory compliance; it creates institutional memory.
If an IT provider changes, an administrator leaves, or leadership turns over, the next person can understand why a security decision was made instead of starting over.
How Solid approaches this
Our approach is to treat “addressable” as a risk-management decision, not a loophole.
Solid’s managed security standard establishes a defined cybersecurity baseline for managed environments while documenting client-specific risks, exceptions, and remediation requirements.
As we prepare for the direction of the proposed Security Rule, our goal is not simply to check whether a control exists. We want to know whether it is deployed appropriately, monitored, maintained, tested when applicable, and supported by documentation.
That approach helps clients strengthen their security posture under today’s Security Rule while reducing the number of major projects that could remain if the proposed requirements are ultimately finalized.
At a glance
| Current HIPAA Security Rule | Proposed Rule (Jan 2025 NPRM) | Solid Managed Standard | |
|---|---|---|---|
| Implementation specifications | Required or addressable | Generally required, with limited exceptions | Defined baseline controls |
| Addressable safeguards | Must be evaluated and implemented when reasonable and appropriate, or the decision and alternatives documented | Required/addressable distinction would be removed | Exceptions treated as documented risk-management decisions |
| Flexibility | Risk-based flexibility based on organizational circumstances and documented analysis | More specific implementation expectations | Standardized baseline with documented client-specific exceptions |
| Documentation | Decisions involving addressable safeguards must be documented | Written documentation requirements would become more specific | Security documentation maintained through defined client deliverables |
| Compliance status | In effect today | Not final | Current standards plus readiness for proposed changes |
Regulatory status
As of August 2026: The proposed modifications to the HIPAA Security Rule remain a Notice of Proposed Rulemaking. The federal regulatory agenda currently projects final action in July 2027 and has placed the rulemaking on its long-term actions list, but that projection is not binding and may change.
The current HIPAA Security Rule remains fully in effect and enforceable.
Where this series goes next
Understanding your security obligations is only useful if you know where your ePHI lives, how it moves, and which systems and vendors can access it.
Next month, we’ll look at technology asset inventories, network maps, vendors, and ePHI data flows, including why an inventory needs to cover far more than computers and servers.
Follow the complete series: Visit our HIPAA Security Readiness resource page to read previous articles and follow the 12-month roadmap, or subscribe by email to receive each new article.
This article discusses proposed modifications to the HIPAA Security Rule published as a Notice of Proposed Rulemaking on January 6, 2025. The proposals have not been finalized and may change. This content is provided for educational purposes and does not constitute legal advice.
