Imagine using a dial-up modem to stream a 4k movie. This is an antiquated method and would take days of buffering to watch a single movie, which sounds absurd to do in a day with modern high-speed internet. Along those same lines, would you expect HIPAA Security Rule specifications, which were designed over two decades ago, to stay the same to address today’s sophisticated threats? Likely not. The IT landscape and cyber threats have evolved drastically over the last two decades.
To address this, the U.S. Department of Health and Human Services (HHS), through its Office for Civil Rights (OCR), has proposed an update to the HIPAA Security Rule to force healthcare organizations to modernize their IT security defenses at a time when healthcare cyberattacks are at an all-time high.
What Is the HIPAA Security Rule?
Compliance with the requirements of the HIPAA Security Rule starts with understanding how it is constructed. The HIPAA Security Rule consists of standards and implementation specifications.
Per HIPAA Security Safeguards: Each Security Rule standard is a requirement: a covered entity and its business associates must comply with all of the standards of the HIPAA Security Rule with respect to the electronic protected health information (ePHI) it creates, transmits, or maintains.
Many of the HIPAA Security Rule standards contain implementation specifications. An implementation specification is a more detailed description of the method or approach organizations can use to meet the requirements of a particular standard.
What Are the Three HIPAA Security Rule Categories?
The HIPAA Security Rule is comprised of three safeguards:
- Administrative Safeguards: These include organization-wide activities such as policies and procedures, risk mitigation, employee training, and HIPAA contingency plans.
- Physical Safeguards: These safeguards are related to physical components such as locked facility doors, data center cameras, workstations, and employees’ remote devices.
- Technical Safeguards: As the name suggests, these include more technical protections of ePHI such as encryption or access controls.
Timeline of the HIPAA Security Rule
Since the original HIPAA Security Rule was finalized in 2003 and its last major update in 2013, the IT landscape has evolved. This includes an increase in the maturity of cyberattacks, ransomware, remote working, AI, and cloud computing. As such, on December 27, 2024, HHS issued a HIPAA Security Rule Notice of Proposed Rulemaking (NPRM) to address the ever-evolving IT environment and the increase in healthcare cyberattacks.
The proposed rule initially targeted a May 2026 finalization date. However, due to concerns and pushback over cost and timelines, that targeted finalization window has passed. It is important to note that this is still a proposed rule and is not yet legally binding. Once the rule is finalized, organizations will have 180 days to implement.
What Are the HIPAA Security Rule Changes & What Are Auditors Seeing?
The following details the proposed HIPAA Security Rule changes and what auditors have been seeing in the field.
Addressable vs. Required: Why the Distinction Is Disappearing
The most significant of the proposed changes is the elimination of the “addressable vs required” categories. A required implementation specification is exactly that: required. In that regard, required implementation specifications are similar to standards. An organization must comply with required implementation specifications, and failure to do so is an automatic failure to comply with the HIPAA Security Rule.
With the addressable category, the organization could assess whether the security safeguard is reasonable and appropriate to the organization’s environment. It is important to note that addressable does not mean optional. An organization must perform one of the following actions, with documentation evidencing their assessment and factors considered to support their decision (source from HIPAA Security):
- Implement the addressable implementation specification.
- Implement an equivalent alternative measure(s) that allows the entity to comply with the standard.
- Not implement the addressable implementation specification or any alternative measures, if equivalent measures are not reasonable and appropriate within its environment.
The proposed rule eliminates the addressable category and makes all specifications required. Organizations that have leaned on the addressable category to defer certain controls will need to implement them. The specifications establish the floor and not the ceiling. Organizations still have the flexibility to determine the scale and methods used to achieve the specifications. However, keep in mind that with the elimination of the addressable category, the ‘reasonable and appropriate’ flexibility is significantly narrowed.
What Auditors are Seeing: Many organizations have the addressable controls implemented as they generally strive for alignment with standard security practices, e.g., NIST Cybersecurity Framework (CSF). However, the elimination of the addressable category could be a big lift for organizations that have heavily relied on this category with the rationale of size, cost, location, etc. Organizations with legacy systems that cannot address the technical requirements may find the required specifications timely and costly.
Technical Mandates: From Highly Recommended to Strictly Required
The following requirements are not new to the HIPAA Security Rule, but some of the wording is ambiguous as to what exactly is needed and in what timeframes. The proposed rule clarifies the expectations.
Encryption
The addressable category for encryption will be eliminated, and the specification will be required for all ePHI data in transit and at rest.
What Auditors are Seeing: Many organizations have this in place as it is a standard security requirement across many IT security frameworks, whether explicitly stated or implied. Where we see this being a bigger lift is for legacy systems that don’t support modern encryption.
Multi-Factor Authentication (MFA)
Currently, requirement §164.312(d) states, “Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.” Although this is currently a “required” specification, it does not specifically call out MFA. The proposed rule explicitly states that MFA is required.
What Auditors are Seeing: MFA is typically enabled in organizations’ most critical system(s) (e.g., cloud infrastructure, source code tool), but is overlooked in ancillary or homegrown systems that touch ePHI. The network mapping item below helps identify these systems. Similar to encryption above, we see this being a bigger lift for organizations with legacy systems that don’t support MFA.
Asset Inventory & Network Mapping
A comprehensive asset inventory and network mapping tracking the flow of ePHI through all hardware and software must be documented, reviewed, and updated on an annual basis, at a minimum.
What Auditors are Seeing: Asset inventories are typically available; however, the flow of ePHI is not always mapped out to every ancillary system it touches.
Risk Assessments & Testing
Risk assessments have always been required, but the frequency was left up to the organization’s discretion. The requirement will shift from “periodic” assessments to explicit testing timelines including annual formal compliance audits, automated vulnerability scans at least every six months, and third-party penetration tests at least once a year. Evidence that the organization is addressing the findings as needed must be made available.
What Auditors are Seeing: Organizations typically have some form of this specification in place, but some may need to enhance their efforts and tighten up documentation to clearly evidence the frequency and remediation efforts of the findings.
Contingency Plans & Incidents
Organizations will have to demonstrate the ability to restore critical systems and recover ePHI data within 72 hours of an incident. Annual testing of contingency plans is required.
What Auditors are Seeing: Organizations have a disaster recovery and contingency plan in place, typically meeting the 72-hour Recovery Time Objective (RTO) for their most critical systems. Annual testing is typically performed.
Business Associate Rules
Blanket compliance statements in Business Associate Agreements (BAAs) will no longer be acceptable. BAAs will need to have expanded obligations and more accountability for the business associate, including incident notification to covered entities no later than 24 hours after activation of their contingency plan. Additionally, the BAAs will need to be reviewed at least annually, with documentation evidencing the review.
What Auditors are Seeing: Passive blanket BAAs in place that are signed upon third-party onboarding and remain effective throughout the duration of the business relationship without revisiting. This will likely be an action item for most healthcare organizations to comply with the specification.
The proposed rule is catching up to what auditors are already flagging. These updates are not only about avoiding massive OCR penalties, but also about tightening organizations’ security posture against modern risks. OCR enforcement has already been citing deficiencies the proposed rule would codify.
HIPAA Security Rule Changes
| Component | Current Status | Proposed Changes |
|---|---|---|
| Encryption | Addressable | Required. All ePHI data in transit and at rest must be encrypted. |
| MFA | Ambiguous wording in a required specification | Explicitly states that MFA is required for all systems that touch ePHI. |
| Asset Inventory & Network Mapping | Ambiguous wording | Explicitly states a comprehensive mapping of all systems that touch ePHI is required. |
| Risk Assessments & Testing | Ambiguous and flexible wording as to the types and frequency | Mandates types of assessments and explicitly states frequencies. |
| Contingency Plans & Incidents | Ambiguous restore timing, testing addressable | Ability to restore ePHI data within 72 hours after a disruption or cyber event. Annual testing is required. |
| Business Associate Rules | Broad BAAs that do not require reviews after execution during onboarding | BAAs with expanded obligations and accountability explicitly documented. Reviews and verifications performed at least annually. |
What to Do In the Meantime
Given the 180-day implementation timeline once the rule is finalized and without knowing exactly when the rule will become final, organizations may wonder what they could do now to prepare.
- Perform a HIPAA gap assessment to identify “addressable” controls that need to be implemented.
- Update asset inventories and network mapping. An organization should know exactly where its ePHI is flowing.
- Inventory all business associates. Prepare to have an updated BAA with each and allot time for future annual reviews. Start the conversations with vendors on how they support encryption and MFA requirements.
- Budget time and cost for technical gaps (encryption, MFA, vulnerability scans, penetration testing)
Once the rule becomes issued and final, healthcare organizations will have 180 days to implement the controls. While you don’t want to put the cart before the horse, it’s best to get ahead in the areas you know will inevitably become final, as you don’t want to be left with a short runway to implement.
Frequently Asked Questions About the HIPAA Security Rule
The HIPAA Security Rule raises a few recurring questions we hear from clients. Here’s a quick rundown of the ones we haven’t already covered.
What’s the Difference Between the HIPAA Privacy Rule & the Security Rule?
The HIPAA Privacy Rule covers PHI in any format (verbal, paper, electronic) and governs when and why PHI can be disclosed or used. The HIPAA Security Rule covers how ePHI (electronic format only) is protected.
Who Is Exempt from the HIPAA Security Rule?
All covered entities or business associates that create, store, and transmit ePHI must comply with the HIPAA Security Rule. Organizations that operate only on paper (and never handled ePHI) are exempt from the HIPAA Security Rule. In this scenario, the organization would still be bound to comply with the HIPAA Privacy Rule and the Breach Notification Rule.
What Are Common HIPAA Security Rule Violations?
Unencrypted and/or inability to track lost devices, weak access controls (e.g., lack of role-based access, use of generic accounts), lack of training, and poor or missing risk analysis are some of the more common violations seen.
Getting Ahead of the Rule: What This Means for Your Organization
With the surge of cybersecurity attacks toward healthcare organizations and the modernization of IT over the past couple of decades, it only makes sense that HHS is updating the HIPAA Security Rule to keep pace with the modern threat landscape. The proposed update is not rewriting security standards; rather, it removes ambiguity and takes what has long been considered “best practice” and makes it explicit. If your organization is already following a modern security framework, the foundation to comply with the proposed updates is already there and may just need a little push to get over the hurdle.
At Linford & Company, we provide HIPAA Compliance audits to assess an organization’s regulatory compliance effectiveness. The typical audit scope includes HIPAA Security and Breach Notification Rules; however, the engagement can be tailored to also include the HIPAA Privacy Rule and other state regulation requirements. If you have any further questions or would like to discuss how Linford and Company can help your organization with HIPAA Compliance or other audit compliance services, please contact us.
This article was originally published on 11/10/2020 and was updated on 7/8/2026.
