As we noted in our previous blog here, on January 6, 2025, the U.S. Department of Health and Human Services (HHS), Office for Civil Rights (OCR) published a Notice of Proposed Rulemaking (NPRM) proposing substantial revisions to the Health Insurance Portability and Accountability Act (HIPAA) Security Rule (45 C.F.R. Parts 160 and 164) (the “Security Rule”).

This NPRM is one of several recent actions taken on the federal level to improve health data security. A redline showing the NPRM’s proposed revisions to the existing Security Rule language is available here. Comments on this NPRM must be submitted to OCR by March 7, 2025. Over 2,800 comments have been submitted thus far. These comments include opposition from several large industry groups raising concerns about the costs of compliance, asserting that the NPRM would impose an undue financial burden without a clear need for such changes to the existing framework. Some commentators expressed concerns regarding the burden on smaller or solo practitioners, while other commentators wrote in support of the effort to improve cybersecurity and commented on suggested alterations to particular elements of the rulemaking. Although the Trump administration has not apparently publicly commented on the NPRM and the final outcome of the rulemaking remains unclear, this Insight details important changes in the NPRM and potential widespread impacts on both covered entities and business associates (collectively, “Regulated Entities”).

The NPRM, if finalized as drafted, establishes new prescriptive cybersecurity and documentation requirements. This represents a significant change for a rule whose hallmark has historically been a flexible approach based upon cybersecurity risk, considering the size and complexity of an organization’s operations. Notably, the background to the NPRM is that the Security Rule already applies to Regulated Entities, including health-related information technology (IT) and artificial intelligence (AI) organizations that process health data on behalf of covered entities. The overall impact of the proposed changes may vary because certain Regulated Entities may already have in place the more robust safeguards prescribed by the NPRM. However, for those Regulated Entities that have not previously taken all such steps, including complying with the enhanced documentation requirements, the burden of the new compliance requirements may be significant.

OCR pointed to several justifications for the proposed revisions to the Security Rule, including:

• the need for strong security standards in the health care industry to improve the efficiency and effectiveness of the health care system;
• the continuous evolution of technology since the Security Rule was last updated in 2013;
• inconsistent and inadequate compliance with the Security Rule among Regulated Entities; and
• the need to strengthen the Security Rule to address changes in the health care environment, including the increasing number of cybersecurity incidents resulting from a proliferation of evolving cyber threats.

Although not discussed in detail by OCR, the growing number of state privacy and data protection laws, risk management frameworks related to data protection, and court decisions have also contributed to the impetus for greater specificity in the Security Rule with its focus on protecting identifiable patient health information.

Notably, many of the substantive requirements in the NPRM are already incorporated in various guidelines and safeguards for protecting sensitive information, such as the National Institute of Standards and Technology (NIST) Cybersecurity Framework and HHS’s cybersecurity performance goals (CPGs). Voluntary compliance with these recognized guidelines has been incentivized pursuant to the Health Information Technology for Economic and Clinical Health (HITECH) Act’s 2021 amendment because a Regulated Entity that adopts “recognized security practices” is entitled to have its adoption considered by OCR in determining fines and other consequences if the agency conducts a review of the Regulated Entity’s HIPAA compliance. Accordingly, OCR noted that these standards and other similar guidelines were considered in the development of the NPRM requirements. Moreover, even if they have already implemented these practices, Regulated Entities will be faced with significantly increased administrative requirements, such as regular review and enhanced documentation requirements.

Key Proposed Changes

The NPRM includes the following key revisions:

New/Updated Definitions Clarify Electronic Systems Within the Rule’s Protections

The NPRM includes 10 new definitions and 15 changed definitions. Some of the new definitions address basic concepts that OCR had not defined previously, including “risk,” “threat,” and “vulnerability.” These definitions are not groundbreaking but will help guide Regulated Entities in establishing a more uniform standard for what they should be evaluating when considering data security.

Another change to the definitions section involves OCR’s proposed updates to defining “information systems” as well as new definitions for “electronic information system” and “relevant electronic information system.” Throughout the NPRM, OCR clarifies when all electronic information systems must abide by a rule versus only the relevant electronic information systems. In effect, each definition narrows the preceding definition, with “relevant information electronic systems” encompassing the smallest group of systems.

The NPRM defines an “electronic information system” as an “interconnected set of electronic information resources under the same direct management control that shares common functionality” and “generally includes technology assets such as hardware, software, electronic media, information and data.” Conversely, “relevant electronic information systems” are only those electronic information systems that create, receive, maintain, or transmit electronic protected health information (ePHI) or that otherwise affect the confidentiality, integrity, or availability of ePHI. The catchall phrasing broadens the definition significantly, requiring Regulated Entities to consider electronic systems they rely on that do not contain any ePHI but may affect access to and/or the confidentiality or integrity of ePHI.

“Addressable” Security Implementation Specifications Would Become “Required”

The Security Rule sets forth three categories of safeguards an organization must address: (1) physical safeguards, (2) technical safeguards, and (3) administrative safeguards. Each set of safeguards comprises a number of standards, and, beyond that, each standard consists of a number of implementation specifications, which is an additional detailed instruction for implementing a particular standard.

Currently, the Security Rule categorizes implementation specifications as either “addressable” (i.e., which give Regulated Entities flexibility in how to approach them) or “required” (i.e., they must be implemented by Regulated Entities). In meeting standards that contain addressable implementation specifications, a Regulated Entity currently has the option to (1) implement the addressable implementation specifications, (2) implement one or more alternative security measures to accomplish the same purpose, or (3) not implement either an addressable implementation specification or an alternative. In any event, the Regulated Entity’s choice and rationale must be documented.

According to the NPRM, OCR has become concerned that Regulated Entities view addressable implementation specifications as optional, thereby reducing the ultimate effectiveness of the Security Rule. The NPRM proposes to remove the distinction between “addressable” and “required” specifications, making all implementation specifications required, except for a few narrow exemptions.

Technology Asset Inventories and Information System Maps Are Required

The current Security Rule requires Regulated Entities to assess threats, vulnerabilities, and risks but stops short of prescribing particular methods or means of doing so. Certain recognized security practices generally include assessing technology assets and reviewing the movement of ePHI through technological systems to ensure there are no blatant vulnerabilities or overlooked risks.

The NPRM proposes to turn these practices into explicit requirements to create a technology asset inventory and a network map. The technology asset inventory would require written documentation identifying all technology assets, including location, the person accountable for such assets, and the version of each asset. The network map must illustrate the movement of ePHI through electronic information systems, including how ePHI enters, exits, and is accessed from outside systems. Additionally, the network map must account for the technology assets used by business associates to create, receive, maintain, or transmit ePHI. Both the technology asset inventory and network map would need to be reviewed and updated at least once every 12 months.

More Specific Risk Analysis Elements and Frequency Requirements Are Imposed

The Security Rule currently requires Regulated Entities to conduct a risk analysis assessing the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI held by such entities. As mentioned above, the Security Rule itself does not actually define “risk,” leaving some latitude for Regulated Entities to determine what should be included and considered in their risk analyses. While NIST (e.g., SP 800-30), the CPGs, and other authoritative sources have, over time, developed practices for conducting risk analyses, the current Security Rule (last updated in 2013) does not reflect what many now consider to be “best practices,” nor does it provide a specific methodology for Regulated Entities to consider in analyzing risks.

The NPRM imposes specific requirements that must be included in a risk analysis and its documentation, including:

• a review of the aforementioned technology asset inventory and network map;
• identification of all reasonably anticipated threats to the ePHI created, received, maintained, or transmitted by the Regulated Entity;
• identification of potential vulnerabilities to the relevant electronic information systems of the Regulated Entity;
• an assessment and documentation of the security measures the Regulated Entity uses to ensure that the measures protect the confidentiality, integrity, and availability of the ePHI;
• a reasonable determination of the likelihood that “each” of the identified threats will exploit the identified vulnerabilities; and
• if applicable, a reasonable determination of the potential impact of such exploitation and the risk level of each threat.

OCR notes in its preamble that there is still flexibility in determining risk based on the specific type of Regulated Entity and that entity’s specific circumstances. A high or critical risk to one Regulated Entity might be low or moderate to another. OCR is attempting to draw a fine line between telling Regulated Entities more explicitly what they should consider as risks (and what classification of risk should be assigned) while staying true to the hallmark flexibility of the Security Rule in allowing Regulated Entities to determine criticality.

The NPRM requires that risk analyses be reviewed, verified, and updated at least once every 12 months or in response to environmental or operational changes impacting ePHI. In addition to the risk analysis, the NPRM also proposes a separate evaluation standard wherein the Regulated Entity must create a written evaluation to determine whether any and all proposed changes in environment or operations would affect the confidentiality, integrity, or availability of ePHI prior to making that change.

Patch Management Is Now Subject to Mandated Timing Requirements

The NPRM proposes a new patch management standard that requires Regulated Entities to implement policies and procedures for identifying, prioritizing, and applying software patches throughout their relevant electronic information systems. The NPRM proposes specific timing requirements for patching, updating, or upgrading relevant electronic information systems based on the criticality of the patch in question:

• 15 calendar days for a critical risk patch,
• 30 calendar days for a high-risk patch, and
• a reasonable and appropriate period of time based on the Regulated Entity’s policies and procedures for all other patches.

The NPRM contains limited exceptions for patch requirements where a patch is not available or would adversely impact the confidentiality, integrity, or availability of ePHI. Regulated Entities must document if/when they rely on such an exception, and they must also implement reasonable and appropriate compensating controls to address the risk until an appropriate patch becomes available.

Workforce Controls Are Tightened, Including Training and Terminating Access

The Security Rule currently has general workforce management requirements, including procedures for reviewing system activity, policies for ensuring workforce members have appropriate access, and required security awareness training. Although Regulated Entities are currently required to identify the security official responsible for the development and implementation of the security policies and technical controls, the NPRM would require the identification to be in writing.

Despite the current rules relative to workforce security, OCR noted that many Regulated Entities are not in full compliance with such requirements. OCR cited to an investigation involving unauthorized access by a former employee of a Regulated Entity as an example of Regulated Entities not tightly controlling and securing access to their systems. The NPRM addresses that issue by outlining more explicit requirements for workforce control policies, which must be written and reviewed at least once every 12 months.

In addition, the NPRM proposes strict timing requirements for workforce access and training:

• Terminated employees’ access to systems must end no later than one hour after termination.
• Other Regulated Entities must be notified after a change in or termination of a workforce member’s authorization to access ePHI of those other Regulated Entities no later than 24 hours after the change or termination.
• New employees must receive training within 30 days of establishing access and at least once every 12 months thereafter.

Verifying Business Associate Compliance Is Required to Protect Against Supply Chain Risks

The NPRM also includes a new requirement for verifying business associate technical safeguards. Under the NPRM, Regulated Entities must obtain written verification of the technical safeguards used by business associates/subcontractors that create, maintain, or transmit ePHI on their behalf at least every 12 months. Such verification must be written by a person with appropriate knowledge of, and experience with, generally accepted cybersecurity principles and methods, which the HHS website refers to as a “subject matter expert.”

Multi-Factor Authentication and Other Technical Controls Are Mandatory

While the Security Rule has significant overlap with the NIST Cybersecurity Framework and CPGs, the NPRM would further align the Security Rule with these frameworks relative to technical controls. For example, the NPRM would require Regulated Entities to implement minimum password strength requirements that are consistent with NIST. Additionally, the NPRM proposes multi-factor authentication requirements that are consistent with the CPGs, which identify multi-factor authentication as an “essential goal” to address common cybersecurity vulnerabilities. Under the NPRM, multi-factor authentication will require verification through at least two of the following categories:

• Information known by the user, such as a password or personal identification number (PIN);
• Items possessed by the user, including a token or a smart identification card; and
• Personal characteristics of the user, such as a fingerprint, facial recognition, gait, typing cadence, or other biometric or behavioral characteristics.

The NPRM permits limited exceptions from multifactor authentication where (1) current technology assets do not support multi-factor authentication, and the Regulated Entity implements a plan to migrate to a technology asset that does; (2) an emergency or other occurrence makes multi-factor authentication infeasible; or (3) the technology asset is a device approved by the U.S. Food and Drug Administration.

Other proposed minimum technical safeguards in the NPRM include:

• segregation of roles by increased privileges,
• automatic logoff,
• log-in attempt controls,
• network segmentation,
• encryption at rest and in transit,
• anti-malware protection,
• standard configuration for OS and software,
• disable network ports,
• audit trails and logging,
• vulnerability scanning every six months, and
• penetration testing every 12 months.

Contingency/Disaster Planning Is Required to Ensure Resiliency

The Security Rule requires contingency planning for responding to emergencies or occurrences that damage systems containing ePHI, including periodic testing and revision of those plans.

The NPRM outlines more concrete obligations relative to contingency planning, including requirements to identify critical electronic information systems. The NPRM proposes relatively short timing requirements, requiring the implementation of procedures to restore critical electronic information systems and data within 72 hours of a loss and requiring business associates to notify covered entities upon activation of their contingency plans within 24 hours after activation.

Regulated Entities are granted the ability to define what these critical electronic information systems are in conducting their criticality analysis and should consider the quick turnaround time for restoring access when making these determinations.

Impact of the Proposed Changes

Regardless of what security framework, controls, and processes Regulated Entities may already have in place, there are three areas where all organizations can expect to see a significant impact in terms of planning and implementation: (1) increased documentation burden; (2) increased compliance obligations; and (3) business associate agreements (BAAs) compliance. The compliance burden will certainly be significant (as many of the commentators have pointed out), but given the breadth of the NPRM, the full extent of the compliance burden will need to await a final resolution of the rulemaking process.

Increased Documentation Burden

While the Security Rule already requires that Regulated Entities develop and maintain security policies and procedures, the NPRM would expressly require that those policies and procedures, as well as proposed additional plans (e.g., security incident response plans), be documented in writing. As a result, if/when OCR is assessing a Regulated Entity’s compliance with the Security Rule, it will likely have a longer checklist of written policies and procedures it expects to see. In addition, the technology asset inventory, network map, written verification of technical safeguards used by business associates, and all of the analyses and evaluations required by the NPRM would need to be memorialized in writing. Many of these documents would require review at least once per year. Many Regulated Entities may find the new documentation requirements impose an increased administrative burden. Further, with respect to Regulated Entities that do not have sufficient internal expertise or resources to tackle the implementation of these proposed requirements, it is likely that Regulated Entities will need to engage third-party legal and IT experts to meet these requirements.

Increased Compliance Obligations

With the additional written policies and procedures come additional obligations to test and review those procedures. Policies cannot be established and stored away until OCR asks to review them; rather, security policies must be revisited and reviewed at least every 12 months. The NPRM also requires that some of these policies be put to the test to determine the adequacy of the procedures in place at least once every 12 months. This will require dedication of additional time and resources on an ongoing basis. Again, to meet these requirements, Regulated Entities may need to engage third-party legal and IT experts to support these efforts.

The NPRM also contains some new timing requirements that may necessitate the development and implementation of new processes to meet these tight deadlines:

• A former employee’s access must end within one hour of the termination of the individual’s employment.
• Business associates must report to covered entities within 24 hours of activating contingency plans.
• Disaster plans must restore critical electronic information systems and data within 72 hours of a loss.
• Critical and high-risk patches not exempted from the rule must be deployed within 15 and 30 days, respectively.

Business Associate Agreements Compliance

As business associates are directly regulated under the Security Rule, they will also be beholden to the enhanced requirements of the NPRM. In addition, as a result of many of the NPRM’s proposed changes, covered entities and business associates will owe one another new obligations.

As a result, it is likely that these new requirements under the NPRM will impact what is memorialized in BAAs. For example, Regulated Entities must obtain written verification from their business associates that they have implemented the required technical safeguards not only upon contracting but at least once a year thereafter. Regulated Entities should also consider revising their existing BAAs to make more explicit the security safeguard requirements that the NPRM imposes, such as multi-factor authentication and patch management. Further, in light of the potential significant changes to security obligations under the NPRM, parties may also wish to reconsider other provisions in their BAAs regarding risk allocation and indemnification rights, audit rights, third-party certification obligations, offshoring, and reporting triggers and timelines, among others. Depending on the volume of BAAs a Regulated Entity maintains, this renegotiation of BAAs could become a costly and time-consuming endeavor.

Recognition of New/Emerging Technologies

Finally, OCR acknowledged the constantly evolving nature of technology, including quantum computing, AI, and virtual and augmented reality. OCR reiterated its position that the Security Rule, as written, is meant to be technology-neutral; therefore, Regulated Entities should comply with the rule regardless of whether they are using new and emerging technologies. Nevertheless, OCR discussed how the Security Rule may apply in the case of quantum computing, AI, or virtual and augmented reality use and has included a request for information from industry stakeholders and others regarding:

• whether HHS’s understanding of how the Security Rule applies to new technologies involving ePHI is not comprehensive and, if so, what issues should also be considered;
• whether there are technologies that currently or in the future may harm the security and privacy of ePHI in ways that the Security Rule could not mitigate without modification, and, if so, what modifications would be required; and
• whether there are additional policy or technical tools that HHS may use to address the security of ePHI in new technologies.

* * * * *

The future of the NPRM remains uncertain as to whether it will be finalized under the second Trump administration. While efforts to strengthen cybersecurity protections across the health care sector have gained bipartisan support, including under the first Trump administration, the estimated cost of compliance and heightened regulatory obligations under the NPRM may face challenges in light of the second Trump administration’s stated position against increased federal regulation.

Alaap B. Shah also contributed to this article.