.svg)
This page covers a rulemaking still in progress. Check the current status before relying on it for compliance decisions.
There is a lot of confused writing about the HIPAA Security Rule right now, much of it describing proposed requirements as though they were already law. That confusion is worth clearing up, because acting on proposed text as if it were final is its own kind of compliance risk.
What Is Actually in Force Today
The HIPAA Security Rule as currently in effect requires a risk analysis under 45 CFR 164.308(a)(1)(ii)(A) and periodic technical and non-technical evaluation under 164.308(a)(8). It does not name penetration testing. It does not set a testing schedule. It does not mandate encryption outright — encryption is an addressable implementation specification.
That is the standard you are measured against right now.
What HHS Has Proposed
On December 27, 2024, HHS issued a Notice of Proposed Rulemaking to modernise the Security Rule, published in the Federal Register in January 2025. It is the most significant proposed update since 2013. The comment period closed in March 2025.
The main proposed changes:
- Removal of the required/addressable distinction — nearly all specifications would become mandatory
- Mandatory encryption of ePHI at rest and in transit, with limited exceptions
- Mandatory multi-factor authentication for systems accessing ePHI, with limited exceptions
- Vulnerability scanning at least every six months
- Penetration testing at least every twelve months, or more frequently where your risk analysis indicates, performed by a qualified person
- Defined contingency timelines, including notification on contingency plan activation and a window for data restoration
- Asset inventory and network mapping requirements
Where It Stands
It remains a proposed rule. HHS has stated the current Security Rule remains in effect while rulemaking continues. A final rule has been anticipated at various points and the schedule has moved; the proposal contemplated a compliance window beginning after a final rule takes effect, rather than immediately on publication.
Final rule text can also differ from proposed text. Definitions of qualified personnel, testing cadence expectations, and any accommodations for smaller organisations are all things that can shift between NPRM and final rule.
The practical position: prepare for it, do not cite it as current law. A compliance vendor or internal document telling you that annual penetration testing is a present legal mandate under HIPAA is overstating the position.
Why Preparing Now Is Still the Right Call
Two reasons, independent of whether the rule finalises as drafted.
First, most of what is proposed is already good practice, and several items map to what OCR already expects. Penetration testing already serves as the strongest available evidence for the 164.308(a)(8) evaluation requirement. Encryption already provides safe harbour from breach notification obligations. MFA already prevents the credential attacks behind a large share of healthcare breaches.
Second, the proposed compliance window is short relative to the work. Deploying MFA across clinical systems, encrypting legacy data stores, and building an asset inventory are multi-quarter projects. An organisation starting on the day a final rule publishes is starting late.
What to Do Now
Build the asset inventory and network map. Useful immediately, required under the proposal, and a prerequisite for everything else.
Close encryption gaps. Identify where ePHI sits unencrypted and plan remediation now rather than under a deadline.
Map MFA coverage. Find the systems that access ePHI without it. Legacy clinical applications are usually the hard cases and need the most lead time.
Establish a testing cadence. Semi-annual scanning and annual penetration testing align with the proposal and strengthen your current evaluation evidence regardless.
Document your reasoning. Whatever cadence you set, the Rule as it stands expects you to justify it through your risk analysis.
How to Read Coverage of This
A lot of writing about the NPRM blurs the line between proposed and current. Some of it is careless; some is vendors using regulatory uncertainty as a sales lever.
Signals that a source is being careless: describing the requirements as already in force, giving a confident compliance deadline, or omitting the word “proposed” entirely. Signals a source is reliable: stating the NPRM date and Federal Register publication, noting that the current Rule remains in effect, and distinguishing what is proposed from what is required.
This matters practically. If you build an internal compliance narrative on the premise that annual testing is already mandated, and leadership later learns it was proposed, you lose credibility on the next thing you tell them is required.
What Would Be Hardest to Implement
If the rule finalises broadly as drafted, effort will not be evenly distributed.
MFA on legacy clinical systems is the hardest item for most healthcare organisations. Older clinical applications frequently do not support modern authentication, and the answer is vendor upgrades, compensating architecture, or replacement — none of which is fast.
Encryption of legacy data stores ranks second. Encrypting new systems is straightforward; encrypting a decade of accumulated data across systems still in clinical use is a project with real operational risk.
Asset inventory and network mapping sounds administrative and is often the slowest to complete accurately, because it depends on information distributed across teams that do not currently maintain it centrally.
Testing cadence, by contrast, is comparatively easy to adopt — it is a procurement and scheduling decision rather than an engineering programme.
A Reasonable Position to Take Internally
If you need to brief leadership, the defensible framing is roughly this: the current Security Rule requires a risk analysis and periodic evaluation, and we are measured against that today. HHS has proposed a significant update that would add explicit encryption, MFA, and testing requirements. It is not final and the timing is uncertain. The proposed changes are consistent with good practice and several would take multiple quarters to implement, so we are prioritising them now rather than waiting.
That framing is accurate, does not overstate the mandate, and still supports the budget request. It also survives the rule being delayed again, which the previous schedule suggests is possible.
Get Ahead of It
Our HIPAA security risk assessment evaluates you against the Security Rule as it stands today, and flags where the proposed changes would create new gaps — so you can plan remediation on your schedule rather than a regulatory one.
See also our HIPAA compliance checklist and guide to HIPAA penetration testing.